I have no idea why they were even in there, as they intentionally circumvented all GC related features - they declared themselves fixed if prone to getting collected, they all used OF_YesReallyDelete when destroying themselves and they never used any of the object creation or RTTI features, aside from a single assert in V_Init2.
Essentially they were a drag on the system and OF_YesReallyDelete was effectively added just to deal with the canvases which were DObjects but not supposed to behave like them in the first place.
Let's use inline checkers in PType instead of constantly having to do clumsy IsKindOf checks etc. Once complete this also means that the types can be taken out of the class hierarchy, freeing up some common names.
src/p_pspr.cpp:363:37: warning: more '%' conversions than data arguments [-Wformat]
src/gl/textures/gl_texture.cpp:845:21: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
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.
A pointer to an object has quite different semantics so let's do this with proper virtual inheritance. This should allow to simplify a lot of pointer related checks in the compiler.
- 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 not needed anymore because classes do not need to be replaced. The only reason this was implemented was the original design with the class descriptors taking on all the metadata themselves.
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.
See https://forum.drdteam.org/viewtopic.php?t=7588
Processing order is now the same as in Chocolate Doom
prBoom+ loads separate files after all WAD lumps though
This makes sense but would change loading sequence existed in ZDoom for years
This is somewhat brute-force thanks to the surprising lack of good documentation for the Ogg headers. The only other option would have been some rather bloated library for a function that should be 25-30 lines at most.
The idea is to have more control on the game side instead of dealing with these formats in the backend, which was done for FMod because it already had the decoders implemented.
However, with OpenAL this setup makes no sense and only complicates future extensions that can be better handled at a higher level.
No more error when running with +map command line parameter with classic HUD:
> VM execution aborted: Attempt to draw to screen outside a draw function
> Called from BaseStatusBar.DrawImage [Native]
> Called from DoomStatusBar.DrawFullScreenStuff at gzdoom.pk3:zscript/statusbar/doom_sbar.txt, line 140
> Called from DoomStatusBar.Draw at gzdoom.pk3:zscript/statusbar/doom_sbar.txt, line 41
