ZDoom, colored sector and weapons flash

So i've been playing with Zdoom and my map is coming along really well. My only problem so far is when i step on a colored sector ( let's say a blue colored sector for exemple ) and pressing the fire button some of the weapons flash look uglier than others, especially the SSG, Chaingun and Rocket Launcher, is there any way to fix it or is there any Wad out there that somehow fix this? ( well, it's not really a bug, it's just not visually pleasant ) some screenshots of my map with the glitch in action:

http://img695.imageshack.us/i/ssgfiring.png/
http://img718.imageshack.us/i/rocketfiring.png/
http://img16.imageshack.us/i/chaingunfiring.png/

I reduced the screenshots size, but the quality is good enough to see
the problem. Thanks in advance!

Nice looking maps (or at least what was shown in those tiny screens)

your running GZDoom right? Zdoom doesn't have that problem.

Anyway I have no clue if you can fix that with a setting or something, but you can however use a sector height trick to color the muzzle flash. but that limits what you can do in that sector, not to mention you can't draw sky's as far as I know. so it's more of an unnecessary hassle =)

Here is a map (note: don't run this on the regular zdoom since it's pointless there)

Don't do any hacky stuff here. I'm aware of the problem and I concur that something needs to be done about it. The problem is just that right now I don't know what. Once I get the right idea to address this in the engine I'll do.

Good to know that, i think that colored sector can add a lot of atmosphere to a level!

The same issue is currently present in Doomsday too. Like Graf said, its best that authors do not try to do anything about it. It can be solved in engine.

@Graf What are your thoughts on this? I've personally already tried a linear blending of the sector light colour and "fullbright" but that didn't look too great to me.

Is this because the flash sprite is fullbright and hence not getting colored since the colormap emulation tends to pure white at the fullbright end?

DaniJ said:

@Graf What are your thoughts on this? I've personally already tried a linear blending of the sector light colour and "fullbright" but that didn't look too great to me.

The only option I see is to use something like GZDoom's brightmaps and use a shader to mix them (or split them into 2 textures if you don't want to use shaders.) But this will inevitably require IWAD dependent data in the engine somewhere.

andrewj said:

Is this because the flash sprite is fullbright and hence not getting colored since the colormap emulation tends to pure white at the fullbright end?

Yes. Unlike ZDoom's software renderer GZDoom treats fullbright properly and always renders it with white light so the weapon parts of the flash sprite stand out.

Perhap not 100% on topic, but it seem that running GZDoom in software mode fixed the problem of colored sectors, however most ( if not all )
of the textures and sprites are totally screwed, it's like i'm running the map on a acid trip or something...

http://img243.imageshack.us/i/screwedcolors.png/


Does it have anything to do with the fact that the new textures i'm using were imported in png format? I double-checked everything in Doombuilder and XWE and nothing seem unusual.

Graf Zahl said:

The only option I see is to use something like GZDoom's brightmaps and use a shader to mix them (or split them into 2 textures if you don't want to use shaders.) But this will inevitably require IWAD dependent data in the engine somewhere.

I'm not willing to go down the route of additional IWAD-specific resources. For the simple reason that it is but a work around for the original IWAD psprites, with PWADs obviously continuing to suffer the same problem.

Even using a shader so that you can "overbright" the results I don't think this will look right.

Perhaps we need to consider using the opacity of the flash psprite as a mask some how.

But how will you generate such a mask? That's precisely my problem here. I can't think of anything that would be able to auto-generate it.

Well if you consider that the flash is basically a mask already except that areas of no change are the same as the other it should be possible to produce a mask from them. Iterate over the flash psprite pixel data, comparing the color and alpha to that in the normal psprite data. If equal there is no difference so the resultant alpha is zero.

Would work, no?

EDIT: Fixed algorithm proposal and removed misleading sentence which alluded to a GL blending method at the drawing stage, which may not be necessary.

That may work for the chaingun but not for the plasmagun and rocket launcher

Any particular reason? I can't foresee a problem, looking at them in an image editor...

Not all flash sprites are masks. Some are full overlays and in some the underlying base sprite is altered a bit (e.g for some highlights)

That shouldn't pose a problem. Once you have the mask, use an algorithm similar to the ColorOutlines method used to spread color into the masked area for sprites and textures but rather, this algorithm will blur the edges of the mask into the non-masked area (naturally, only do this where a source pixel is present in both normal and flash psprites). Draw the flash as normal but with the resultant mask.

Its never going to yield ideal results though it will look far better than what we currently get.

Edit: Created a mockup of the results of such an algorithm to possibly clarify it: http://dengine.net/wip/pspritemask.psd
All actions taken in the creation of this mockup can be implemented relatively easily algorithmically.

Not sure it would be that simple...

As you can see, here (PLSGA0 and PLSFB0) the flash sprite is used to actually change the entire weapon slightly. The shapes do not correspond.

In which case, there will be nothing left of the underlying psprite visible or what will be - will be the same color so it won't matter. See the mockup I made using MISG as an example. If it would help I could do the same with plasma rifle?

Remember the goal is not to light the fullbright areas but to blend the "border" between them and the non-fullbright areas.

Edit: Although, the algorithm could be improved so that rather than a linear blur, the distance and degree of which is a function of the color difference delta between normal and flash psprites and their position relative to the border. Though naturally this is a quite a bit more expensive.