ptgb::vector::resize() had a bug which caused it to incorrectly add/erase elements.
The reason was a loop end condition that was modified during iterations of said loop. This end condition
was intended to be static, but because it used a variable that was modified during the loop, it didn't
repeat the intended number of times.
Fix: before starting the for loop, calculate the end condition once.
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.
libsysbase_libsysbase_a-handle_manager.o
So, I optimized the MOVESETS table to only store the "overriding" bits in the movesets of the evolutions
in relation to their base forms. That only improved compression slightly (about 300 bytes)
I also eliminated 4 KB of IWRAM usage by libsysbase_libsysbase_a-handle_manager.o because of the "handles"
buffer. We're not using it and we REALLY need our IWRAM. (and it also reduces the rom size with 4KB too!)
The ones I moved back as uncompressed tables (EVOLUTIONS and gen_1_index_array) simply didn't compress well
at all. It wasn't worth the runtime decompression cost.
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)
