FFV Battle Windows

[Mike 64]

I was editing the text window graphics, when I noticed that in battle scenes, the top row of pixels for the menu windows was missing. So I looked at the tilemap for battle scenes in BSNES Plus and saw that there was an extra row of tiles in the battle background duplicated from the last row, and that the top row of pixels for that was being drawn over the top row of pixels for the menu windows. I then decided to try removing the bottom duplicate row from the tilemap using the memory editor, and it worked until the battle ended.

So I was wondering how, if at all, I could stop the duplicate row of battle background tiles from being drawn to begin with.

[Everything]

This is just a guess, but if it's a single scanline it sounds like it might be an HDMA timing issue. Try running on higan (accuracy) and see if the problem persists.

If that doesn't work, I have some notes on the code for loading battle background tilemaps so I might be able to figure out where it's loading an extra row of tiles.

[Mike 64]

I couldn't find higan (accuracy) anywhere, and the only results that showed up when I searched were for a Retroarch core that doesn't seem to exist anymore. Unless you meant the latest available version of the standalone emulator, which is v115 as far as I can tell, in which case, the same thing happened, same with other SNES emulators that I tested.

Here's how it looks:

And an export of the tilemap for the battle background, to show what I mean by a duplicate of the last row of tiles at the bottom.

And then the tilemap for the menu window to show what that's supposed to look like.

[Everything]

Try replacing the byte at C1/3557 (0x13557 in a hex editor) from 0xA2 to 0x60 (RTS). I think that will stop it from making an extra copy of the last row of tiles.

You can also try making the changes below. I changed it so that it copies 32x19 tiles instead of 32x20 tiles when copying the tilemap to VRAM.

Code:

C1/3537: A2 00 05     LDX #$0500 -> change to A2 C0 04     LDX #$04C0

C1/3547: A2 00 05     LDX #$0500 -> change to A2 C0 04     LDX #$04C0

[Mike 64]

Using the first method worked, but at the same time, made me realize that the extra row is likely drawn for the purposes of the heat wave and underwater effects in deserts and the submerged Walse Tower, respectively, and possibly for other battle backgrounds that do something similar, since the effect is now more noticeable at the bottom of the two mentioned backgrounds.

So now the question is, why does the top row of pixels from the bg get drawn above the top row of pixels for the menu windows? I checked again, and noticed that the entirety of the battle scene, including the menu windows, seems to be drawn one pixel higher than it should be drawn on the screen in-game when compared to the actual tilemap being loaded into vram. So maybe that's why? Because the whole thing is seemingly misaligned vertically by a row of pixels?

[Everything]

It seems like the HDMA timing is off by one scanline. I'm not sure where that gets set up in the code but I will try to find it.

This doesn't affect a vanilla ROM does it? It would help to know exactly what you changed. Are you starting from the RPGe translation? Can you tell me the CRC32 of your unmodified ROM file?

[Mike 64]

I'm using the GBA script port version as a base(which in turn uses RPGe as a base), but I can confirm that it happens regardless of the version, it's just less noticeable because the graphic uses white in the "middle" instead of grey like my graphic.

Original Japanese Version (CRC32, C1BC267D):

RPGe Translation with passive sprinting and learning (CRC32, 23ED4E16):

GBA Script Port with passive sprinting and learning (CRC32, 15B84781):


As far as changes to the rom go, I've only changed the speech font to match the FFV GBA speech font, along with cleaning up the resulting formatting of the text so that it would fit, as well as both sets of text window graphics.

[Everything]

Very interesting! I think we can consider this a bug in the vanilla version. I believe the screen shots on this page were made with real hardware and they also seem to have this issue. So that rules out the possibility of an emulation issue. It's also possible that this was intentional, but that seems unlikely to me. In a bizarre coincidence, one of the people who worked on the RPGe translation just tweeted a few hours ago about something similar occurring in other games.

I've found the RAM location of the background scrolling HDMA tables which are responsible for switching from the battleground area to the menu area on the screen. I think we would just need to shift the transition up by 1 scanline to fix the issue. I haven't quite figured out how to do that yet but I'm getting close.

*** Update ***

Change one byte at C1/1513 (ROM address 0x11513) from 0xA0 to 0x9F. That should shift the transition from the battlefield area to the menu area up by one scanline.

There is a separate fix for the final battle with Exdeath because it uses a different HDMA table to get the scrolling background effect. Change one byte at C1/158F (ROM address 0x1158F) from 0x04 to 0x03.

[Mike 64]

Nice. The fix for normal battle backgrounds works like a charm. However, I tried the fix for the Neo Exdeath background, and it doesn't seem to be working as intended, despite changing the value at 0x1158F from 04 to 03. Seems like all it does is change what line the background's tiles get loaded into the scene to be drawn to the actual background, as far as I can tell, which is located below the menu window. But it's still progress regardless.

[Everything]

Can you post a screenshot of the Neo Exdeath battle?