SpritesMind.Net

I'm currently working on Sonic2 double resolution interlace mode emulation, and I'm seeing some weirdness with sprite rendering.

My current emulation does not perform per scan line sprite table query rendering, but rather at the end of the frame just parses the current sprite table and renders each sprite encounted for faster speed.

With this method for Sonic2 I'm only able to see sprites if I subtract 224 from their y position and then it appears I see a mixture of sprites - some from the top half of interlace display and some from the bottom half of the interlace display.

Has anyone else delt with interlace mode sprites and knows whats going on here? In double resolution interlace mode is there anything special needs to be done when parsing the sprite y position from the sprite table? It looks to me like I need to update my sprite rendering to parse the sprite table every scan line.

UPDATE: So after further testing, I'm actually only seeing sprites from the bottom half of the interlace screen which definitely makes it look like the sprite table is getting setup twice per frame - once for the top interlace half, and once (probably from hbl halfway down the screen) for the bottom interlace half.

cheers,
Steve.

With this method for Sonic2 I'm only able to see sprites if I subtract 224 from their y position - and I mainly see the sprites of the bottom half of the interlace display (Tails' screen).

For the normal and single density interlace modes bits 8-0 of the sprite Y coordinate are used. In the double density interlace mode bits 9-1 are used instead. Are you adjusting the sprite rendering code to account for this?

Charles MacDonald wrote:

With this method for Sonic2 I'm only able to see sprites if I subtract 224 from their y position - and I mainly see the sprites of the bottom half of the interlace display (Tails' screen).

For the normal and single density interlace modes bits 8-0 of the sprite Y coordinate are used. In the double density interlace mode bits 9-1 are used instead. Are you adjusting the sprite rendering code to account for this?

Thanks for the reply Charles. Yeah - I'm using those bits and from tracing through the sprites in the table, only the bottom interlace half screen sprites are present so it has to be the sprite table being updated twice per frame. Since I'm only parsing the sprite table at the end of the frame, I'm only seeing the bottom half sprites.

cheers,
Steve

Sonic2 is indeed modifying sprites table at middle frame so you have to handle that specification to emulate it properly (scanline rendering ?).

A good method would be: At the start of each frame, make a copy of the sprite table. When a VRAM write happens in the middle of a frame, take a note of it, and on the next line, draw the sprites using the sprite table copy, cutting them off at the top and bottom of the current area. Then, record the new sprite table and continue on. Repeat as needed, until you reach the end of the screen, where the remaining portion of the screen is drawn.

The game I'm making also relies on sprite table updates in the middle of a frame, to display scrolling transparent text.

Thanks for the help guys.

Since I only have to display either the top or bottom half of the interlace display (stretched to full screen), my solution was to parse and save off the sprite table at the beginning of the frame for top half, or at end of line 112 for the bottom half. I then render this saved sprite list as normal when composing the frame.

Next to fix up is the per line hscroll table. Does anyone know if the hscroll table doubles in size for double interlace mode (448 entries, 1 entry = 1 line) or does each entry span 2 lines of the display (224 entries, each entry=2 lines)?

thanks

From the tests I've done, it appears that each entry in the per line hscroll table covers 2 screen lines when in double interlace mode.

Correct. Well, sort of.

In interlace mode the system is still only displaying 224 lines per frame, it's just that one frame is all the odd lines, and the next all the even lines. So, you still only need 224 entries in the scroll table. You could change the scroll table every frame, and have all 448 lines at different scroll coordinates that way. But for your purposes assuming 2 lines per entry will be just fine.