[Perro Seco]

I downloaded EDuke32 r5905 and I found two bugs related with the 26-29 fog palettes:

• If I write a DEF file with some fogpal commands in it, fog will disappear during game. It doesn't happen with older versions (like r4525, the one I was using before).
  
  
• Looks like fog has a slightly different color, and weapon sprites (the first-person view ones) doesn't have any fog effect:
  

[Hendricks266]

Which renderers?

Is there any chance you could bisect the issues to a narrower range, or a single synthesis build? A 1500 revision window is not much help, I'm afraid.

A problem with fog has been reported once before, but without much information. I appreciate your assistance.

[Perro Seco]

It happens in classic and polymost renderers, I can't run polymer because my graphic card is very basic and doesn't support it.

But I managed to found this:

r4800: everything related with fog works fine.
r4814: weapon sprites bug appears, but fogpal still works fine.
r5347: fogpal bug appears; if I write something like "fogpal 28 XX XX XX", palette 28 will work fine, but the rest of fog palettes will disappear during game.

[Hendricks266]

That helps, thank you!

[Hendricks266]

Perro Seco, on 23 October 2016 - 03:51 PM, said:

r4814: weapon sprites bug appears, but fogpal still works fine.

This is not a bug. EDuke32 remembers a setting for every pal: whether tsprites take on the floorpal of their sector or not. The player's weapon follows the setting too. Helixhorned intentionally set this to "no" by default for fogpals.

The fog effect kind of sucks in 8-bit either way, but having the setting this way makes complete sense for GL.

Perro Seco, on 23 October 2016 - 03:51 PM, said:

r5347: fogpal bug appears; if I write something like "fogpal 28 XX XX XX", palette 28 will work fine, but the rest of fog palettes will disappear during game.

This one is trickier. The game will look for the first empty set of 4 contiguous palette IDs to fill with the hardcoded fogpals. In the commits around that point, I added def tokens that could completely replace PALETTE.DAT and LOOKUP.DAT. In order for thie fogpals to respect palettes loaded from the def code, I had to move the creation of the fogpals to after the def code is loaded instead of before it. What you've pointed out made me realize that this changed the behavior of the fogpal def token to not overwrite the hardcoded fogpals any more.

Since they are intended for maps without any accompanying CONs or defs, I am okay with this change. For full mods that would like to use them, I recommend the following def code:

// disable the hardcoded fogpals
globalgameflags 2

// replicate the hardcoded fogpals
fogpal 26 15 15 15
fogpal 27 15 0 0
fogpal 28 0 15 0
fogpal 29 0 0 15

I am of the opinion that these hardcoded fogpals should never have been added, but we're stuck with them.

[Perro Seco]

Thanks a lot for that code, now I can see the fog again.

Quote

This is not a bug. EDuke32 remembers a setting for every pal: whether tsprites take on the floorpal of their sector or not. The player's weapon follows the setting too. Helixhorned intentionally set this to "no" by default for fogpals.

Any chance to get it working again like in r4525? If not I'll try to emulate it via CON code, but I've been searching in EDuke32 Wiki and I can't find a way to access the weapons' palette.

Quote

I am of the opinion that these hardcoded fogpals should never have been added, but we're stuck with them.

I think fog is a great addition, it adds variety to the levels. For me, it looks cool even in 8-bit. Here are some screenshots from my TC, using classic renderer:

Spoiler

The only problem now is the one mentioned above; the weapon in the second image looks very dark compared with the environment.