Sound is only partially functional, video mode completely nonfunctional, but it makes no sense adjusting them to the current backend code when it's due for replacement.
Reverted this to a sane setting, as it was in the original games and in all other games I have ever seen, i.e. there is a global setting to enable mouse view, and a button to manually trigger it. The toggle can be easily handled by flipping the CVAR directly.
The main problem here was that it triggered a few cases for mouse-less gameplay in the default case with a mouse present, because the mouseaim CVAR was no longer what the game expected.
This misguided change seems to have originated in JFDuke but by now had propagated to all the other games as well, the code was in all 4 frontends.
- hooked up all front ends with a generic message printing function so that common code can access the native message displays. This is needed for consolidation of some input actions which are mostly identical but print messages.
- preparations for a generic message system.
This was consolidated for both EDuke and RedNukem frontends, put into a class with strict access control and the length limit was lifted.
The new class will eventually allow better localization control.
- disabled the mouse movement sensitivity CVARs pending a refactoring of the code to handle them in the input backend instead of the individual input handlers.
Now this was magnitudes easier than the EDuke menu - NBlood's menu is actually clean and usable code but still nothing compared to a unified menu system.
This mainly means being able to use the generic font.
This also adds more generalization to the menu sound handling, plus an option to turn menu sound off. This is motivated by the pig sounds which RR uses in the menu.
* removed some redundant functionality (e.g. Shift-F5 to change - use the console for that!)
* removed a few more leftover parts of the old music system
* savegames should not do more than resuming the music at the point of saving. (DN3D and RR only so far. Blood to be done.)
* handle music enabling/disabling in the backend, which simply knows better what to do. This was only working in the menu, so changing the CVAR had no effect.
* implemented single image screens
* implemented skeleton of the image scroller
* added RR-specific definitions to the menus (need to copy and adjust d_menu.cpp)
* added definitions for credits screens.
Sadly the scripting which necessitates this all is such a hack that it's probably necessary to fix again if the next project comes along that uses the same kind of "creativity" instead of providing a robust implementation.
Not tested yet!
* Added a JSON-based header to the savegames so that the unified menu can read from a common data source.
* moved loading and saving of frontend independent data to the wrapper so that support is automatic.
Just for the menu this can be done much simpler - the entire setup here doesn't work well with the game frontends being compiled as separate modules anyway.
This looks like an ImGui bug - it doesn't like two identically labelled buttons on the same page, it seems. I now work around this by using strings with different numbers of spaces. Stupid but effective.
Since the code is extremely volatile I changed the setup so that the save is a zip file with the regular snapshot plus all added data as separate entries.
This allows compressing everything properly without savegame breaking interference.
Blood does not yet load its savegames, need to check.
Conmsidering how hard it is in Duke Nukem based games to modify the level music, there is now a setting for this in mussetting.txt to make the job easier and even allow setting level music in Redneck Rampage without replacing game data.
- draw fullscreen blends below the console.
- moved all mouse event processing out of the SDL backend to D_PostEvent.
- removed all remaining code for dealing with mouse buttons directly.
Not only is this a deprecated feature - it also does not work right when complex lighting is at play, it must be done in the shader to get proper results.
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.
This broke the savegame reader which still assumed it was working on compressed data. Everything will now take the uncompressed path.
In-stream optional compression is not a good idea anyway, this can and should be done better.
Also: Why is the savegame format architecture dependent???
This is still just glue code, the Build implementation suffers from poor support for multiple keys bound to a single button so they are due for replacement as soon as input is working again.
* moved the ASCII conversion hackery in SDLayer to a subfunction because this made things just messy.
* integrated the keyboard callback's functionality directly into inputState for consolidation purposes. This was yet another independent layer in the keyboard management.
* hook up D_PostEvent as the central place to dispatch keyboard input. This is now the only function that is getting called from the backend and a major prerequiside for swapping out the backend for GZDoom's.
Todo: Route mouse input through that, too.
Unfortunately this means that the keybinding menus in all games except Blood are shot to shit right now because of how they passed the data on to its destination.
These menus are not fixable, this will have to wait until the replacement is up.
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.
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.
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.
