This has increasingly become an obstacle with the hardware renderer, so now the values are being stored as plain data in the sector, with the software renderer getting the actual color tables when needed. While this is a bit slower than storing the pregenerated colormap, in realistic situations the added time is mostly negligible in the microseconds range.
Since the true color software renderer also handles them there is no point keeping them on the GL side.
This also optimized how they are stored, because we no longer need to be aware of a base engine which doesn't have them.
This function will truncate everything that is larger than LONG_MAX or smaller than LONG_MIN to fit into a long variable, but longs are 32 bit on Windows and 64 bit elsewhere, so to ensure consistency and the ability to parse larger values better use strtoll which does not truncate 32 bit values.
This really serves no use anymore and is mostly a remnant of old times with dark CRT monitors. The default ambient level was set at 20, meaning a sector light level of 40. This is a value actual levels rarely get to, except when using some lighting effects - but it's for those that the ambient clamping did the most damage.
This was done to clean up the license and to ensure that any commercial fork of the engine has to obey the far stricter requirements concerning source distribution. The old license was compatible with GPLv2 whereas combining GPLv2 and LGPLv3 force a license upgrade to GPLv3. The license of code that originates from ZDoomGL has not been changed.
- added colormap shader to postprocessing.
This replaces the in-place application of fullscreen colormaps if renderbuffers are active. This way the fully composed scene gets inverted, not each element on its own which is highly problematic for additively blended things.
- fixed: The shader code for handling special fixed colormaps did not use the color vertex attribute which was most evident with the 'shadow' render style on the spectre.
After thinking about it for a day or so I believe it's the best option to remove all compatibility code because it's a major obstacle for a transition to a core profile.
Turns out that the name doesn't accurately describe what it does.
It is correct for images that come with their own palette or are true color.
But for images using the game palette it doesn't use the red channel to determine translucency but the palette index! Ugh...
This means it cannot be done with a simple operation in the shader because it won't get a proper source image. The only solution is to create a separate texture.
- remove thing color from lighting calculations.
- implement alpha textures and inverse sprites for infrared as texture modes. This still requires some handling for the alpha texture mode for non-shader rendering because there is no way in the fixed pipeline to do it. The inverted texture effect can be done with a texture combiner.
- fixed: ThingColor for sprites was set in the wrong place. It must be in the Process function, not in the lighting calculation.
- added functions for isolated calculation of sprites' dynlight color.
On GL 3.x+ this isn't needed at all and on older hardware it causes performance issues, in particular with hires textures due to impossibility of precaching.
In addition it forces some really awkward handling of lighting for things that have their own color, like stenciled sprites or particles.
With this special case gone it will be possible to handle this case in a saner manner than it is right now.
As compensation for older hardware a fullscreen blend will be drawn over the entire screen. This won't be 100% accurate but it's preferable to keeping the current method.
