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.
- To really take advantage of this function, I thought it would be useful to be able to add additional models if the user wants to. Let's say you got a player model at index 0. Your gun model has the same frames, but you don't want to duplicate the modeldef data. With generator index, you don't need to duplicate the data, just tell generator index to clone frame data from index 0.
- Implemented a little something to check if a negative skin or model index were passed, and prevent modders from pulling that off.
- Made it so when rendering a model, it clones an smf to use so that data isn't overwritten
- Reimplemented the skin index property. This changes the behavior of this index if CMDL_USESURFACESKIN is activated
- Let's fill the holes of serialized data so it can properly be removed instead of leaving undefined behavior behind.
- Added CMDL_HIDEMODEL flag. This makes a model index invisible.
- Implemented an FString TArray which goes into save files that saves a model file and path, and when the game is loaded, spits back out the model to be Loaded when loading a save file
- Changed some logic when giving an actor that doesn't have a modeldef a modeldef to make sure it knows it doesn't have one when cleared
- Fixed the serialization for modelData. Only problem now is that I was right about needing to push the models on load
- 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
- Made the models and skins arrays TArrays
- The issue I described with models not always reverting to default properly was caused by the fact I was unintentionally overwriting smf data. Now intermediate TArrays store the data before the loop instead of overwriting anything
-Added A_ChangeModelDef
A_ChangeModel(modeldef, modelpath, model, modelindex, skinpath, skin, skinid, flags)
This can change the modeldef, model and skins of an actor.
Currently, modelindex and skinindex accept indices from 0-15.
An actor MUST have a modeldef in order to use this function, either defined from modeldef, or given one through the modeldef parameter. You can pass "" to use the same modeldef. Likewise, passing "" for model or skin will just revert to the default model.
Available flags:
CMDL_WEAPONTOPLAYER - If used on a weapon, this instead change's the model on the player instead.
One issue I am aware of right now is that clearing a model by "" sort of works but is buggy. For now you can just manually set the model back using the names explicitly. However, I am stumped and I think getting more eyes on it would help.
Instead of allocating everything on the heap as single blocks, use a value TArray and allocate the frame arrays from the texture manager's memory arena, since lifetime of the data is identical.
Most importantly this avoids using a variable size array at the end of the struct.
Move the initialization before BaseFileSearch is called, otherwise
GameConfig is used not initialized and it doesn't find the gzdoom.pk3
file.
GameConfig used uninitalized was spotted by @LoneFox78.
This allows dumping a lot of shit code using deprecated Windows functionality and bringing the code in line with Microsoft's roadmap for terminal/console functionality.
Note that this will cause garbled output of non-ASCII characters on Windows 7 and 8.1, but proper handling on these declining systems is of far lesser importance than future-proofing the feature.
