Models are currently non-functional and need to reroute their texture handling to the global texture manager instead of handling everything themselves.
Voxels also need a bit of work to make their texture management more automated.
This needs to be moved into the backend, and partially into the shader. So far this only removes the code from the main rendering logic, the final implementation is not done yet.
It had to go because it required the main rendering code to look deep into the texture data which would be a major blocker for refactoring.
- consolidated Polymost precaching and removed precaching for static tiles because they now are always loaded.
- removed cache configurability. On modern systems this is relatively pointless - allocating 50 or 100 MB is a non-issue - and the cache is due for replacement anyway.
- Some ThrowError() calls was replaced my viewSetSystemMessage()
- New modern type playQAV (WIP)
# Conflicts:
# source/blood/src/actor.cpp
# source/blood/src/weapon.h
- Added names for sprite, wall and sector types
- Added gModernMap protection for using new features only on different version of map
# Conflicts:
# source/blood/src/actor.cpp
# source/blood/src/callback.cpp
# source/blood/src/callback.h
# source/blood/src/triggers.h
Sorry, but having a globally writable pointer to every texture is just insane and makes any functional management impossible.
This is merely a preparation for adding a real texture manager. That cannot be done if any code can write over the data at will. For that, it now has to make the texture writable first or create a writable empty texture.
These will have to do some texture management bookkeeping so directly changing the values is problematic.
This required changing the parameter interface in polymost.cpp because a few places hacked around with the global state to pass parameters to subfunctions.
The only difference was that bloodhack came from NBlood and playing_blood was added for unhandled differences between the backends of EDuke32 and NBlood.
- also removed the legacy fog modes because their implementation did not mix well with the texture system - they are also not really useful to begin with.
The last fog mode will most likely also be removed once true color shading is working but that one is less of an issue.
This makes no sense because it'd toss out all the level textures that may still be needed for what probably is only a temporary palette change (like going underwater)
Christoph Oelckers
Christoph Oelckers
nukeykt
CommonLoon102
Grind Core