This was the only code using the ViewBob member variable.
This also moves the range check for this variable to its application, because a badly behaved mod can just as easily change it at run time instead of just setting an absurdly large value in the class definition.
Initially, settings controller flag was false by default
It was not touched during construction and destruction of player_t instances though
Now, with all members initialized in class definition, this flag must be saved and restored manually
https://forum.zdoom.org/viewtopic.php?t=62830
* it was never saved in savegames, leaving the state of dead bodies undefined
* it shouldn't be subjected to pointer substitution because all it contains is old dead bodies, not live ones.
This does not work with a setup where the same backend is driving both renderers.
Most of this is now routed through 'screen', and the decision between renderers has to be made inside the actual render functions.
The software renderer is still driven by a thin opaque interface to keep it mostly an isolated module.
- fixed: The streaming music player must return the file reader if it fails to open, so that the next player can still use it.
- fixed: Timidity++'s Instruments class did not delete the sound font when it was destroyed.
..-
b_game.cpp:537:27: warning: more '%' conversions than data arguments [-Wformat]
g_game.cpp:2982:40: warning: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'long' [-Wsign-compare]
- let FScanner::OpenFile return an error instead of throwing an exception. The exception was never used anyway aside from being caught right away to be ignored.
- moved timer definitions into their own header/source files. d_main is not the right place for this.
- removed some leftover cruft from the old timer code.
For some files that had the Doom Source license attached but saw heavy external contributions over the years I added a special note to license all original ZDoom code under BSD.
This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
Fullscreen HUD done with the exception of key and inventory bar. I also used the opportunity to make it a bit more resistant against badly designed inventory icons.
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.
- added a StartSlideshow ACS and ZScript command and extended the functionality to specify the slideshow's name when starting it.
This is for triggering any kind of intermission definition in the middle of a level - keep in mind that this may not be set up to loop!
This method was chosen because it avoids adding variable declarations to the global namespace which would have required a lot more work while polluting the grammar.
This way the global variables can be handled by a small bit of special coding in the struct generator.
This one was particularly nasty because Windows also defines a DWORD, but in Windows it is an unsigned long, not an unsigned int so changing types caused type conflicts and not all could be removed.
Those referring to the Windows type have to be kept, fortunately they are mostly in the Win32 directory, with a handful of exceptions elsewhere.
The manager class cannot be scriptified because it provides the internal implementation which may change at some point in the future. It also encapsulates all access to the file level because if that part is not protected, modders could write malware mods.
Now all actors have the same metaclass and therefore it will always be the same size which will finally allow some needed changes to the type system which couldn't be done because it was occasionally necessary to replace tentatively created classes due to size mismatches.
- disabled the Build map loader after finding out that it has been completely broken and nonfunctional for a long time. Since this has no real value it will probably removed entirely in an upcoming commit.
Two reasons for this:
1. if this has to be routed through the VM each recursion will cost 1000 bytes of stack space which simply is not good.
2. having the virtual function only care about the item itself but not the entire inventory chain is a lot less error prone for scripting.
Since the scripting interface needs a separate caller function anyway this seemed like a good time to change it. The same will be done for the other chained inventory handlers as well.
After testing with a savegame on ZDCMP2 which is probably the largest map in existence, timing both methods resulted in a speed difference of less than 40 ms (70 vs 110 ms for reading all sectory, linedefs, sidedefs and objects).
This compares to an overall restoration time, including reloading the level, precaching all textures and setting everything up, of approx. 1.2 s, meaning an increase of 3% of the entire reloading time.
That's simply not worth all the negative side effects that may happen with a method that highly depends on proper code construction.
On the other hand, using random access means that a savegame version change is only needed now when the semantics of a field change, but not if some get added or deleted.
- do not I_Error out in the serializer unless caused by a programming error.
It is better to let the serializer finish, collect all the errors and I_Error out when the game is known to be in a stable enough state to allow unwinding.
- always make the top level object randomaccess when opening a JSON file for reading. Some things won't work right if this is opened for sequential access.
