Goals include:
* To recover emulator code into a working state (using SDL2 as I cannot
use the Windows library)
* To allow memory management in emulator to not mirror the intricacies
of the calculator version (eg. aSystemStack, aVRAMBuffer, etc)
* To recover actual printf-style error messages on the calculator
* To use the standard library and avoid random reimplementations of
functions
* And other code cleanups that are only possible with CGDoom-specific
header files, instead of the mix in platform.h and os.h
It's a 32-bit-access-only heap. On the Ultimate Doom WAD the amount of
data moved is about 17 kiB, which is not a lot, but arrays with 4-byte
elements are not easy to find in Doom.
This occurs if all texture IDs on a particular line are multiples of
256 (like STARGR2 = 256) since the cast to boolean (byte) destroys
significant bits.
Cumulating lengths will allow a binary search for faster lookup. This is
important because performance seems to vary wildly with the number of
fragments, which I suspect is related to the linear search algorithms
(as there are often several hundred fragments).
Performance had dropped to 3.5s from 2.9s since last test, and
surprisingly this change pulls it back up to 2.9s, even though the
number of fragments now (150) is still more than during the first test
(100).
I suspect binary search will improve performance again. This would be
very helpful, as it would prove that WAD access is the primary
bottleneck for the game. Unlike actual game code, WAD access is
something we can look at and even optimize.
This change adds proper key control by querying the KEYSC directly
instead of using PRGM_GetKey(). This allows for the very distinctive
advantage of pressing multiples keys at once.
Controls are still quite hard to use, I'll think of an alternative
keymap.