Commit Graph

24 Commits

Author SHA1 Message Date
GearsProgress
1f29379810 Linking textbox creation to string display 2026-03-14 10:16:16 -04:00
GearsProgress
209dbcf2ce Fixing merge conflicts for PR 117 2026-03-11 11:02:02 -04:00
The Gears of Progress
2482bb486b Modifying decompression function to be based on indexes 2026-01-11 17:09:30 -05:00
The Gears of Progress
1055094ab9 Modifying text_helper to not have static text sections 2026-01-11 15:02:16 -05:00
Philippe Symons
a7b2703bf8 Replace the PCCS code with a git submodule
This eliminates duplicate code. - Only maintain the code in one place!

To make sure the submodule is getting cloned too after cloning Poke_Transporter_GB, execute:
git submodule update --init --recursive

To update the submodule to a newer commit/different branch:

cd PCCS
git pull
git checkout <commit_or_branchname>
cd ..
git add PCCS
git commit
git push

The way it works is that a specific commit is tied to your Poke_Transporter_GB repository's PCCS folder.
2025-11-27 23:14:29 +01:00
The Gears of Progress
ba1a075701 Adding PCCS 2025-10-12 15:08:33 -04:00
The Gears of Progress
a0793c72c0 Fixing issues before implementing the CPCS 2025-09-20 17:17:20 -04:00
Philippe Symons
47cd143de6 Replace ZX0 by the builtin LZ10 compression.
LZ10 decompression is builtin to the GBA's bios, so we don't need ZX0. It's also significantly faster
(618 usec instead of 2311 usec in my personal benchmark code for decompression of the same data)

And it seems like by doing so, we saved 1 KB as well!

So, seems like replacing ZX0 is the right move.

The reason I didn't initially is because I misunderstood the documentation. I assumed LZ77UnCompWram could only uncompress into EWRAM, not IWRAM.
But it turns out it can do both.

And using standardized tools is usually better than using a custom implementation.

The only downside of this right now, is that we can no longer stream text tables through a smaller buffer than the entire decompressed size.

Anyway, things seem to work fine, so bye bye ZX0. It's been fun.
2025-07-18 16:19:34 +02:00
Philippe Symons
ce4c807bab Merge branch 'optimizations/reduce-binarysize-remove-libstdc++' into optimizations/implement-zx0-compression 2025-05-25 22:45:47 +02:00
The Gears of Progress
e5375b9155 Fixing post-transfer text box 2025-05-25 15:41:09 -04:00
Philippe Symons
26fd1e2dd3 Add compression for the text data, output stack usage .su files and rework script_array
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.
2025-05-21 12:21:06 +02:00
The Gears of Progress
a369e08093
Merge branch 'master' into feature/upload-rom-as-multiboot-to-other-gba 2025-04-06 12:37:47 -04:00
Philippe Symons
93a6c0f3fe Add functionality to upload Poke Transporter GB to another gba after it has started on the current one [EZ Flash Omega]
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)
2025-04-03 23:31:24 +02:00
The Gears of Progress
b267912687 Continuing box updating 2025-03-27 14:37:47 -04:00
The Gears of Progress
8160bcd276 updating box menu, pre sprite grabbing 2025-03-22 15:57:22 -04:00
easyaspi314
e4ef25e20e Compress the graphics (mostly), fix potential vram memcpy issue
This greatly decreases the ROM size, from 245 KB to 198 KB with no visual
changes (that I am aware of)

Changes:
- Enable compression on every graphic but the Pokemon sprites (which are
  too large for the GBA to decompress).
- Change grit from emitting .s files to .c files so GCC can strip unused
  palettes and maps
- Fix the empty tiles
- Trim down the font to skip 00-1F and 80-FF which were all zeroes
  - needs a slight workaround because the Pokemon name display was printing
    an invisible FF byte
- Switch memcpy to tonccpy which is vram safe
- Limit palette sizes.

Signed-off-by: easyaspi314 <6258309+easyaspi314@users.noreply.github.com>
2025-01-17 19:32:48 -05:00
The Gears of Progress
3b945ecf3e v1.1.0 2024-11-01 22:54:05 -04:00
The Gears of Progress
3728db9f72 Final push!! 2024-08-23 17:50:17 -04:00
The Gears of Progress
1ec09842ad Updating tons of graphics 2024-08-19 14:47:29 -04:00
The Gears of Progress
b7f056ce79 Updating Dex Graphics 2024-08-08 16:07:43 -04:00
The Gears of Progress
7aa6933dd6 Fixing crash 2024-07-05 19:20:05 -04:00
The Gears of Progress
e0f78a3195 Finalizing beta v2 2024-05-29 13:11:44 -05:00
Remnants of Forgotten Disney
301ccf602b Finalizing Red/Blue Payload 2024-04-07 16:46:39 -05:00
Remnants of Forgotten Disney
a27f1c2c37 Continuing transfer menu implementation 2024-04-02 12:19:06 -05:00