Langrisser II (v1.2) opening tile graphics bug
Posted: Thu Feb 23, 2017 8:24 am
Long-term veterans may remember that Genecyst had a problem with this game, where it rendered the characters displayed in the intro incorrectly. And it looks like I'm experiencing the same bug. But unfortunately, nobody ever explained what actually caused it :/
So this is what the bug looks like:
And this is what it's supposed to look like:
The text at the bottom of the screen is rendered as 16x16 sprites.
The problem is that the sprite layout in VRAM is:
AB
CD
Which requires sprite addressing like this:
However, this isn't how the Genesis works. That breaks every other large sprite in every other game. It's supposed to be like this:
In other words, for the tiles in Langrisser II to render correctly, they should exist in VRAM like this:
AC
BD
... but they don't!!
I suspected I had an emulator bug where I was writing to VRAM improperly.
So I traced the game back to PC=$008c6a where it triggers a 68K->VRAM DMA from $ffd208 to $a180 for the tile that resides onscreen at Y=176-191; X=64-79.
So I looked for where $ffd208 was being filled out, and that's at PC=$02c45c.
I then compared higan's trace log to Mednafen's, and the exact same bytes are being written in the exact same order into work RAM.
As such, the tile data in VRAM when the sprite is being rendered is definitely laid out in memory as:
AB
CD
So ... what gives here? How are other emulators rendering tiles, that are in memory in the wrong order, correctly? :/
So this is what the bug looks like:
And this is what it's supposed to look like:
The text at the bottom of the screen is rendered as 16x16 sprites.
The problem is that the sprite layout in VRAM is:
AB
CD
Which requires sprite addressing like this:
Code: Select all
uint tileNumber = tileY * (o.width >> 3) + tileX;
Code: Select all
uint tileNumber = tileX * (o.height >> 3) + tileY;
In other words, for the tiles in Langrisser II to render correctly, they should exist in VRAM like this:
AC
BD
... but they don't!!
I suspected I had an emulator bug where I was writing to VRAM improperly.
So I traced the game back to PC=$008c6a where it triggers a 68K->VRAM DMA from $ffd208 to $a180 for the tile that resides onscreen at Y=176-191; X=64-79.
So I looked for where $ffd208 was being filled out, and that's at PC=$02c45c.
I then compared higan's trace log to Mednafen's, and the exact same bytes are being written in the exact same order into work RAM.
As such, the tile data in VRAM when the sprite is being rendered is definitely laid out in memory as:
AB
CD
So ... what gives here? How are other emulators rendering tiles, that are in memory in the wrong order, correctly? :/