All games combined there's 11(!!!) scene render blocks, not counting the sub-blocks for ROR and mirrors.
Does it surprise anyone that most of these sub-blocks do not feature all engine capabilities?
With all the 2D refactorings thhe softsurface won't work anymore.
This also revealed a bug with the fullscreen variable, a few places were still using the old one from the SDL backend.
- fixed a crash in the 2D drawer when two consecutively allocated vertex buffers had the same address. Strangely this only occured with Exhumed but not the other games
- fixed Exhumed crashing with sound disabled.
This needs to be replaced with the game independent ZDoom version and hooked up properly, but it of low priority because it's a multiplayer only feature.
* removed old sound loading code, which was the last bit to use cacheAllocateBlock which is also gone now.
* cleanup of player sound code. All game side tracking of the sound resources has been removed.
does not compile yet.
* 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.
Why? Because it's fucking useless. If we want to waste CPU on outputting nothing, SDL has us covered with its "dummy" audio backend.
git-svn-id: https://svn.eduke32.com/eduke32@8387 1a8010ca-5511-0410-912e-c29ae57300e0
# Conflicts:
# GNUmakefile
# platform/Windows/audiolib.vcxproj
# platform/Windows/audiolib.vcxproj.filters
# source/audiolib/src/driver_nosound.cpp
# source/audiolib/src/driver_nosound.h
# source/audiolib/src/drivers.cpp
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.
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.
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.
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.
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.
* 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.
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 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.
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.
This needs to be moved into the backend, and partially into the shader. So far this only removes the code from the main rendering logic, the final implementation is not done yet.
It had to go because it required the main rendering code to look deep into the texture data which would be a major blocker for refactoring.
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.
Currently this only contains the main Polymost shaders and the resources from nblood.pk3.
The latter cannot be used yet because the Build resource management system is too stubborn to add the newly added file without some changes.
It's better to refactor the entire system instead.
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.
