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.
I think this shows a fundamental misunderstanding of what constexpr means, even when declared as such it requires a constant argument to be treated as a constant.
But since nearly all uses of this were not using constants, the compiler was emitting actual memory accesses to the array each time this was 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.
