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.
Add a binary table format and convert the text entries into this format in text_helper/main.py. It then gets compressed with zx0.
The new text_data_table and streamed_data_table classes exist to read the various entries from this binary table. streamed_data_table specifically
exists to use a decompression buffer that is smaller than the actual binary table. But it requires a decompression buffer that is
still larger than ZX0_DEFAULT_WINDOW_SIZE (default: 2048 bytes) and will only be able to decompress in
chunks of (<decompression_buffer_size> - <ZX0_DEFAULT_WINDOW_SIZE>) bytes
Try to keep the binary text tables sufficiently small though, because since zx0 doesn't actually support random access,
getting to the last entry is significantly more expensive than reading the first one. And unless you use streamed_data_table,
it also requires <uncompressed_size> bytes of stack space, therefore IWRAM to decompress them.
I also had to rework script_array because it can no longer reference the strings directly. Instead we now reference the DIA_* "enum" values.
We also no longer store an array of script_obj instances, because these were getting stored in IWRAM since they're non-const global variables
originally. Instead we now have const arrays of script_obj_params structs, which should end up in .rodata -> therefore EWRAM.
Right now, script_obj only supports the PTGB text table (originally the dialogue array). But if the need arises to support other tables as well,
I'd consider adding a separate enum to script_obj_params to indicate the specific table.
The compilation process will also output .su files in the build folder from now on. These files indicate the stack frame size for every function in
every compilation unit, so be sure to check them from time to time. Note that they will only show the stack consumption for that specific function.
So to get the worst case stack consumption, you need to manually add all the functions in a certain stack flow.
This commit removes all references to things in the libstdc++ library to remove a decent chunk of bloat.
This means every std::to_string() call, std::string and std::vector. (as well as iostream related stuff).
I replaced those with my own versions ptgb::to_string() and ptgb::vector. Especially the latter is not exactly the same,
but close enough.
I also replaced operator new and delete with my own implementation to avoid pulling in everything related to exceptions
from libstdc++
Another problem was the fact that libtonc uses siscanf, which pulls in everything related to the scanf family of functions
and locale support. The worst part of that was that it included a 13KB "categories" symbol from libc_a-categories.o,
which was pulled in because of the locale support integrated into newlibc's siscanf() function. To fix that, I created a
custom, extremely restricted implementation of siscanf. libtonc only used this function to parse at most 2 integers from a
string anyway.
The reason for this functionality is that some flashcarts *cough* EZ Flash Omega (DE) *cough* can't be hotswapped IN. When you try this, they will trigger a reset of the gba.
This is only relevant for the use case in which you first launch the rom from a flashcart in the first place.
I suppose this can only be relevant for flashcarts which offer "single cart mode". (mode B for EZ Flash Omega).
So, I added an option to upload the rom to another GBA from the "game_load_error" screen if you press the SELECT button.
So, with this change, you could
- launch Poke Transporter GB on GBA 1 from a flashcart.
- eject the flashcart on GBA 1
- make sure the EZ Flash Omega or other "single cart mode/mode B" capable flashcart is set to this mode.
- insert this flashcart into GBA 2
- connect GBA link cable (narrow plug on GBA 1, wide plug on GBA 2)
- Power on GBA 2 and press both SELECT and START while the gameboy logo is still shown
- On GBA 1, in the "game_load_error" screen, press SELECT
- On GBA 1, now press A -> The multiboot upload will now start
- Once finished, GBA 2 will now be running Poke Transporter GB as well
- GBA 2 will recognize the gen III save!
- You can now disconnect the GBA link cable and turn off GBA 1. (you may use it later for the GBC game alongside a GBC link cable to start the actual PKMN transfer)
