src/gl/renderer/gl_renderer.cpp:775:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:776:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:777:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:778:45: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:779:40: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:780:45: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/v_draw.cpp:1144:51: warning: '&' within '|' [-Wbitwise-op-parentheses]
src/textures/texture.cpp:1050:20: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
src\intermission\intermission.cpp(80): warning C4101: 'lumpnum': unreferenced local variable
This removes the entire palette switch and all the special checks to ensure that no menu can be drawn over this image.
Instead it gives this texture its special palette in the texture manager so that the proper image is created right away.
I decided against exposing this as an editing feature because it is far too specific to this particular image and the raw page format it uses.
A quick check of /idgames shows no project ever replacing it - especially no ZDoom-based project - so no extended handling is needed to make this work with other texture formats.
* the MAPINFO options now get handled in g_mapinfo.cpp and g_level.cpp, just like the rest of them as members of level_info_t and FLevelLocals.
* RecalcVertexHeights has been made a member of vertex_t and been moved to p_sectors.cpp.
* the dumpgeometry CCMD has been moved to p_setup.cpp
This theoretically means that the software renderer could access this data as well - if it just had been written with a more flexible texture interface.
However, as things stand, this may require quite a bit of work to achieve.
The old organization made sense when ZDoom still was a thing but now it'd be better if all pure data with no dependence on renderer implementation details was moved out.
A separation between GL2 and GL3+4 renderers looks to be inevitable and the more data is out of the renderer when that happens, the better.
This was originally invented to fix the sprite offsets for the hardware renderer.
Changed it so that it doesn't override the original offsets but acts as a second set.
A new CVAR has been added to allow controlling the behavior per renderer.
This is a necessary first step for simplifying the texture handling in order to refactor it.
# Conflicts:
# src/gl/system/gl_swframebuffer.cpp
# src/textures/textures.h
# src/win32/fb_d3d9.cpp
This was done mainly to reduce the amount of occurences of the word FTexture but it immediately helped detect two small and mostly harmless bugs that were found due to the stricter type checks.
src/v_video.h:56:6: error: ISO C++ forbids forward references to 'enum' types
src/v_video.h:342:17: error: field has incomplete type 'FTextureFormat'
src/v_video.h:344:47: error: variable has incomplete type 'FTextureFormat'
These cannot be done with the regular textures so there needs to be an option to create more than one native texture per FTexture. For completeness' sake there is also the option now to create a paletted version of a texture if the regular one is true color. This fixes a long standing problem that translations were not applied to non-paletted textures.
Aside from PCX 4 bit, uncompressed PCX and TGA grayscale for which I was unable to obtain test images, all others now produce proper textures in both 8 and 32 bit mode.
The old logic used a translation table that does not work with color images, it was designed to handle 8 bit grayscale images.
So now, it creates a true color buffer and then turns it into a texture with R,G,B = 255 and the alpha channel set to the grayscale value.
This was also the reason why crosshairs made from 32 bit PNGs did not show correctly.
* Instead of using the red channel it now uses the grayscale value. While slower in a few situations, it is also more precise and makes the feature more useful.
* For paletted textures do not use the index as alpha anymore but the actual grayscaled color. This is again to make the feature more consistent and useful.
* To compensate for the above there is now a list of hashes for known alpha textures in patch format, so that they don't get broken.
* IMGZ is now considered a grayscale format. There's only two known textures that use IMGZ for something else than crosshairs and those are explicitly handled.
* several smaller fixes.
* the actual color conversion functions for paletted output are now consolidated in a small number of inlines so that future changes are easier to do.
Note: This hasn't been tested yet and will need further changes in the hardware rendering code. As it is it is not production-ready.
GCC/Clang reported these warnings:
src/textures/jpegtexture.cpp:305:29: warning: data argument not used by format string [-Wformat-extra-args]
src/textures/jpegtexture.cpp:388:28: warning: data argument not used by format string [-Wformat-extra-args]
src/textures/jpegtexture.cpp:432:29: warning: data argument not used by format string [-Wformat-extra-args]
src/textures/jpegtexture.cpp:481:28: warning: data argument not used by format string [-Wformat-extra-args]
Now it is no longer necessary to provide specially set up textures for rendering shaded decals, they can use any PNG texture now that contains a proper red channel.
Handling of the alPh chunk has been removed as a result as it in no longer needed.
Even though unlikely, this should work as a regular texture because it can be used as such.
As a result of the above, true color generation needs to be done explicitly now.
Until now each subclass of FTexture had to implement the entire span generation itself, presumably so that a few classes can use simpler structures.
This does not work if a texture can have more than one pixel buffer as is needed for alpha textures.
Even though it means that some classes will allocate more data now, it's the only way to do it properly.
In addition this removes a significant amount of mostly redundant code from the texture classes.
- added alpha texture processing to all converted classes
As of now this is not active and not tested.
Note that as part of the conversion even those textures that were working as alphatextures will not look correct until the higher level code gets adjusted.
