SpritesMind.Net

Good day to everyone!

I'm fairly new to SGDK, and currently researching in what the Genny can and cannot do. One thing that intrigued me was displaying large sprites in Space Harrier II. Before, I thought it was just using a PLANE to draw the sprites on, which would explain the choppiness as "sprites" would have been aligned to 8 pixel coordinates. I was thinking that way so that it avoids the sprite scanline limit. But when I checked the layers from Gens Kmod, the sprites were indeed in the Sprite layer.

I think Golden Axe for the Master System probably implemented something similar to go beyond the scanline limit.

How do I achieve the same using SGDK?

P.S. Apologies if this has been asked before, as I don't know what keywords to use for this specific question.

Golden Axe SMS puts sprites in the background IIRC (Space Harrier SMS and Altered Beast SMS too). It can be seen by the fact that the "transparent pixels" around the sprite are opaque.

Is that this effect you want to reproduce ?

@tryphon
Maybe something like it, but not quite. I was just wondering how Space Harrier II was able to pull it off with Sprites instead of the background layer. Was wondering if the Genesis had some sort of "ignore scanline limit if aligned to 8px" for sprites.

Space Harrier II has lots of overlapping sprites onscreen, so I was thinking it would have flickered like crazy specially with all the large pillars and sprites on screen. But somehow, it doesn't. What particular technique did they use? And is it the cause of the lower framerate and choppy movement?

With the SMS, it's understandable that they used the PLANE BG layer in Space Harrier as it can't possibly display that many sprites. But the Genesis actually used hardware sprites for the sprites.

No, there's no way to avoid flickering. If SH2 uses sprites, then it doesn't reach the limits of 20 sprites or 320 pixels per scanline. The sprites are not very wide, so this is likely.

The low framerate and choppy movement is mainly due to the fact that the MD can't do zoom, so there are frames at different sizes, but due to cart size constraints, there are not so much.

Sik has shown a clever way to fake zooming while using few frames, but it increases the number of sprites and could cause overflow...

hotrodx wrote: ↑

Sun Mar 24, 2019 5:23 am

I'm fairly new to SGDK, and currently researching in what the Genny can and cannot do. One thing that intrigued me was displaying large sprites in Space Harrier II. Before, I thought it was just using a PLANE to draw the sprites on, which would explain the choppiness as "sprites" would have been aligned to 8 pixel coordinates. I was thinking that way so that it avoids the sprite scanline limit. But when I checked the layers from Gens Kmod, the sprites were indeed in the Sprite layer.

Not far off actually… sprites at the nearest depth do indeed become plane A (to give room for the other sprites behind it). Outrun does something similar. I didn't check Super Thunder Blade but I wouldn't be surprised if it does that as well.

So it's actually doing both at the same time.

Sik wrote: ↑

Mon Mar 25, 2019 12:55 pm

hotrodx wrote: ↑

Sun Mar 24, 2019 5:23 am

I'm fairly new to SGDK, and currently researching in what the Genny can and cannot do. One thing that intrigued me was displaying large sprites in Space Harrier II. Before, I thought it was just using a PLANE to draw the sprites on, which would explain the choppiness as "sprites" would have been aligned to 8 pixel coordinates. I was thinking that way so that it avoids the sprite scanline limit. But when I checked the layers from Gens Kmod, the sprites were indeed in the Sprite layer.

Not far off actually… sprites at the nearest depth do indeed become plane A (to give room for the other sprites behind it). Outrun does something similar. I didn't check Super Thunder Blade but I wouldn't be surprised if it does that as well.

So it's actually doing both at the same time.

Thanks for verifying. That really explains it a lot.

I wonder how far one can go with the "BG as sprites" technique. Take a brawler like Streets of Rage or Golden Axe. Then offset a BG layer during HBLANK to position the sprite. If two BG "sprites" overlap horizontally, switch one to use traditional sprites. Otherwise, keep using BG sprites to avoid the scanline limit. Then at the end of the VBLANK, update animation for the next frame.

The issues I can think of is as follows:
1. We end up with only one BG plane.
2. Is updating the BG tiles even fast enough for sprite-like animations?
3. Duplicate tiles for BG and sprite, unless they can be shared.

What do you think?

Keio Flying Squadron does something like that, using sprites as a background. At one point (around stage 5 or 6?) it has a huge Ark that splashes onto the sea and you have to catch up with it. Normally the sea takes up all the backgrounds, and once you reach the ark, it's made up of sprites only. Then the game scrolls up (the thing is 2-3 screens tall), and once the sea backgrounds are out of view, the ark switches into using that background plane for its graphics.

If you keep shooting while the game does this, you can see the cutoff point due to the sprite limit making parts of the ark flicker - but only until it switches to using a BG layer.

Huge wrote: ↑

Tue Mar 26, 2019 1:54 pm

Keio Flying Squadron does something like that, using sprites as a background. At one point (around stage 5 or 6?) it has a huge Ark that splashes onto the sea and you have to catch up with it. Normally the sea takes up all the backgrounds, and once you reach the ark, it's made up of sprites only. Then the game scrolls up (the thing is 2-3 screens tall), and once the sea backgrounds are out of view, the ark switches into using that background plane for its graphics.

If you keep shooting while the game does this, you can see the cutoff point due to the sprite limit making parts of the ark flicker - but only until it switches to using a BG layer.

Haven't played Keio as I never had a SegaCD, but were you referring to this: https://www.youtube.com/watch?v=CJI6eoU ... .be&t=2630 ?

In the video, there was a brief moment where the large flying Ark went over the scanline sprite limit (coincided with the player firing) at around the 44:03 mark. So that segment might still be made of sprites even if the sea BG layer is now offscreen.

Still, I'm a newbie with the Genesis programming. Can it share tiles between sprites and BG? And if so, is it without penalty?

Genesis is unified VRAM, no penalty at all.

Sprites need to have a specific tile arrangement, and tiles can't be reused (aside from multiple copies of identical sprites). Tilemaps use the opposite arrangement, but you can place tiles arbitrarily, so it's doable, albeit not exactly in an intuitive way (as the tiles end up shuffled around).

Actually is not that easy to reach the 20 sprite limit on a actual game. This isn't NES where you have to think about it constantly. Probably you will hit cpu performance and playabylity problems before. But in the case you can use the same "techniques" developed on NES to circumvent such problems.

Sik wrote: ↑

Mon Mar 25, 2019 12:55 pm

Not far off actually… sprites at the nearest depth do indeed become plane A (to give room for the other sprites behind it). Outrun does something similar. I didn't check Super Thunder Blade but I wouldn't be surprised if it does that as well.

Do you mean that cars got displayed on plane A in Outrun? Seems not possible to me, since this plane is used to display the second road; but perhaps there are exceptions, that's why I'm asking.

No, but it does apply to the scenery to the sides (presumably only when not doing the wide roads, that is).

It gives room for the scenery to go a bit deeper before hitting the sprite limits (since the problem is that there's a lot of overlap, so sprites won't cover as much of the screen as you'd normally expect). It definitely helps that it's the largest one that gets turned into a tilemap, as that's where most of the gain is.

EDIT: also, when the game renders grass or sea (which covers up to the side of the screen), it also uses a plane in those cases (which is why they can't overlap and cut off the "sprites" behind them).