* make all legacy light modes except 'Doom' MAPINFO only. A CVAR still exists for testing but its value won't be saved to the config.
* user can only select between "performance', 'software' and 'vanilla'. 'performance' is the old 'Doom' mode which is still needed to speed things up on low end hardware.
* MAPINFO can not enforce any of the two software light modes, as low end users require the option to change this to the 'performance' setting. Selecting one will always revert to the user's light mode selection.
This also adds the `r_actorspriteshadowalpha` and `r_actorspriteshadowfadeheight`
cvars for greater control (only effective in hardware renderers).
These are set to 0.5 and 0 by default, which means this fading behavior
is disabled by default.
When enabled, this has two benefits:
- It becomes easier for the player to judge an entity's height since
the shadow opacity now gives this information.
- Entities that are far high above the ground no longer cast a shadow,
which looked strange.
This solves two problems:
* The linked list is too slow, a map is better. A map cannot be used with statically allocated CVARs because order of initialization is undefined.
* The current CVAR system is an unordered mishmash of static variables and dynamically allocated ones and the means of identification are unsafe. With this everything is allocated on the heap so it can all be handled the same by the cleanup code.
- MODELSAREATTACHMENTS was basically being applied anyways
- Fixed a crash related to using an animation that never had the vertex buffer drawn because it was never used as a model
- The compile errors should be fixed
- Implemented a way for skeletal models using the MODELSAREATTACHMENTS flag to not upload duplicate bones to the bone buffer
- I need to figure out how I'm gonna reference the same boneStartIndex between the indices. Maybe some property in smf? The problem is that even though the bone calculations are done just once per instance of the actor when the flag is enabled, the bone buffers are being copied still, and if there's too much data, some will quit uploading because it's full. Besides doing this, I may just see about increasing the buffer size if possible. It's really just not very big.
Its only relevant use case has been to use the software renderer on hardware not capable of OpenGL 3.3, but a large chunk of that can now be serviced with GLES.
In addition it has ceased further development and has not received any of the recent 2D render features which further reduces its viability.
This is *not* the right way to reduce function parameter count. The data in question is far easier evaluated at the calling site and passed as a parameter.
- Made the 2 TArrays into a class called DActorModelData.
- Removed the skinindex and now just uses one index
- Replaced a bunch of nullptr for modelDef checking with NAME_None
- Added some garbage cleanup to A_ChangeModel itself, as well as removing memory of modelData that is no longer needed
- Attempted serialize code, putting up for review
