[Fox]

There is quite a problem with .fogpal, because in Duke 3D the visibility of each texture also decreases with the shade. The result is a very unrealistic and unpleasing effect if the fog is not black.



The solution I can think of would require the fog being rendered in two steps, one which darkens the textures and a second one that adds the fog as if the texture shade is ≤ 0.

Speaking mathematically:

Spoiler

How it is:

• Shade 0: adds 10% of # fog
  
• Shade 10: adds 20% of # fog
  
• Shade 20: adds 30% of # fog

How it would be:

• Shade 0: adds 10% of # fog
  
• Shade 10: adds 9.09% of black fog and 10% of # fog
  
• Shade 20: adds 18.18% of black fog and 10% of # fog

[Helixhorned]

Fox, on 30 April 2014 - 03:37 PM, said:

There is quite a problem with .fogpal, because in Duke 3D the visibility of each texture also decreases with the shade.

Are you referring to the fact that with Polymost and r_usetileshades 1, a texture's constant darkening is also a function of its sector's visibility? (Note that there's no such thing as "a texture's visibilty". It makes only sense to speak of the sector member 'visibility', or as the per-pixel attenuation with distance from the eye.) In fact, that's my major beef with TX's original "use tile shades" mode: it just doesn't make a lot of sense to take something that's varying per-pixel and apply that uniformly to a texture.

For this reason, I propose making r_usetileshades 2 the default, which uses lookup tables for the constant darkness attenuation (i.e. shade) and models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

Fox: what are the renderer settings you're using in that screenshot? Setting r_showcoords to 2 will show some of the relevant ones.

[Fox]

That just sector .filler with r_usenewshading 3 (r_usetileshades doesn't matter).

Spoiler

Helixhorned, on 01 May 2014 - 02:10 AM, said:

models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

It would be kinda of weird for me if non-black fog behavior was different, especially because you can have a fog that is 99% black yet would be different.

[Helixhorned]

OK, I went ahead and made r_usetileshades 2 the default. I'm curious how the change will be percieved in real situations. As I noted in the commit log, the new default mode

Quote

does not take a sector's visibility values into account for uniform
darkening of a texture. It is more faithful to classic with respect to
fog/visibility *distances*, but may be less so as far as the "tint" of the
texture due to visibility attenuation is concerned.

Fox, on 01 May 2014 - 10:40 AM, said:

Helixhorned, on 01 May 2014 - 02:10 AM, said:

models fog/visibility as linear fading with distance with a particular color. TX, I understood your last comment to mean that you're fine going forward with that?

It would be kinda of weird for me if non-black fog behavior was different, especially because you can have a fog that is 99% black yet would be different.

I should have said "models fog/visibility exclusively as linear fading with distance with a particular color." Fading with distance (i.e. using glFog()) is what the OpenGL normally do in the absence of per-pixel shade table lookups (as currently only implemented with Polymer's r_pr_artmapping). What the original r_usetileshades 1 does is that it basically splits the darkening due to a sector's visibility and puts a part of that as uniform texture attenuation, and the "remaining" part goes into the actual fragment-depth-dependent fogging. As a consequence, with r_usetileshades 1 fog can sometimes cut off much farther compared to classic, as seen on the earlier E1L1 air duct screenshots. (It still cuts off slightly farther with r_usetileshades 2, but only by a small constant factor.)

Quote

That just sector .filler with r_usenewshading 3 (r_usetileshades doesn't matter).

Ah, I see. It only now dawned to me what you meant. Yes, an object's shade also determines the fog parameters, and with linear fog, in particular the far cutoff distance. This is simply due to the OpenGL modes modeling fog after classic, and is easily seen in the central palookup equation (or the inversion thereof). In r4460, I made an object's shade not contribute to fog parameters if that fog comes indeed from a sector[].fogpal -- the fog calculation is done as if the shade were 0. I'm kind of happy with this special case for 'fogpal' because it differentiates it from setting the same pal as .floorpal on the sector.

[Fox]

Worked REALLY good, especially because you can have linear black fog using a fogpal other than zero.

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?

[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.