For main resource data this is probably unnecessary - most resources are never cached with the exception of sounds and textures, which are loaded permanently anyway.
But for hardware textures this is different. Due to the poor precaching it is impossible to selectively evict hardware textures that are not needed any longer, so for this an MRU cache is really needed so that they do not accumulate and congest the video RAM in the process.
That's one more third party dependency down.
Not only are two hashing algorithms redundant, there was also a large size discrepancy: SuperFastHash is 3 kb of source code while xxhash is 120kb and generally extremely awful code.
It was easy to make a choice here. None of the use cases require this kind of performance tweaking, the longest hashed block of data is a 768 byte palette.
Unfortunately this means that looking up ID 0 can be a bit more costly than the rest because all ID-less entries in RFF files also use 0.
For other file types -1 is used.
* moved the binding commands to osd.cpp. They were in the global namespace already and this way everything to be tossed out is in the same place when the time comes.
* removed support for the OSDs native CVARs. The only ones left were some internal ones I won't need until this code can be replaced.
* same for the custpmization code the games added. Duke Nukem was the only one anyway to have a decent font for it.
I think this shows a fundamental misunderstanding of what constexpr means, even when declared as such it requires a constant argument to be treated as a constant.
But since nearly all uses of this were not using constants, the compiler was emitting actual memory accesses to the array each time this was used.
It's still not active but now should produce correct results when working inside the file system.
What it is missing is a file scanner that picks the data it needs to process.
- disabled the user maps menu because it is hopelessly dependent on functionality that cannot be fixed. Better wait until the menu refactor to do it right - it'd be a waste of time fixing the current menus.
* saving of demos and savegames no longer mindlessly writes to the mod directory. All such access is now being rerouted through the special paths interface so that the game data can reside in write protected locations.
* refactored all occurences of klistpath except fnlist_getnames.
* do not allow CON scripts to write to arbitrary files. This is a massive exploit and can be used to cause real damage if someone knows how to play this thing - it's far easier than people may think! It will now write any such data to a special section in the main config which is safe and cannot be manipulated to write to random locations on the hard drive.
- consolidated the 3 identical S_OpenAudio implementations. The replacement code is disabled for the time being because it needs a rewrite. The replacement logic is uses is a bit too volatile.
- removed the old GRP scan code.
* reroute several error conditions to I_Error.
* removed some soon-to-be obsolete GRP loading code.
* explicitly trigger the SetDefaults script events which depended on side effects from the config implementation.
* removed the nonsensical file system switch. All this does is create instabilities because it is non-obvious from where data is loaded. If a resource is mounted, it should be checked for content no matter what. While this may affect the stray weird mod out there it is a necessity if we want to allow transparent project repackaging.
When doing this during startup it can be done by regular cleanup measures.
This also moves two larger chunks of networking code out of game.cpp.
Nevertheless, the fact that enet is a very dirty library which directly depends on Windows types is a big problem because it bleeds Windows definitions everywhere thanks to poor abstraction in all relevant layers.
The idea here is to completely merge the resource management into the file system so that Blood's DICTNODE is merely an alias to the internal FResourceLump.
A two-tiered resource system is not something I consider worthwile, it made sense to get around Builds crappy cache but in the long term this is not a good solution for a multi-game port to have a resource management system in the backend and another one put over it in the front end, both with their own caching logic that might interfere with each other. Better merge it into one that can handle everything.
Christoph Oelckers
CommonLoon102
hendricks266