- Some maps may contain very large or very many (animated)
textures
- Texture sets are not typically shared between maps, so
each texture allocation may go unused for a long time
after the map ends
- Keeping these PU_STATIC leads to significant memory
usage over the program duration
- Software* + OpenGL support
- *Not supported: R_DrawColumnShadowed_8
- This has something to do with walls and FOF lights.
However, I don't see an easy code solution and I don't
know how to even test this.
- Ensures that column drawer doesn't read out of bounds
the brightmap column.
- Refactored code in r_segs.cpp, so it checks
R_TextureHasBrightmap.
- Added comments for plane brightmaps and sprite
brightmaps, that these are still error-prone.
- Cache DBGLINE texture
- Draw this texture at horizon (player's eye level)
- Draw this texture at max brightness
- Do not slope skew this texture
- Use R_DrawColumn_Flat_8 to colorize the this texture
Checks on a background thread since the complexity should
be O(n^2). The specific texture data it checks shouldn't
change after R_LoadTextures so it doesn't need a mutex.
R_LoadTextures was reading in the entirety of every
texture lump, now it only reads the 8 byte PNG header.
This saved more than 1 second for me (1.68 s -> 0.24 s).
PNG still need to be read in entirely to check their
dimensions; I didn't bother looking into optimizing it
since we don't have many PNG textures right now.
- ZDEBUG2 is now ZDEBUG ... although admittedly, it doesn't seem that useful, it just enables some CONS_Debug's ... but now there's a convenient way to enable them now I suppose
- Mostly just means the I_Errors give __FILE__ and __LINE__.
- Also enables a "memdump" command that just prints a bunch of zone memory info.
I don't think any of this should be guarded, so I went ahead and did this.
All my work thus far on solving the drawflag/renderflag/additive/subtractive conundrum.
Outstandng problems:
* Bad additive/subtractive tables means that they appear opaque except under certain conditions.
* No support for FOFs, Polyobjects, or linedefs in OpenGL yet.
* All OpenGL support mostly done blind, may or may not function in practice.
If nothing else, the hard engineering problems are solved and it's just bug hammering...
