The same logic as in GZDoom applies: The root must not have any other content and the subdirectory must contain identifiable game content.
Some handling was also added to strip out macOS resource fork folders because they can contain data that can confuse file detection.
- delete some voxel code that's software rendering only.
- apply Big Endian byte swapping for SFXs, as well, now that this no longer involves hacking the file system cache.
The new movies weren't played because the names did not match.
Transition from the last level of Ep1 to the first one of Ep2 did not work.
Selection with command line switch wasn't reliable.
There's a second variant without this definition, so this needs to be defined internally, and since it needs to be done internally it may receive proper localization labels.
* reverb/echo is not yet implemented, so there's two stub functions for now.
* RTS needs to be done differently, because the sound engine cannot play raw buffers without any control data.
Unfortunately necessary because Ion Fury savegames store 120 GB(!!) of data, mostly zeros.
Unlike the old method, this compresses the entire savegame as one block using a ZLib stream so it should be a lot more efficient now.
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.
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.
