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.
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.
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.
- 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.
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 stuff is software rendering only so should be made optional anyway.
But aside from that it was the last non-sound data, being loaded into the cache.
With this gone the sound cache can be redone as a dedicated object and the atrocious cache1d implementation be tossed out.
The map isn't necessarily "corrupt", but it has a large water sector with half a dozen different SE7 teleporter sprites in it, of which all but one have destination SE7 sprites that are constantly moving while the matching SE7 in the large sector stays in place. When you teleport, the game code picks one. It doesn't always pick the one that matches.
Yeah, OK, it never picks the one that matches.
The area is a total clusterfuck.
git-svn-id: https://svn.eduke32.com/eduke32@8241 1a8010ca-5511-0410-912e-c29ae57300e0
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.
For Duke Nukem and its direct offspring (Nam, WW2GI and Redneck Rampage) the ramp is not a linear fade from 0 to 1, it needs to be a little darker than that.
Unfortunately the proper factor needed here must be set manually, this cannot really be calculated from the lookup tables.
Something about their data preparation is not right, their depth looks totally off and causes fog to become to dense.
One more reason to reconstruct the renderer in a sane fashion.
Although this initially helped, it was only because it partially covered up the issues from the real problem which was using the sampler properties of the texture offsets.
With that one fixed this cache became pointless.
Models are currently non-functional and need to reroute their texture handling to the global texture manager instead of handling everything themselves.
Voxels also need a bit of work to make their texture management more automated.
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.
- 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.
