Unique RNG namespace for client-side effects and HUDs. Identifiers for these cannot clash with identifiers that affect the playsim making them completely safe to use in HUD elements. They also won't be saved.
cleaned up function interface to avoid referencing the file system in the worker functions.
replaced StringTable's operators with functions.. The main reason is that these are far easier to look up when browsing the source.
This also fixes a premature translation in SBARINFO that was done in the parsing stage, not the printing stage.
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.
This simulates a feature found in Crispy Doom, which keeps the
weapon bobbing while firing. This leads to a "smoother" appearance
which may look a bit prettier to some people.
The default value of 0 preserves the old behavior.
Rationale: while the previous description contains the name of a CVAR, it doesn't specify that it's a CVAR. Unsuspecting user may be not aware that the engine or a mod contains such a CVAR.
Looks I completely forgot this part when refactoring the interface - it must account for the callbacks not doing anything due to the network code not being operational yet.
These were creating dangerous interdependencies. It is better to do explicit conversions when needed.
As an added plus, this means that zstring.h no longer depends on name.h which was very annoying.
With localization for non-Latin languages on the support list the multibyte API doesn't cut it anymore. It neither can handle system text output outside the local code page nor can an ANSI window receive text input outside its own code page.
Similar problems exist for file names. With the multibyte API it is impossible to handle any file containing characters outside the active local code page.
So as of now, everything that may pass along some Unicode text will use the Unicode API with some text conversion functions. The only places where calls to the multibyte API were left are those where known string literals are passed or where the information is not used for anything but comparing it to other return values from the same API.
This setup has been a constant source of problems so now I reviewed all uses of FName to make sure that everything that needs to be initialized is done manually.
This also merges the player_t constructor into the class definition as default values.
- 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.
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.
There's simply never enough of them and they are used far too infrequently to justify the hassle of tagging along two TMaps per class.
For what they provide, single global lists that handle all player classes at once are fully sufficient.
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.
- For most cvars, this is equivalent to calling GetGenericRep() to get a
string.
- For float cvars, it uses %g instead of %H, because %H is generally more
information than is needed.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
