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.
I have no idea how this is supposed to work, but all it does is create corrupt images, so for now it reverts to the software renderer which generates working 320x200 images.
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.
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???
* 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.
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.
* 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.
- 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 Steam/GOG path getters were taken out of the frontends.
This also switches the Windows directory reader touse the wide string version to get Unicode file names.
Some paths were added to the config file instead of hard coding them.
Some part are not done yet, and the file system data is currently ignored - there's no way to properly set this up with the file system code Build came with.
This removes all unused parts of the implementation and moves the rest to the InputState class for easier replacement later. All MACT is doing now here is to call the UpdateStatus function, the internal workings are no longer relevant.
- write the console log to the folder returned by M_GetDocumentsPath and not to the root game directory.
- removed G_ExtPreInit because it has become redundant. The search path setup will have to be redone anyway.
Also removed the entire cruft related to this - the pointless offsetting value and the precalculation of the timer value (as if we could not afford a single division for something that WAITS!
Unfortunately this required removal of the menu option for the time being.
Blood was fine, albeit with an inverted scale, but the EDuke implementation was something very special - and not in a good way, using 4 CVARs to store the scaling state instead of one.
This is a lot of changes in a lot of code because nothing here was abstracted into the sound system. :(
Hopefully most of the affected code here can be tossed out soon, it's not pretty.
This is going to be a lot of work consolidating the 3 frontends' settings but a necessary evil for eventually getting Shadow Warrior to work as it is quite lacking here.
In this case a different open function is used because this is normally files on the hard drive and not assets, so being able to have a different setup for finding them is important.
Note: enet uses 'malloc' and 'free' as field names in a struct - this does not work with any compiler using some sort of heap instrumentation that #defines these names!
This had to be changed to allow MSVC debug builds to compile again.
- consolidated Polymost precaching and removed precaching for static tiles because they now are always loaded.
- removed cache configurability. On modern systems this is relatively pointless - allocating 50 or 100 MB is a non-issue - and the cache is due for replacement anyway.
Sorry, but having a globally writable pointer to every texture is just insane and makes any functional management impossible.
This is merely a preparation for adding a real texture manager. That cannot be done if any code can write over the data at will. For that, it now has to make the texture writable first or create a writable empty texture.
These will have to do some texture management bookkeeping so directly changing the values is problematic.
This required changing the parameter interface in polymost.cpp because a few places hacked around with the global state to pass parameters to subfunctions.
- also removed the legacy fog modes because their implementation did not mix well with the texture system - they are also not really useful to begin with.
The last fog mode will most likely also be removed once true color shading is working but that one is less of an issue.
Unfortunately nothing of this can be fixed before the resource management has been refactored from the ground up. Sp for now this ugliness needs to suffice.
Renamed all elements still referring to zdoom.
removed the frontend specific resource data.
fixed startup dialog to accept ANSI date despite building as Unicode. This needed a bit of hackery because the macros in windowsx.h are not character set sensitive.
The EDuke32 and RedNukem frontends are working, Blood isn't yet.
Notes:
many of the CMake variables and its output still refer to zdoom. Before changing that I wanted to make sure to be able to commit something that works.
support code for Windows XP has been entirely removed. On Windows this will only target Vista and up.
the crc32.h header had to be renamed to deconflict from zlib.
several Windows API calls were changed to call the A-versions directly. Weirdly enough there were places that defined their parameters as T types but in a non-working way.
removed some remaining editor files and support for the native software rendering only Windows backend.
in a few simple cases, replaced 'char' with 'uint8_t'. The code as-is depends on chars being unsigned which is non-portable. This needs to be carefully reviewed.
