Commit Graph

10 Commits

Author SHA1 Message Date
Cyphgirl 1d3441da53 Extract palettes and rebuild BG sheets from assembled screens
Removes 74 baserom incbins (104,512 bytes) and makes every background
tile sheet in the game readable and correctly coloured, byte-for-byte
identical to the ROM throughout.

Palettes
- Extract 69 standalone palettes to JASC .pal, built via the existing
  %.gbapal: %.pal rule. gbagfx's gbapal->pal direction pads anything that
  is not 16 or 256 colours up to 256 (gfx.c:822), so the JASC is written
  directly from the ROM bytes and gbagfx only does pal->gbapal.
- Convert the 9 legacy raw-binary .pal files to JASC, so a single .pal
  format exists. dusclops_anim held 496 colours, over the JASC limit, so
  it becomes 31 per-frame files.

BG sheets (tools/scripts/detilemap.py)
- BG tile sheets are deduplicated, so the raw sheet is unreadable as an
  image at any width. The checked-in source becomes the assembled screen
  (8bpp, pixel = bank*16 + index, which keeps every per-cell palette bank
  distinct) and detilemap folds the screens back through their tilemaps.
- Covers all 9 intro scenes and all 8 boards: 21 sheets.
- Ruby and Sapphire stream their board through a 22-slot scroll ring, so
  a tilemap row R draws chunk R of a virtual bgtop+bgbottom strip rather
  than indexing the sheet. --row-chunk handles that; the model is written
  up in data/board_data/VRAM_LAYOUT.md.
- 8 sheets have non-blank tiles no tilemap reaches (BG0 tilemaps are built
  at runtime); --extra carries them rather than silently zeroing.

Build
- .SECONDARY was unscoped, which marked $(OBJS) secondary too. Make does
  not rebuild a missing secondary file when its dependant looks current,
  so deleting an object and running `make compare` relinked a stale ELF
  and printed OK. Now scoped to generated art and audio. .PRECIOUS with
  patterns would be terser but defeats .DELETE_ON_ERROR, which would let
  a half-written .4bpp produce a wrong ROM silently.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:50:59 -04:00
Retnuhytnuob ac86c24005 Merge pull request #235 from Cyphgirl/extract-shop-data
Extract shop data
2026-08-07 03:37:59 -05:00
Cyphgirl 73ca456669 Extract the coin arrows for both boards
57 pieces out of baserom.gba, in colour. ROM still matches
(make compare).

Three groups per board, one per coin value, each with lit variants of
three pieces. The two boards differ in table shape: ruby has four
variant rows with the destinations fifth, sapphire has three plus a
destination row and a row of spacers. Ruby repeats the first variant in
groups 0 and 2, so 57 distinct pieces cover the 72 slots.

Piece 2 of groups 0 and 1 is never copied on either board -- their
destination overlaps the next group's piece 0 -- so there is no DMA size
to take. Those 13 are extracted at their full declared span instead.
Everything else uses the size from DrawRubyCoinRewardMeter and
DrawSapphireCoinRewardMeter.

Palettes are bank 9 of gRubyBoardPalette and bank 11 of
gSapphireBoardPalette, both tilemap-attested. The two boards do not
match here: ruby's coin arrows are green with white numerals, sapphire's
are light blue with white numerals, which is what the field scans show.
Sapphire bank 0 is also blue and scores within 3 RGB units of bank 11
against the scan, but it is navy where the board art is clearly light
blue, so the render decided it rather than the distance.

Left alone: graphics/stage/ruby/ruby_coin_arrows.png, an earlier
extraction of the whole 0xC00 block as one 256x24 sheet, still
referenced by a commented-out incbin above the first symbol. It matches
baserom exactly but cannot be wired up without collapsing the 30
individual symbols, which is presumably why it was left commented. It is
now redundant and could be removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 23:31:17 -04:00
Cyphgirl b7a58383ea Extract the get arrows for both boards
60 pieces out of baserom.gba, in colour. ROM still matches
(make compare).

Same shape as the evo arrows: three letter groups spelling GET, each
with a set of variants for the lit progression, each variant three
pieces going to three VRAM destinations one tilemap row apart. Group
sizes differ per piece (0x40 or 0x60) and were taken from the
DmaCopy16 calls in DrawRubyCatchArrowProgress and
DrawSapphireCatchArrowProgress. Groups 0 and 2 repeat their first
variant, so 60 distinct pieces cover the 72 table slots.

30 symbols span more ROM than is copied; the remainder is .space where
blank (22) and a baserom incbin otherwise (8).

Palettes are bank 8 of gRubyBoardPalette and bank 11 of
gSapphireBoardPalette. Both are referenced by their board tilemap at
these tiles and both render the arrows red-orange with a white letter,
matching the Ruby and Sapphire Field scans. Index layouts differ per
board again: ruby draws the body at index 5, sapphire at index 7.

Note these are the "Catch 'em Arrows" in the Bulbapedia legends; the
symbol and function names disagree with each other already
(gRubyGetArrowTilePtrs drawn by DrawRubyCatchArrowProgress) and were
left alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 23:23:35 -04:00
Cyphgirl 4c6f2013a4 Extract catch, hatch, mart and bumper arrows for both boards
78 arrow rows out of baserom.gba, in colour. ROM still matches
(make compare).

Each arrow is four rows that go to four separate VRAM destinations one
tilemap row apart, with an off and an on state (mart has four states:
mart off/on and evo off/on, since the ramp is shared). Row widths are
not uniform -- they run 2 to 5 tiles -- so the copied size per row was
taken from the DmaCopy16 calls in ruby_board_indicators.c and
sapphire_board_indicators.c rather than assumed from the symbol spans.

22 symbols span more ROM than the game copies. Only the copied part is
extracted; the remainder stays as a baserom incbin, or .space where it
is blank (6 of them).

gSapphireBumperArrow_082E0860 and _082E08E0 are skipped: they are
already .space, and both the table comment and the fact that
AnimateSapphireBumperArrowPalette only copies rows 1-3 confirm row 0 is
unused.

Palette is bank 11 of gRubyBoardPalette / gSapphireBoardPalette. That
bank is the only one on either board that is both yellow at the arrow
body index and actually referenced by the board tilemap at these tiles.
The two boards do not share index layouts -- ruby draws the body at
index 10 with outline 15, sapphire at index 4 with outline 11 -- so each
was decoded separately. Checked against the Ruby and Sapphire Field
scans on Bulbapedia, where all four arrow types on both boards are
yellow with a dark outline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 23:18:37 -04:00
Retnuhytnuob 99c486a41d ruby tilemap 2026-07-28 15:57:50 -05:00
Retnuhytnuob 1d633482cf big checkpoint 2026-06-01 02:31:46 -05:00
Retnuhytnuob 622d7678c5 collision checkpoint 2026-05-31 01:15:45 -05:00
Retnuhytnuob dd7efbf409 Add collision view/edit tool 2026-05-21 04:25:05 -05:00
Retnuhytnuob 1b72dfe8ad Datadump rom1: 0x08118680 - 0x0825DE70 graphics/simple arrays (#213)
* dump u8 * pointers

* through 08137DA4

* checkpoint 08138014

* travel paint

* sapphire travel paint

* painter palette rename

* ruby evo arrows

* prenaming sapphire evo arrows

* sapphire evo arrows

* raw ruby coin arrow dump

* rename capture ball variants

* indicatorLight naming

* carve pointer array at 0x086AFCB0

* dump/carve gFieldBoardConfigs 0x086AFD70

* dumped gKecleonSpriteYSortData:: @ 0x086AEA70

* dump spheal flight path data

* merged the 2 SphealFrameset Arrays

* naming of spheal/sealeo frameset data

* dump gOptionsSpriteSets and potential data block after the Pokepinagb string

* add comment with original name of raw fu the 2 raw functions

* add comment with original name of the 2 raw functions

* folderized board lights

* split Ruby Light file, name ruby light unknowns

* Sapphire board lights

* class standardization: board collision data set

* board data folderization

* 4 banner graphics, unk naming

* added m4a_tables.c

* move comment point for m4a_tables

* agb_sram rodata

* incorporate remainder of m4a_tables file.

* Move AgbLibSramVersion into src/agb_sram.c

* Dump se fragment

* Don't hardcode gDeltaEncodingTable address

* Don't hardcode AgbMain in crt0.s

* Cleanup gAreaPortraitIndexes name

* More name cleanup

---------

Co-authored-by: Marcus Huderle <huderlem@gmail.com>
2026-04-14 17:39:37 -05:00