It left me just as confused as you when I looked at other emulator's rendering of this first frame. I even checked on a real Game Gear just to be sure!

The 64 sprites available on the Game Gear/SMS VDP should be rendered one by one, in the order they appear. The first sprites have priority over the later ones. This means the later ones should NOT be rendered if another sprite was rendered on a given pixel (except for transparent colors…).

#GameGear #Emulation #gears

So what happens on this frame ? Luckily I wrote a debug mode that is easy to toggle, and explains it all.

The game uses higher-priority blank sprites to hide the rest of Sonic ! (probably from a re-used routine). This is so that in the animation where the Sega logo appears, it looks like there's a magic line that makes everything appear. And Sonic's feet and hand would go over that line ! So they were hidden by developers by putting blank (but not transparent) sprites before Sonic.

#GameGear #Emulation #gears

After implementing background priority, I found something curious. The map screen in Sonic 1 did not show the current level line and number of lives anymore.

I thought I caused some kind of regression, so I added a test framework to generate frames and compare them with a "good" render to prevent regressions. This is how most frames in these posts are generated.

But it's not the only issue for this frame: the third image is how this frame should actually look, if we check how the map is rendered with another emulator.

Now that's a curious bug…

#GameGear #Emulation #gears

After I wrote the article, I posted it on the SMS power discord, asking for ideas on this corruption bug. Many great people chimed in.

A question I had was if I could dump the tileset to look at the video ram of the VDP to find out if anything might be corrupted.

A tileset is the list of tiles (sometimes called "patterns" or "characters") in memory that can be be used for background or sprites.

On a typical Game Gear game, those live in the ROM, then are copied in Video RAM (VRAM) once the ROM is mapped in the address space. They can only be displayed by the VDP from the VRAM.

The VRAM can hold 512 tiles, and each tile is 8x8 pixel. So I initially rendered the memory region in a 256x128 tileset (32x16 tiles).

Doesn't it look a bit weird ?

#GameGear #Emulation #gears

The map did look weird, and someone rightfully told be it would look much better if rendered in the other dimension (16x32 tiles) instead.

This way the map is entirely visible! It's as if the artists worked exactly like this.

And we can clearly see the corruption bug in the first two tile lines.

Something felt off in the previous tileset though: it seemed like the bottom half (usually used for sprites)is using the wrong palette. In the VDP, background can use both palette 0 and 1 (0 by default), but sprites always use palette 1. Let's render the bottom half with palette 1 instead and transparency:

#gears

But something is still missing. Like those sprites are split or something. What if we tried to honor the SIZE bit for the bottom half in order to see double-size sprites ?

Double-size sprites combine vertically two consecutive sprites in memory.

And it looks much better ! We can clearly see Dr Eggman, numbers, as well as the level lines.

I have also fixed the corruption.

#gears #emulation