[Fox]

So "fog" has been disabled for normal palettes?

[Helixhorned]

Fox, on 01 May 2014 - 03:13 PM, said:

Edit: Since negative shade has no effect with .filler fog, wouldn't it also make sense to remove the glow colors (or glowmaps from highres textures) in the fog?

IMO whether fullbright colors "shine through" the fog should be a property defined together with a particular pal number, to mimic the behavior of how the corresponding palookup table is set up. Currently, things are a little inconsistent between classic and the non-per-pixel-lookup GL modes (apart from the fact that 8-bit mode doesn't directly support fogpal at all). The default fog palettes are set up such that the fading also applies to the fullbright color indices, >= 240. The lookup result indices could in theory be also fullbright, but for sufficently large shade indices, they shouldn't. On the other hand, the OpenGL modes make fullbright colors always shine through. The other major difference is that in the 32-bit modes, a fogged .floorpal is applied automatically to walls and the ceiling of that sector, whereas in classic you'd have to set it manually.

Fox, on 02 May 2014 - 08:05 PM, said:

So "fog" has been disabled for normal palettes?

How so? The changes have only been adding new stuff, not breaking old things, at least not intentionally.

[LeoD]

Not sure if I'm doing it wrong (again) but the new MinGW GCC 4.9, both 32 and 64 bit, fails to link EDuke32 with LTO=1 (default):

[gcc.exe (i686-posix-sjlj-rev1, Built by MinGW-W64 project) 4.9.0]:

c:/Users/leod/_VCS/eduke32/platform/Windows/lib/32\libSDL2main.a(SDL_windows_main.
o): In function `console_main':
/Users/slouken/release/SDL/SDL2-2.0.3-source/foo-x86/../src/main/windows/
SDL_windows_main.c:140: undefined reference to `SDL_main'
collect2.exe: error: ld returned 1 exit status
Failed linking executable eduke32.exe!

[gcc is /mingw/bin/gcc gcc.exe (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.0 RENDERTYPE=WIN]:

C:/Progs/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../.
./../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-
crt0_c.o):crt0_c.c:(.text.startup+0x25): undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
Failed linking executable eduke32.exe!

[Hendricks266]

That's weird. A shot in the dark, but try commenting out this include in build/src/winbits.c:

// Workaround for a bug in mingwrt-4.0.0 and up where a function named main() in misc/src/libcrt/gdtoa/qnan.c takes precedence over the proper one in src/libcrt/crt/main.c.
#if (defined __MINGW32__ && __GNUC__ == 4 && __GNUC_MINOR__  >= 8) || (defined __clang__ && __clang_major__ == 3 && __clang_minor__ >= 4)
# include "mingw_main.c"
#endif

EDIT: From the GCC changelog:

Quote

When using a linker plugin, compiling with the -flto option now generates slim objects files (.o) which only contain intermediate language representation for LTO. Use -ffat-lto-objects to create files which contain additionally the object code. To generate static libraries suitable for LTO processing, use gcc-ar and gcc-ranlib; to list symbols from a slim object file use gcc-nm. (Requires that ar, ranlib and nm have been compiled with plugin support.)

I have a feeling this could be related.

EDIT 2: It could also be a problem in this early MinGW-w64 build. As I wrote on the wiki, I prefer rubenvb's personal builds for MinGW-w64. His folder shows recent activity but nothing for 4.9 yet. I ultimately prefer mainline MinGW, but they are rather slow to update GCC releases.

[LeoD]

Hendricks266, on 07 May 2014 - 02:19 PM, said:

That's weird. A shot in the dark, but try commenting out this include in build/src/winbits.c:

Nope, doesn't help.

Hendricks266, on 07 May 2014 - 02:19 PM, said:

It could also be a problem in this early MinGW-w64 build. As I wrote on the wiki, I prefer rubenvb's personal builds for MinGW-w64. His folder shows recent activity but nothing for 4.9 yet. I ultimately prefer mainline MinGW, but they are rather slow to update GCC releases.

I've been using the 4.8.2 w64 builds from the place linked above since October. Except for the header file copying mentioned in the wiki they run out-of-the-box.

Hendricks266, on 07 May 2014 - 02:19 PM, said:

From the GCC changelog:
[...]
I have a feeling this could be related.

Yup! make OPTOPT=-ffat-lto-objects does the trick for the time being!

[Hendricks266]

You may want to use CUSTOMOPT for that. Setting OPTOPT clobbers the OPTimization OPTions the Makefile throws in.

[LeoD]

Hendricks266, on 07 May 2014 - 04:15 PM, said:

You may want to use CUSTOMOPT for that. Setting OPTOPT clobbers the OPTimization OPTions the Makefile throws in.

Hm, CUSTOMOPT only works when no OPTOPT (like -march=bdver1 in my case) is given. Seems like a Makefile.common deficiency,

[Micky C]

Is there a recent version of mapster32 readily available and set up for mac? The dukeworld mac zips don't seem to have it?

[rhoenie]

Mickey C, on 15 May 2014 - 12:55 AM, said:

Is there a recent version of mapster32 readily available and set up for mac? The dukeworld mac zips don't seem to have it?

Starting with eduke32_osx-gtk2_lion_svn4466.dmg it is added again now.

Find it here: http://dukeworld.duk...et/eduke32/mac/

[Micky C]

So I try using eduke32 and mapster32 for mac, and the damn thing just can't find duke3d.grp! I remember hearing that the data might have to be placed in some weird location, but I figure between the grp file in the root folder, and between Megaton I've also got installed, it should be able to find one of them. Any ideas? Has this exposed some kind of problem with the mac eduke's ability to detect the megaton locations, or did it simply not have that feature in the first place?

[rhoenie]

Mickey C, on 17 May 2014 - 05:48 PM, said:

So I try using eduke32 and mapster32 for mac, and the damn thing just can't find duke3d.grp! I remember hearing that the data might have to be placed in some weird location, but I figure between the grp file in the root folder, and between Megaton I've also got installed, it should be able to find one of them. Any ideas? Has this exposed some kind of problem with the mac eduke's ability to detect the megaton locations, or did it simply not have that feature in the first place?

Open a Finder window, move the mouse to the menu "Go", press the ALT key, go to "Library". In there is a folder "Application Support". You need to create a new folder "EDuke32" in here and place all the data files from your DOS Duke Nukem 3D installation there.

[Micky C]

Ah yes that did the trick, even got the AMC TC working by moving all the data there. Thanks Rhoenie

[LeoD]

Another GCC 4.9 issue: make ebacktrace1-64.dll fails:

Spoiler

> make ebacktrace
Build started using:
compiler: "gcc -Wimplicit -Wdeclaration-after-statement -O2 -funswitch-loops -fomit-frame-pointer -DNDEBUG -DUSING_LTO -flto -fno-stack-protector  -W -Wall -Werror-implicit-function-declaration -Wpointer-arith -Wextra  -funsigned-char -fno-strict-aliasing -DNO_GCC_BUILTINS -D_FORTIFY_SOURCE=2 -fjump-tables -Wno-unused-result  -Wno-char-subscripts -I/home/eduke-geralds/platform/Windows/include -DUSE_LIBPNG -DUSE_LIBVPX -Isource -Ibuild/include -Isource/jmact -Isource/jaudiolib/include -Isource/enet/include  -fno-pic -DUNDERSCORES -I/home/sdk/dx -I/home/sdk/dx/include  -DHAVE_INTTYPES -DSDL_TARGET=2 -DSDL_FRAMEWORK -D_GNU_SOURCE=1 -DRENDERTYPESDL=1 -DMIXERTYPEWIN=1 -Wno-strict-overflow -DUSE_OPENGL -DNOASM -DPOLYMER  -Wno-attributes"
linker: " -flto -static-libgcc  -Wl,-Map=start.memmap  -L/home/eduke-geralds/source/jaudiolib/third-party/Windows/lib/64  -L/home/eduke-geralds/platform/Windows/lib/64   -lFLAC -lvorbisfile -lvorbis -logg -ldsound -lm -lvpx  -Wl,--enable-auto-import -lmingwex -lgdi32 -lcomctl32 -lwinmm -lssp -lwsock32 -lws2_32 -lshlwapi -mwindows -static -lSDL2main -lSDL2 -lmingw32 -lgdi32 -limm32 -lole32 -loleaut32 -lwinmm -lversion -ldxguid_sdl -lpng_mini -lz_mini -lcompat-from-mingw-w64  -lstdc++"
C:/Progs/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../.
./../../x86_64-w64-mingw32/bin/ld.exe: cannot find -liberty
collect2.exe: error: ld returned 1 exit status
Failed building ebacktrace1-64.dll from platform/Windows/src/backtrace.c!
make: *** [ebacktrace1-64.dll] Error 1

Seems they forgot mingw64/lib/libiberty.a. I have copied the 4.8.2 version as a workaround.

[MetHy]

What exactly has changed with eduke32 (compared to vanilla duke) regarding parallaxed subway sectors throwing rockets?
What I mean is, in a map I've made I've made a spaceship throwing rockets E2L1 style. It works like intended in eduke32 but when trying the map in dos duke3d and in megaton, the rockets would always hit a boarder of the spaceship and not come to the player.

It's not really a problem (i'm sure i can fix this so that it works in all dukes), just wondering.

[Danukem]

MetHy, on 18 May 2014 - 02:22 PM, said:

What exactly has changed with eduke32 (compared to vanilla duke) regarding parallaxed subway sectors throwing rockets?
What I mean is, in a map I've made I've made a spaceship throwing rockets E2L1 style. It works like intended in eduke32 but when trying the map in dos duke3d and in megaton, the rockets would always hit a boarder of the spaceship and not come to the player.

It's not really a problem (i'm sure i can fix this so that it works in all dukes), just wondering.

An educated guess: EDuke32 uses higher bit numbers and so has more precision when calculating how to aim at the player. This can make a large difference if the player is far away, especially if the player is above or below the rocket.

[MetHy]

Trooper Dan, on 19 May 2014 - 07:06 AM, said:

An educated guess: EDuke32 uses higher bit numbers and so has more precision when calculating how to aim at the player. This can make a large difference if the player is far away, especially if the player is above or below the rocket.

Would that make a difference regarding enemies, too ?

[Danukem]

MetHy, on 19 May 2014 - 08:47 AM, said:

Would that make a difference regarding enemies, too ?

If my guess is correct and if enemies use the same aiming function (which they probably do), then yes. But it wouldn't be as noticeable, because enemies are coded to fire only when they have a line of sight to the player and they tend to fall asleep when they are far away.

[MetHy]

So technically, for example a Commander being high above the player will have better aiming in eduke32 than in classic duke...

[Fox]

You could post a picture of said spaceship, so we can have an idea of how you are using the effect.

[MetHy]

Well, the spaceship is high above playing level. Well, not that high, like 40 units higher; and that seems to be the reason why the rockets explode as they're shot in classic Duke.
The only way I could make it work in classic Duke was if I lowered the subway SE (which is where the rockets come from) by at least 15-20 units (come to think of it, the spaceship in E2L1 wasn't that high above the player), however that wouldn't work at all in the level I've made unless I completely reshape the whole level, and even then it wouldn't be as good as it is now.

I've tried everything btw and the source of the rocket shooting being too high is the only explanation I've found. It has nothing to do with the rockets hitting the spaceship itself or the sky, or the size and shape of the sector, etc

Conclusion : the level will be eduke32 only (even though I like my levels to be playable in all dukes if possible). What pisses me off a little though is how I had no idea those subway parallax sector rockets behaved differently in eduke32, and if I had known, considering how early on I implemented that spaceship, I COULD have come up with a way to make it work in all Dukes. Now though, it's too late as reshaping the whole level at this point is out of question.
Then again, how could I have known; I doubt even the makers of eduke32 knew those rockets behave differently than in classic Duke.

Something else completely different now : the sprite no shade feature doesn't work on flat ("ground aligned") sprites when there is a parallax sky above. Is that how it's always been?

[High Treason]

Do you have shade preview enabled ( ' + X ) ? I don't think it shows up without that, assuming you're talking about Mapster of course. If it's in EDuke I certainly don't remember it behaving like that.

[Daedolon]

MetHy, on 20 May 2014 - 03:55 AM, said:

Something else completely different now : the sprite no shade feature doesn't work on flat ("ground aligned") sprites when there is a parallax sky above. Is that how it's always been?

It only works for floor shade, if you have a parallaxed ceiling, the sprite will take its shade. Check out the cables in my CBP map for the winch system outside.

[MetHy]

Well, I've built a workaround, it's only 3 sprites so I built I tiny sector at the base of the sprites and I gave the skies of those tiny sector the shade value I wanted for the sprite; I was just wondering if that's how sprite no shade is supposed to behave. Wouldn't it be nice if it also worked when there are parallaxed skies?

[Danukem]

Daedolon, on 20 May 2014 - 04:04 AM, said:

It only works for floor shade, if you have a parallaxed ceiling, the sprite will take its shade. Check out the cables in my CBP map for the winch system outside.

That's a bug. spritenoshade is supposed to make the sprite unaffected by the sector's shade, regardless of whether it is floor or ceiling.

[Helixhorned]

 MetHy, on 20 May 2014 - 03:55 AM, said:

Something else completely different now : the sprite no shade feature doesn't work on flat ("ground aligned") sprites when there is a parallax sky above. Is that how it's always been?

I can't reproduce this. Placing a floor-aligned sprite into a sector with a parallaxed ceiling and enabling the sprite's "don't take over shade" bit (key [N] in Mapster32), the sprite keeps its own shade value in the editor (don't forget to enable shade preview with [']+[X] as High Treason remarked) as well as the game.

[Sobek]

Hmm. So I've been away for a couple of years really (popped my head in the door from time to time). Could anyone tell me what some of the biggest improvements or changes have been to eDuke32 in that time? I remember every couple of days I'd read the changelog on new builds and be amazed at some of the excellent fixes present, but I'm just curious if there have been any MAJOR improvements made anywhere that I should know about. I used to struggle with some annoying little glitches (like models that would just vanish because the engine decided they didn't need to be rendered from that particular viewpoint or sector, for example). Just curious what you consider to be the highlights so I can start getting caught up again

Spent the last few days just cleaning up a fresh install so I can get back into things. Have been playing some dukematches with my best friend on some of our old maps we made and having such a blast. Just about ready to get stuck into it all again I think!

[Micky C]

One thing you might find useful is something called clipshape maps, allowing you to have accurate model clipping by recreating the rough shape of the model using sector geometry in a special map file, which the engine then uses for clipping information.

Not sure how familiar you are with Polymer and TROR but those are around. There's also better fogpal for openGL modes independent of shade, and alternate palates in polymer are now accurate for hightile textures when using the correct generated references "tables" (can't remember the name).

[Daedolon]

 Helixhorned, on 20 May 2014 - 08:15 AM, said:

I can't reproduce this. Placing a floor-aligned sprite into a sector with a parallaxed ceiling and enabling the sprite's "don't take over shade" bit (key [N] in Mapster32), the sprite keeps its own shade value in the editor (don't forget to enable shade preview with [']+[X] as High Treason remarked) as well as the game.

Note that few sprites have hardcoded behaviour to ruin this as well.

[MetHy]

There has been a glitch for quite a while now (still in the latest eduke32 version, i checked) that makes turrets a LOT harder to hit then they should be.

[Helixhorned]

 Daedolon, on 21 May 2014 - 06:51 AM, said:

Note that few sprites have hardcoded behaviour to ruin this as well.

Yes, in actors.c, some cases of the actor SFLAG_NOSHADE have inconsistent coding. The set of problematic tiles is probably as follows.

In G_MoveZombieActors(); the A_CheckSpriteFlags() call is currently buggy r4477: on transitioning from zombie actors to STAT_STANDABLE, these will always take over either the ceiling or the floor shade:

Spoiler

RUBBERCAN
EXPLODINGBARREL
WOODENHORSE
HORSEONSIDE
CANWITHSOMETHING
CANWITHSOMETHING2
CANWITHSOMETHING3
CANWITHSOMETHING4
FIREBARREL
FIREVASE
NUKEBARREL
NUKEBARRELDENTED
NUKEBARRELLEAKED
TRIPBOMB

Sprites affected by SE12 (light switch) when "Lights flickering on":

                for (SPRITES_OF_SECT(SECT, j))
                {
                    if (sprite[j].cstat&16)
                    {
                        if (sc->ceilingstat&1 && A_CheckSpriteFlags(j,SFLAG_NOSHADE) == 0)
                            sprite[j].shade = sc->ceilingshade;
                        else sprite[j].shade = sc->floorshade;
                    }
                }

This is not to be confused with functionality for the sprite "don't take over shade flag", which controls sprite[].shade -> displayed sprite shade in G_DoSpriteAnimations(). This one should be working fine.
So, MetHy: was this a false alarm (shade preview not enabled?) or is it one of the problematic cases above?

---
Regarding the few last reports of alleged bugs in general: posting a test case straight away usually yields better results than merely telling.

EDIT2: actually, I recall the turret-hard-to-hit bug from playing the beach CBP. No need for a test case for that, but it might be a while until I'll debug it.