Memory manufacturers and AAA game studios hate her!
With some clever rearranging, PTGB now uses only 36 KiB of the 64 KiB
BG VRAM. This means the remaining 28 KiB is free to use in the future.
Caveats: The flex tileset must not use more that 6 KiB. There is a check
for it added.
VRAM Map
06000000 - 06000800 ( 2K): Eternal backdrop and textbox tileset
06000800 - 06002000 ( 6K): Flex BG tileset
06002000 - 06002400 ( 2K): BG0: Backdrop tilemap
06002800 - 06003000 ( 2K): BG1: Flex BG tilemap
06003000 - 06003800 ( 2K): BG2: Textbox tilemap
06003800 - 06004000 ( 2K): BG3: Text tilemap
06004000 -~06009000 (20K): Text rendering bitmap
06009000 - 06010000 (28K): Free work RAM
06010000 - 06018000 (32K): Sprite tileset
Additionally:
- Explicitly clear VRAM on boot
- Dirty workaround to fix box drawing buffer overflow.
- Flex backgrounds use a table instead of a huge switch statement
- Textbox tile IDs are now const u16[] instead of int[]
text_data_table was very similar in concept to FileContainerReader.
But FileContainerReader is generally more flexible, as it allows you to split up your table into several chunks.
This takes away the worry of these files getting too big to compress.
However, we now have a maintenance duty for the text_tables file, which maps a table index to the list of chunks.
We also need to be careful about every use of FileContainerReader::getPointerToFileInDecompressionBuffer().
Using it is fine when you're dealing with a single chunk or if you're sure the file doesn't span multiple chunks.
But the moment you seek to a different chunk, any pointer obtained from getPointerToFileInDecompressionBuffer()
becomes stale as the decompression buffer gets overwritten.
Still, this function is necessary for high memory pressure situations, such as mystery_gift_builder, because we can't maintain
multiple lineBuffers there.
This allows us to log to mgba's logging window.
It will be very useful to debug issues.
But we only allow enabling this for debug builds for license reasons.
This adds a lot of the debug_mode.h options as an option you can modify at runtime.
I also moved both the text debug screen and the regular debug info screen in there.
And I added an option to start song playback.
This commit integrates the MaxMod sound engine into PTGB.
Some test code already existed, but now it's done for real.
I added a thin API wrapper in sound.c/sound.h to abstract the sound engine.
One of AquaticAlloy's test songs was added to the main menu as a proof of concept.
We may want to disable it before the actual merge though.
I found another way to optimize the rom space by implementing a custom malloc, free, realloc and calloc
function.
This reduces rom size by 3 KB and IWRAM usage by 1 KB. (elimination of __malloc_av). The original
implementation is much more complex and larger than it needs to be.
The custom malloc is implemented as a bitmap allocator. It keeps a bitmap to track which pages of the
heap are allocated. Like the original allocator, it uses the free space in EWRAM after the multiboot gba
rom. But unlike the original allocator, we control the size with CUSTOM_MALLOC_POOL_SIZE.
The custom malloc can be disabled with USE_CUSTOM_MALLOC.
There was a crash happening with ptgb::vector when you'd press A on the CONFIRM button of the box screen. It only occurred on actual gba hardware and
was a real heisenbug: as soon as you'd add code to display logs on screen, the problem would disappear. So it was very difficult to figure this one
out. We're not even entirely sure why, but it looks like the malloc/realloc/free use in ptgb::vector would cause issues.
Maybe it was alignment, but after messing with the code we also saw a warning appear in the terminal telling us that realloc wouldn't properly
deal with non-POD types. It complained about this very thing while referring to the add_track() function, which stores ptgb::vectors inside another
ptgb::vector. We also didn't have a custom copy constructor yet to actually copy the buffer instead of its pointer.
All of these could potentially have led to the crash. But debugging during the link cable flow was difficult, so we were never able to confirm it in
a debugger, log or dump.
Because I suspected the high IWRAM consumption (especially now with ZX0 decompression) for a while, I also did an optimization in mystery_gift_builder
to pass global_memory_buffer as its section_30_data buffer instead. This reduces IWRAM consumption by 4 KB.
There was another problem I discovered during my crash hunt: the out_array (now payload_buffer) was allocated as a 672 byte array, but the payloads
were actually 707 bytes. Therefore writing this to the buffer caused a buffer overflow, thereby corrupting the global variables appearing after it in
IWRAM. It turned out eventually that none of these variables were really critical, but it could explain some minor bugs GearsProgress has seen.
I also did a few performance optimizations:
- At various stages in the code, for loops were used to copy data from one buffer into another byte-by-byte. This was far from optimal because the gba
cpu can load/copy 4 bytes at a time if you ask it to. So I replaced those with memcpy(), which is a hand-optimized assembly function to copy data
using this principle.
- generate_payload was being called twice: once at start_link and once at continue_link, giving the exact same result, even though it was already
being stored in a global buffer allocated in IWRAM. This was also a fairly heavy function. So I optimized the code to only initialize it once in
the script chain and then just retrieve the buffer.
- generate_payload was constructing the eventual payload twice even within the same call. That's because it first merged z80_rng_seed, z80_payload
and z80_patchlist into a full_data ptgb::vector, after which it then copied the data again to out_array (now called payload_buffer). I eliminated the
full_data vector now.
