[gukid/ioev]

I'm working on a hack that reverts the controller layouts in Breath of Fire 4 to their (way more sensible) Japanese counterpart.  So far I have the layouts working, and they can be selected from the settings menu.  I also have updated all of the icons in the text to be correct (as far as I can tell.)

I've been having a really hard time figuring out where the data is that determines the layouts that are displayed on the controller settings screen, and also the text labels for the player name input screen (though I haven't looked into this part much yet.)

I know where these strings are stored, and changing the indexes or strings themselves changes what is displayed on screen, but there are 2 dynamic fields that swap one button functions on layouts 3/4 that are on different buttons from the Japanese version, and this part can't be corrected by changing the text or indexes.

I'm also pretty sure one of the strings won't fit correctly (Talk/Confirm needs to be on the right) and I'm assuming I'll have to tweak the spacing a little bit, or put "Confirm" on a new line if that's possible.

I'm familiar with the .EMI file format, and have have read through https://www.romhacking.net/hacks/6413/ (bof4 text documentation by navarchos) but it seems this screen must be stored in a slightly different way.

Any help would be greatly appreciated!  Also I can go into further details about what I have figured out if that would be helpful.

[navarchos]

Looks like you'd want to change a pointer table in GAME.EMI. Here's what I got from tracing assembly:


801b2808 94440000: lhu    $a0(80116cf8), 0x0000(v0)([801b52f8] = 80bf)
...
8014c0e0 3084ffff: andi   $a0(000080bf), 0xffff
8014c0e4 00042342: srl    $a0(000080bf), 0x0d
8014c0e8 14800003: bne    $a0(00000004), $r0(00000000), 0x8014c0f8
8014c0ec 00051040: sll    $v0(801b52f8), $a1(000000bf), 0x01
8014c0f8 24020002: move   $v0(0000017e), 0x0002
8014c0fc 14820008: bne    $a0(00000004), $v0(00000002), 0x8014c120
8014c100 24020004: move   $v0(00000002), 0x0004
8014c120 14820008: bne    $a0(00000004), $v0(00000004), 0x8014c144
8014c124 2482ffff: addiu  $v0(00000004), $a0(00000004), 0xffff
8014c128 3c02801e: lui    $v0(00000003), 0x801e
8014c12c 3442b000: ori    $v0(801e0000), 0xb000
8014c130 00051840: sll    $v1(00000002), $a1(000000bf), 0x01
8014c134 00621821: addu   $v1(0000017e), $v0(801eb000)
8014c138 94630000: lhu    $v1(801eb17e), 0x0000(v1)([801eb17e] = 109c)

I'm looking at the string "action"
First, it loads 0x80bf from the memory (which in turn, is from GAME.EMI), then it extracts only the lower bytes (0xbf), multiplies that by two and adds it to a base address for a pointer table.
0xbf indicates that the 0xbf-th (or 191st) pointer is to be read, and the 191st pointer does point to "action"

The address to this pointer is 0x000202f8 in GAME.EMI, hope that helps

[gukid/ioev]

Thank you!  I'm sure this is it.

The controller layout data is actually at the end of this block, and I while I noticed that the character Strings are contained here, I didn't notice that that there was also a whole bunch of other strings that were mostly control codes.  It won't be as easy as just swapping in the Japanese file data but I think it'll be pretty straightforward once I map out the string table.

Update:

The table ends up looking like:

Code: [Select]

C880      Camera
BD80   Change Rank
BE80 /Cancel
C780 Subscrn
BF80 Action
C080 Talk/Confirm
C980 Dash
C180 START button      Pause
C280 SELECT button     Help

BD80   Change Rank
C880      Camera
BE80 /Cancel
C780 Subscrn
BF80 Action
C080 Talk/Confirm
C980 Dash
C180 START button      Pause
C280 SELECT button     Help

C880      Camera
BD80   Change Rank
BE80 /Cancel
C780 Subscrn
C980 Dash
C080 Talk/Confirm
BF80 Action
C180 START button      Pause
C280 SELECT button     Help

BD80   Change Rank
C880      Camera
BE80 /Cancel
C780 Subscrn
C980 Dash
C080 Talk/Confirm
BF80 Action
C180 START button      Pause
C280 SELECT button     Help

Which is definitely the button layouts, although it doesn't handle where the strings are positioned.  So while I can achieve most of what I want to do here, I'll need to go up one additional "layer" per-se, and find the data that references these layouts so I can reposition the text.

Update:

Since I'm new I often forget what tools I have available to figure this stuff out.  Modifying values in memory directly after this table alters the position of the strings.  Getting close!

[navarchos]

More tracing, this time with the help of NO$PSX's extremely useful VRAM and GPU debugger:

Once again, I'm looking at the string "Action"
The GPU command used to render the first character gives a hint as to how the entire string is positioned:

Code: [Select]

64808080 # variable size textured rectangle
006C0070 # upper left edge of the rectangle (yyyyxxxx)
3C004C08 # clut + uv coordinates
000C0008 # size of rectangle

The second line is the one we're looking for.

X coordinate:

Code: [Select]

80140f98 8fb50034: LW      00000000 (s5), 0034 (801ff670 (sp)) [801ff6a4]
...
801b281c 92040000: LBU     00000004 (a0), 0000 (801b5318 (s0)) [801b5318]
...
801b282c 02a42021: ADDU    00000030 (a0), 00000040 (s5), 00000030 (a0) # final x coordinate = 0x40 + 0x30 = 0x70
...
80140b04 acc40008: SW      006c0070 (a0), 0008 (8002f078 (a2)) [8002f080] # push coordinates
The value at 0x801ff6a4 can't be changed, and is likely the offset of the current character being rendered by the GPU, as such, it's probably not the offset we're looking for. However we can change the value at 0x801b5318, which is the x-axis offset. Just like the pointer-to-pointer, this is found in the GAME.EMI file, at 0x20318.

Y coordinate:

Code: [Select]

80140f9c 8fb40030: LW      00000088 (s4), 0030 (801ff670 (sp)) [801ff6a0]
...
801b2820 92050001: LBU     000000bf (a1), 0001 (801b5318 (s0)) [801b5319]
...
801b2838 02852821: ADDU    00000030 (a1), 0000003c (s4), 00000030 (a1) # final y coordinate = 0x3c + 0x30 = 0x6c
...
80140b04 acc40008: SW      006c0070 (a0), 0008 (8002f078 (a2)) [8002f080] # push coordinates
Again, the value at 0x801ff6a0 cannot be changed, but we can change the y-axis offset at 0x801b5319. This is right next to the x-axis in GAME.EMI, at 0x20319.
These offsets are not signed integers, but setting both of them to 0 places the string on the uppermost left corner of the window, so there shouldn't be any problems with the positioning.

Hope that helps.
January 13, 2022, 12:50:11 am - (Auto Merged - Double Posts are not allowed before 7 days.)If you'd like to change the underlines:

They come as triplets of bytes in GAME.EMI. The first byte of the triplet denotes the x-axis offset of the line, the second is the y-axis offset of the line (which is the same for both start and end points), and the last byte denotes the length of the line.
The location of the y-axis offset of the right underline (which is the one you'll be changing, I assume) is 0x20336 in GAME.EMI.

The line is very faint (especially the right one) but that should help with making sure the text doesn't collide with the line.

[gukid/ioev]

Thank you for all of your help!  I had actually figured out the structure of the positioning of the text and bars, but seeing your comments on the ASM is really helpful as I've been having trouble understanding what most of it was doing.

The current state of things is:


I figured it was easier to just shift everything over to the left, than mess with trying to pull apart the "Talk/Action" string and figure out a way to put an additional string on the screen or manage a return code.  I had also considered just removing the text for Action and Cancel and let it be implied, but I think this works well enough.

I've also figured out the characters on the name entry screen, it's a single image with some offsets to which character to display.

I think the only things remaining is one bug that showed up when I changed the controller button mappings back to the japanese data, is on the name entry screen the "Next" function no longer works.  Not a huge deal, but still kind of strange.

Also on the Japanese settings screen it does a neat thing where it moves the text over a bit, and resizes the grey line underneath.  So in the image I posted, Dash would be up against cancel "Dash/Cancel" and if Dash were in the Action position, it would be up against the square button and the line would be shorter.  No idea how it does this though, but I suspect there's some kind of character code for it, so I'll probably end up digging into the Japanese text to see.

[MD_Prometh]

This looks like a cool hack. Always neat to see BOF IV get some love

[navarchos]

Thank you for all of your help!  I had actually figured out the structure of the positioning of the text and bars, but seeing your comments on the ASM is really helpful as I've been having trouble understanding what most of it was doing.

The current state of things is:


I figured it was easier to just shift everything over to the left, than mess with trying to pull apart the "Talk/Action" string and figure out a way to put an additional string on the screen or manage a return code.  I had also considered just removing the text for Action and Cancel and let it be implied, but I think this works well enough.

I've also figured out the characters on the name entry screen, it's a single image with some offsets to which character to display.

I think the only things remaining is one bug that showed up when I changed the controller button mappings back to the japanese data, is on the name entry screen the "Next" function no longer works.  Not a huge deal, but still kind of strange.

Also on the Japanese settings screen it does a neat thing where it moves the text over a bit, and resizes the grey line underneath.  So in the image I posted, Dash would be up against cancel "Dash/Cancel" and if Dash were in the Action position, it would be up against the square button and the line would be shorter.  No idea how it does this though, but I suspect there's some kind of character code for it, so I'll probably end up digging into the Japanese text to see.

That looks great! If I may ask, where are the controller layout data located in GAME.EMI?

[gukid/ioev]

Actually, I was mistaken, it's not in GAME.EMI, it's in:

EDIT: Nevermind, it IS in GAME.EMI, apparently my assumption of the data was off a bit, rather than starting with 00, it ends with 00.  I've updated the locations below.

Code: [Select]

BIN/SYSTEM/CAMP.EMI: 00037464
BIN/SYSTEM/COMMU01.EMI: 00021c64
BIN/SYSTEM/COMMU02.EMI: 00018c64
BIN/SYSTEM/COMMU03.EMI: 00033464
BIN/SYSTEM/COMMU04.EMI: 00019464
BIN/SYSTEM/COMMU05.EMI: 00019464
BIN/SYSTEM/COMMU06.EMI: 00039c64
BIN/SYSTEM/COMMU07.EMI: 00035464
BIN/SYSTEM/COMMU08.EMI: 0002a464
BIN/SYSTEM/COMMU09A.EMI: 00039464
BIN/SYSTEM/COMMU09B.EMI: 00037464
BIN/SYSTEM/COMMU09C.EMI: 0003d464
BIN/SYSTEM/GAME.EMI: 00022498
BIN/SYSTEM/LOT_SHOP.EMI: 0001d464
BIN/SYSTEM/MASTER.EMI: 00035464
BIN/SYSTEM/MSHOP.EMI: 00031464
BIN/SYSTEM/SAVE.EMI: 00033c64
BIN/SYSTEM/SGAMEN.EMI: 00041464
BIN/SYSTEM/SHOP.EMI: 00034c64
BIN/WORLD/AREAD075.EMI: 000fc464
BIN/WORLD/AREAE000.EMI: 000f9464
BIN/WORLD/AREAE003.EMI: 000f9464
BIN/WORLD/AREAE004.EMI: 000f9464
BIN/WORLD/AREAE006.EMI: 000fa464
BIN/WORLD/AREAE013.EMI: 000fa464
BIN/WORLD/AREAE014.EMI: 000fa464
BIN/WORLD/AREAE019.EMI: 000fec64
BIN/WORLD/AREAE021.EMI: 000fec64
BIN/WORLD/AREAE022.EMI: 00100464
BIN/WORLD/AREAE041.EMI: 000fbc64
BIN/WORLD/AREAE049.EMI: 000f9c64

Which brings me to hopefully my last question (before I start testing), what's a good way to get these changes back into the ISO?  I've written a small program to apply all the changes across all the files that contain this (and other) data, but other than inserting them one by one using cdmage, is there some other option?  I was thinking of rebuilding the iso, but I'd like to make as few changes to the original file as possible, to hopefully optimize the patch size.

[navarchos]

If you want to automate using a command-line based tool, you can try PSX-Mode2. It doesn't change file size when reinserting files with no size changes.

[gukid/ioev]

This worked beautifully, thank you again!

Edit: I also figured out the bug on the name entry screen where the "forward" functionality didn't work after remapping the controls.  Turns out it's hardcoded in an instruction: 0x0020 in us, 0x0010 in jp.  Changing this one byte fixed it.  Time to test!

Edit: Of course I run into trouble right away!  The map has a small menu on it that seems to use some hardcoded inputs just like the name input screen.  Also uses images for the text labels which is making it hard to find the data for the button labels.

I'm curious about this VRAM debugger in no$psx, but when I run Bof4 it plays the audio of the intro movie without video, none of the buttons respond and the it never loads beyond the end of the video.  I'm assuming it works fine for you?

[navarchos]

Getting BoFIV to work on NO$PSX is finicky. You can use an earlier version (IIRC from my tests, anything below v1.8 works), or make a savestate from an earlier version, and load it in the most recent version.

I found the labels on the map inside AREAE005.EMI.

[gukid/ioev]

I knew I wasn't crazy thinking that this worked at one point!  I must have started on an older version and upgraded at some point.

I found the graphics for the map menu in the vram debugger, and it looks like it's image based.  I'm not at all familiar with extracting/replacing images so this will be a bit of a challenge.

[navarchos]

Using CrystalTile2, you can edit the graphics using an external tool, and then reinsert it.

• Open the AREAE005.EMI file in CrystalTile2
• To get the tile editor up go to View -> Tile Editor or press F5
• To get the graphics to display properly, you need to set width to 64, height to 32 (or anything really, but 32 is optimal), and tile form to "GBA 8bpp". It should look like this:
  
• Scroll down until you find the tile. You can see the offset at the bottom-right box of the window.
• To copy a tile, left click on it, then right click and select "copy", or press CTRL+C
• This tile can now be pasted to an image editor. Just make sure that the image size doesn't change when you edit it
• Once done, the tile can be pasted back to the original file by copying it from the image editor, selecting the destination tile, then pasting it

If you double click a tile, it enters CrystalTile's own tile editor. To return to the tile viewer, just press F5 again.

[gukid/ioev]

This is super useful, thank you!  I had checked out CrystalTile2, but didn't realize the tile editor was under a different menu... hah...

I ended up doing this work using an application called TileShop.  The workflow had a few more steps, but it very nicely let me set up the us file on one side and the japanese on the other, and I could just drag and drop the icons from one side to the other.

So the display is correct, but now I need to fix the constants in the code again, which shouldn't be too difficult.  I'm also guessing these graphics will be found in some other files so I'll need to find and replace those as well.

Making steady progress!

[navarchos]

There seems to be a piece of dialogue that uses a placeholder code for the action button. Specifically, it's the help dialogue that shows up when you do the jar-clearing minigame in wharf. So far I haven't found another dialogue which uses this placeholder. I think this might be handled automatically by the game, so there's no need to change that.

[gukid/ioev]

Yeah, I figure I'm going to be finding little bits of hard coded button assignments all throughout the game.  Thankfully I'm getting a little better at finding where they are.
January 19, 2022, 10:54:47 pm - (Auto Merged - Double Posts are not allowed before 7 days.)I must have jinxed myself, as I'm having a really hard time finding the fishing menu graphics.  How were you able to figure out that the map menu graphics were in AREAE005.EMI?  I've done some digging (fishing?) in the ram during the fishing scenes, and it seems only AREAE003.EMI and the main executable are loaded, but I don't see the graphics I need in either of those files.  I've also tried to brute force loading many files, but it's quite exhausting having to set the bit depth and size every time.

[navarchos]

I found the graphics in AREA003.EMI and AREAD075.EMI:

I used 128x32 tiles, 4bpp.
The offsets are, 0xa8800 in AREAD075, and, 0xa6000 in AREAE005. I didn't find any other redundant copies.
I assume you were looking for fishing-related texts in the AREA files? That should work, since graphics and texts in the same area are stored together, sometimes redundantly (such as in this case).

I text dumped the entire contents of the /WORLD folder a while ago. As it is right now, it's not yet organized, and I need to tag the redundant files as well. I could send you a copy of the dump if you want.

[gukid/ioev]

Thank you again!  At first I was looking for fishing related strings, but they seemed to be in quite a few of the files, and I wasn't able to find graphics in them.  It never occurred to me to try different bit depths and sizes!

I was also a little worried about duplicate graphic assets across EMI files.  I guess as long as I can determine the starting offset, I should be able to figure out which "piece" of the emi the graphic makes up, and then can search for that binary string in other files.  I'm probably going to use the same approach for patching multiple files at the same time.  I was actually trying to determine a way of searching for the X button binary graphic somehow, but I don't think that's really possible.

If you'd like to share your text dump with me I'd be glad to accept it.  I'll take any help I can get

Edit: Made the changes as before, but it seems it's using a different palette as well, so the buttons show up as the wrong colors.  Will poke around and see if I can find the format of the palette in this file as well.

Edit2: Found a few changed bytes at the top of this section in the file, changed them back to the JP version and we're in business!

The changed palette was a bit of a mixed blessing, searching for what should be all the instances of the fishing graphics I need to modify:

Code: [Select]

BIN/WORLD/AREAD075.EMI: 000a1146
BIN/WORLD/AREAE000.EMI: 0009e946
BIN/WORLD/AREAE003.EMI: 0009e946
BIN/WORLD/AREAE004.EMI: 0009e946
BIN/WORLD/AREAE006.EMI: 0009f146
BIN/WORLD/AREAE013.EMI: 0009f146
BIN/WORLD/AREAE014.EMI: 0009f146
BIN/WORLD/AREAE019.EMI: 000a3146
BIN/WORLD/AREAE021.EMI: 000a3146
BIN/WORLD/AREAE022.EMI: 000a4946
BIN/WORLD/AREAE041.EMI: 000a1146
BIN/WORLD/AREAE049.EMI: 0009f146


[navarchos]

Here is the dump.

I was also confused initially since the map menus use 8bpp, while the fishing menu uses 4bpp. As far as I know, the game only uses 8bpp and 4bpp for textures.

[gukid/ioev]

(Edit: turns out what I thought was a missing feature is there, it's just not documented in the help text.)

Finding some strings referring to copying skills into "skill scrolls".  I haven't played the game in a while, but I don't remember anything like this?  It would have used the square button somewhere in camp menu.