Question about sprite layering on the PCE

[Nando]

Note, the following sprite is not mine, I "modified" an "Advance Guardian Hero" sprite to use as an example.

Could the following character sprite set up be done on the PCE?



Meaning one whole character sprite made up of three pieces. Isn't that what the second Toumaden game does?

[sunteam_paul]

Simple answer: Yes.

Be aware of the sprites per line limitation in the game design though.

[Nando]

I was wondering about that next. I'm still searching online and trying to find some examples about it and how it would affect the game play. Any resources you can throw my way I would really appreciate it.

Please correct me if I am wrong. On the PCE there's a limit of 16 sprites per scanline and a 32wide sprite counts as two, correct? and this directly affects how many things are displaying on the screen, and if there's any flicker?

Now seeing how there would be three layers to this sprite This means that the sprite up there would count as 6?

The plus side is that I could use more colors per sprite layer. So if I really wanted to give a bit more detail/color to a particular area, I could.



 

[spenoza]

Please correct me if I am wrong. On the PCE there's a limit of 16 sprites per scanline and a 32wide sprite counts as two, correct? and this directly affects how many things are displaying on the screen, and if there's any flicker?

My understanding is that the PCE can display 16 sprites per scanline OR 256 sprite pixels per scanline. Whichever limit is hit first is the one in play. If you cram 8 32-pixel-wide sprites on a line that's when you'll start to encounter flicker. Then again, if you are using sprites for fake multi-plane scrolling, using wider sprites frees up more sprites for display on screen elsewhere.

So yes, you are essentially correct. Overlapping 3 32-pixel-wide sprites would effectively use up 6 "slots" on the affected scanlines, but it would only use 3 sprites toward the total number that can be displayed on-screen.

Some ways to get around this would be, if this is a run n' gun style game with projectiles in play, to cause the projectiles to display only every other rendered frame, and to have them flicker out of sync. Let's say this character has a rapid-fire gun and can put up to 6 bullets on screen at a time. If you alternate the bullet display you could make 6 bullets effectively use only 3 displayed sprites for every frame. That would use up 9 "slots" per frame on the affected scanlines for the character and 6 bullets from the gun, and only use up 6 sprites per frame for the total allowable sprites displayed. That leaves you space for 7 more "slots" on the scanline and 58 more sprites on-screen.

I do not know what order the system prioritizes which sprites to flicker when the scanline limits are exceeded. FIFO? LIFO? Who know?

[Arkhan]

It's 256 pixels per line.  16 is the max if you only do 16x16 sprites.  It ranges from 8-16 depending on your sprite sizes.

It would not take up 6 slots per scanline.  It would take two.  It's like this:

[32x16]
[32x16]
[32x32]
Right?  That's a width of 32.  Not 64.  Hence, 2 "slots".  edit:  (The leg sprite might be 32x32.  I think it is)

The system prioritizes based off the sprite number, IIRC.   Lower sprite numbers take higher priority.  It's not LIFO or FIFO.  It's not a stack or queue.  It also doesn't flicker them.  It just flat out clips sprites that are out of priority.    See here.   The dome tops are lower sprite #s than the coral.  They clip the coral out.  If you fly down there, it clips a dome too because the ship is sprite 0.

This is no longer the case in Atlantean, but that's how it was in that video.

Also, spenoza, your numbers are off for your bullet flickering, I think.  Assuming the sprite is 32 pixels wide.  Won't it be 2 from the character, 3 from the bullets (per frame), so 80 pixels total (32 + 16*3) per frame on a scanline.  That would give you what, 11 more "slots"?  (176 pixels left / 16 = 11).  It would still be 6 sprites. (3 bullets and 3 32x16 sprites).

[Nando]

I see. Thinking of it as "slots" on a "stack"

what other caveats should I be looking for when creating these sprites?

Thanks again Ark!

[Arkhan]

The caveat is don't put >256 pixels on a line.

don't think of it as a stack.  Its not a stack.  Do you mean a computer stack?

It's more like a baseball team bench.  all the bench warmers can sit on the f*cker all they want til the important team members want to sit instead.  The sucky people get shoved off.

The bench can only hold 256 pixels.  Some players are fatasses (32 pixels) others are healthy (16 pixels)

[spenoza]

The caveat is don't put >256 pixels on a line.

don't think of it as a stack.  Its not a stack.  Do you mean a computer stack?

It's more like a baseball team bench.  all the bench warmers can sit on the f*cker all they want til the important team members want to sit instead.  The sucky people get shoved off.

The bench can only hold 256 pixels.  Some players are fatasses (32 pixels) others are healthy (16 pixels)

I think the "slots" analogy works OK, too. The only sprite widths available are 16 and 32. So you're either taking 1 or 2 slots of a 16-slot scanline.

As to my figuring of 6 for the character, that was based less off the given example and more off the premise of 3 32-width sprites overlapping on the same scan line. It looks like, as you have posited, that the torso and legs don't overlap any scan lines and that the gun only overlaps the torso. Though if there's 8-way aiming, I see the gun, at angle, overlapping both. I prefer to work in abstracts until I have no choice otherwise, though, so take that into account with my statement.

And thanks for clarifying the sprite clipping order.

As for the bullet example, again, that was assuming 3 32-width sprites, all displayed at the same time. Or did I make a mistake? If two 32-width sprites overlap exactly, thus taking up only 32 pixels on-screen, aren't they still 64 pixels of sprites, or do they only count as 32 sprite pixels in total?

[Arkhan]

Why would any of the 3 sprites in the above example ever clip each other? 

Its 3 separate sprites acting as one.   If they're overlapping on horizontal scanlines, you are doing something wrong and everyone will notice it.

The bullets:  You said you're flickering them.  odd frames = 3 bullets.  even frames = other 3 bullets.  They're never on screen at the same time. 

[Nando]

I was thinking more along a "stack" of scan lines on a TV. Anyway, I like the bench analogy better.

Paul showed me this study he had done on some sprites showing how some of the larger characters are built.



two 32x32 "stacked" sprites where the head barely goes above the top sprite area.

[spenoza]

Why would any of the 3 sprites in the above example ever clip each other? 

Its 3 separate sprites acting as one.   If they're overlapping on horizontal scanlines, you are doing something wrong and everyone will notice it.

The bullets:  You said you're flickering them.  odd frames = 3 bullets.  even frames = other 3 bullets.  They're never on screen at the same time. 

YEah, the bullets were correct. Look, I don't know WHY you'd want 2 or 3 sprites to ever overlap perfectly, but say, hypothetically, they did. Then my example would be correct, right?

I can think of one good reason to have a little overlap. Let's say it is a run n' gun where the character has a big gun. You want the legs and torso animated separately, but you want the gun to have 8 directions of independent movement. In that case, the torso and legs wouldn't overlap, but the gun could, at times, overlap both the legs and torso.

I do agree, though. I was diving too far into hypothetical territory and not addressing his practical request. So let me wax specific to try and make up for it. You'd have 3 16-pixel bullets in any given frame, 32 pixels of torso (or however wide the torso sprite is, maybe only 16), and then 32 pixels of gun sprite (which appears to overlap the torso sprite). In that case you'd have 7 slots in use, or 112 pixels of your total 256 available. If the torso is only 16 wide, that's 6 slots in use or 96 pixels.

Overlapping of sprites is where the bench analogy breaks down a little. If one guy sits in another guy's lap, he still uses up an extra spot on the bench.

[Arkhan]

I'm still not sure if your bullets are correct.  Explain your example again. 

Your overly hypothetical example is best solved by having the sprite-artist properly conform to 3 pieces of a sprite.  You basically draw it as a larger entity (32 wide 48 tall, as the case may be) and once it is FINISHED, you split it into chunks.  This removes your hypothetical overlap shenanigans.

Overlapping doesn't break the analogy.  It's the same thing.  The overlapping is irrelevant to counting pixels per scanline.  you could put 16 16x16 sprites directly on top one another.  The 17th one won't show up.

[Nando]

Technically speaking, is it even worth it to try and build a character sprite like that?


Reason I was looking at that setup is that I would like to have a varied weapon look. The other alternative would be to just keep one weapon art style and animate the sprite more along the lines of Metal Slug on the GBA, two stacked sprites.

[Arkhan]

Building a sprite like your original example is perfectly acceptable dude.  just draw it as the big thang' first and split it afterwards.

That way,sometimes the gun could be up top, sometimes it could be in the middle, or maybe pointed downward. 

If you try drawing it as 3 separate chunks, you're setting yourself up for pain.

[Nando]

Sweet! thanks for the Tips!