Hacking ROM Hack Translation WIP (advice welcome) Pocket King GBC

[null-problem]

I'm new here, so please let me know if this is the wrong forum, etc.

I've been working on translating Pocket King for the Game Boy Color.
It's kind of a fantasy advance wars but you can form little parties and evolve your
troops/monsters. I've never seen it mentioned in English and don't recall how I discovered it.

So far, I've made a table file and reverse engineered the text format
for narrative sequences between stages. I've also found several
individual strings with pointers and have had some small luck with
insertion. I've made dumpers successfully for both of these kinds of
text, and have a translator picking away at the dumps.

What I haven't had much luck with is modifying menu text. I've isolated
the code that loads the tiles into VRAM and the code that uses those
tiles to 'paint' the menu to the map VRAM. There is even a 'drawing'
in the code representing the menu, with hex of the appropriate
tile number in each position.

What I haven't been able to find, is any reference to the strings
relating to the menu items, if they even exist. Maybe they are hardcoded somehow,
but I also didn't find pointers to the sprites in memory or anything like that.
I could change the menu text using the
above 'drawing', but only to currently loaded tiles, which is not
helpful. There must be a data format that at least sets what tiles will
be in the VRAM to draw the menu from, but it doesn't use the same format
as the other text.

I have also isolated where the image for the first tile in a menu
item is in the raw ROM and have isolated where the code starts reading
it, but I seem to lack the skills to work backwards in the asm to
figure it out.

I'm a professional programmer, but very new to romhacking, so I'd
appreciate any guidance. I can provide plenty of specifics (offsets, control codes, pointer locations, etc) if anyone is
interested in taking a look. I also imagine someone more experienced
would have some general approaches or advice I'd find helpful.

Post automatically merged: May 25, 2025

Well, after days of work (and of course the day after I went around asking for help...), I had a breakthrough. The 'picture' of the menu based on tiles didn't have the tiles in numeric order, like the word 'unit' (in katakana) used the tiles 14 13 15 12. I realized the representation in the code from the table might be scrambled and in the numeric order of the tiles, and it was.

So if 'word' was the target word and used tiles 14 13 15 12, if I ordered the tiles 12 13 14 15, instead of looking for 'word' in the ROM, I needed to look for 'dowr'. It worked out. Probably would have obvious to you old hands but that threw me for a loop for awhile.

Should have an early playable demo soon(?).

 

[Skv0ra]

So, menu uses preset graphic tiles for text vs just simple text overlaid over a bg? That's, kinda funny considering how tight GBC games had to be.

 

[null-problem]

So, menu uses preset graphic tiles for text vs just simple text overlaid over a bg? That's, kinda funny considering how tight GBC games had to be.

There is a tile graphic per kana/latin character. Then, for displaying menus, there are two steps: First, the program uses a string to load all needed (for that menu screen) in VRAM. Second, there is a representation (in tile numbers with a 'screen offset' control after each one) in the data for each menu that uses those preloaded tile numbers to put them to the screen.

So, for example:
If I had a menu that had Atk, Def, Move, HP, the string (I call these 'loadstrings') would read like AtkDefMovHp (notice the 'e' didn't get repeated) and that string would use the normal 'table file' bytes to define itself.

Then, these tile graphics would get loaded into VRAM tiles, starting with assignment from 0x10 (the other tiles remain fixed).
So here's how the tiles would look in VRAM:
A t k D e f M o v H p
10 11 12 13 14 15 16 17 18 19 1a
That's the first step.

Then, when it comes to displaying the menu, the part of the 'menu image' in the ROM for 'Atk' would look like this:
10 00 11 00 12 00 (if on the right half of the screen) or
10 01 11 01 12 01 (if on the left)
Of course there are 'pipe' characters and terminators and such. Another interesting quirk is that the dakuten (the little double quote and circle over some kana to change their sound) are their own separate characters, so each line of the menu has a line above that is always empty except for dakuten! If someone wanted to asm hack this more thoroughly and create more space for things, reusing those dakuten lines for non-ja languages would be pretty nice.

So, my issue here was twofold:
1) I was looking for the text on the menu using the 'table' bytes, not the random bytes defined by each 'loadstring'.
2) A relative search approach is always gonna fail under this system, for several reasons.

But, once I'd reversed the process and understood it, it went pretty smoothly. Took me quite a while to figure out though, as this is my first hack.
Some menus share the same 'loadstring' and others have their own. Also there are menus that get drawn using this system, but then after some areas are overwritten using strings from pointers, like the value to display after Atk, Def, etc.

I have to imagine this isn't a novel approach, though? Seems like the company (Kaga Tech->Kaga Create) was responsible for lots of games I've heard of.

I can imagine something like this isn't too uncommon, but this is my first game to try hacking on a system like the GBC.

 

[Shavoss]

Man, sempre quis completar o bestiário deste game
Mas sem entender não foi possível