Fixed bunch of compilation errors:
cannot pass non-trivial object of type 'FString' to variadic method; expected type from format string was 'char *' [-Wnon-pod-varargs]
Fixed linker erorr:
g_doomedmap.cpp.o: In function `InitActorNumsFromMapinfo()':
src/g_doomedmap.cpp: undefined reference to `PClass::FindActor(FName)'
Combining these two groups of data has been the cause of many hard to detect errors because it allowed liberal casting between types that are used for completely different things.
Having these two types related can cause problems with detection in the compiler because for some parts they need quite different handling.
Common handling for the fields has been moved into PSymbolTable but overall redundancy was quite minor as both types share surprisingly little functionality.
- fixed: IsVisibleToPlayer and optimized it a bit more.
- moved SourceLumpName to PClass, so that it can also be used for non-actors (there's a lot of non-Actor classes already.)
- separated the serializer for PClassPointer from PPointer. Even though not doable, a pointer to a class type is something entirely different than a class pointer with a restriction so each should handle its own case.
- added a few access functions for FActorInfo variables.
With PClassActor now empty the class descriptors can finally be converted back to static data outside the class hierarchy, like they were before the scripting merge, and untangle the game data from VM internals.
For these fields maps have no advantage. Linearly searching a small array with up to 10 entries is nearly always faster than generating a hash for finding the entry in the map.
- some optimization of access to OwnedStates in old DECORATE.
- consolidate all places that print a state name into a subfunction.
- allocate states from the ClassDataAllocator memory arena. States do not need to be freed separately from the rest of the static class data.
This reinstates the old FActorInfo as part of the meta data a class can have so that the class descriptor itself can be freed from any data not directly relevant for managing the class's type information.
This is an incredibly costly way to do a debug check as it infests the entire VM design from top to bottom. These tags are basically useless for anything else but validating object pointers being passed to native functions (i.e. mismatches between definition and declaration) and that simply does not justify a feature that costs execution time in non-debug builds and added memory overhead everywhere.
Note that this commit does not remove the tags, it only discontinues their use.
- decided to ditch the widget system I had started to lay out. As it turns out that would make things far more complicated and slower than they need to be.
This makes VMValue a real POD type with no hacky overloads and eliminates a lot of destructor code in all places that call a VM function. Due to the way this had to be handled, none of these destructors could be skipped because any value could have been a string.
This required some minor changes in functions that passed a temporary FString into the VM to ensure that the temporary object lives long enough to be handled. The code generator had already been changed to deal with this in a previous commit.
This is easily offset by the code savings and reduced maintenance needs elsewhere.
Note that the Strife status bar does not draw the health bars yet. I tried to replace the hacky custom texture with a single fill operation but had to find out that all the coordinate mangling for the status bar is being done deep in the video code. This needs to be fixed before this can be made to work.
Currently this is not usable in mods because they cannot initialize custom status bars yet.
It used the expression's value type, but needs to use the variable's, which can be different when the assignment is synthesized from a builtin function.
- keep string registers which are being used as function parameters allocated until after the function call returns. This is for allowing to pass strings by reference which would avoid some costly constructor/destructor loops in the call instruction.
