Meaning one whole character sprite made up of three pieces. Isn't that what the second Toumaden game does?
Title: Re: Question about sprite layering on the PCE
Post by: sunteam_paul on April 27, 2012, 05:45:45 AM
Simple answer: Yes.
Be aware of the sprites per line limitation in the game design though.
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 27, 2012, 06:04:00 AM
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.
Title: Re: Question about sprite layering on the PCE
Post by: spenoza on April 27, 2012, 07:14:49 AM
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?
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 27, 2012, 08:29:40 AM
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).
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 27, 2012, 08:39:18 AM
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!
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 27, 2012, 08:43:13 AM
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)
Title: Re: Question about sprite layering on the PCE
Post by: spenoza on April 27, 2012, 08:52:10 AM
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?
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 27, 2012, 08:58:42 AM
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.
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 27, 2012, 09:04:54 AM
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.
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.
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 27, 2012, 09:23:18 AM
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.
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 27, 2012, 09:23:23 AM
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.
Meaning one whole character sprite made up of three pieces. Isn't that what the second Toumaden game does?
Assuming the upper torso frames *never* overlaps the leg frames (even by a single pixel), the gun is overlapping both. So at any point the gun sprite is taking up 4 slots (16x16 sprite slot) for a total height of 16 scanlines (the torso needs a minimum of 32 wide sprite for the most of it and same for the legs). That's 64 pixels or 1/4 the total allowed sprite pixel bandwidth for that given scanline. That's very wasteful IMO unless you specifically NEED to do this. If you're trying to build out more complex animation based on 'section' animation for sprites, well.. I'd probably use ram to pre-composite them at the start of the stage or when an event changes. The method of overlapping sprites is pretty popular in arcade game design at the time of the 16bit era, but they had a lot of sprites to throw around per scanline, so it wasn't a big deal.
Either waste the rom/cdram space for the precomposite frames, or composite them yourself (code) into a prebuild sheet when needed during runtime/downtime/whatever-time. Otherwise (like others have stated), you're gonna waste through your sprite scanline bandwidth. Also remember, flicker doesn't happen unless you code it to happen (sprite priority shifting). Sprite cells (16x1 resolution, not 16x16) get dropped when sprite bandwidth is exceeded for that scanline. The lower priority sprites in the sprite table (SAT) get dropped over the higher priority ones (earlier entries in the SAT). The priority flag of the sprite to the BG layer has no effect on this either (they're all treated by what number they are in the SAT - nothing else). Remember, that means *non* visible sprite pixels too! If you have a sprite object that only takes 6-8 rows of consecutive visible pixels in that cell, the rest of the rows still get 'calculated' into the sprite bandwidth for the scanline they land on.
Title: Re: Question about sprite layering on the PCE
Post by: spenoza on April 27, 2012, 03:17:48 PM
I'm still not sure if your bullets are correct. Explain your example again.
Happy to. Er, which part, and starting where? Are you only concerned with the bullets or the bullets and the character? If I'm wrong about something I want to know why so I can get it right next time.
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 27, 2012, 04:00:30 PM
That's why it is best to predraw everything and make chunks up after that.
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 30, 2012, 02:59:39 AM
Wow, I had a good chunk of things to think about this weekend.
My goals are to have varied walk animations. The game will have slower paced levels where walking makes more sense and wider fields for running. For this I thought that I could split the sprite in two and create different walk sequences. Cutting down on some time by just having to animate the legs and hopefully getting some cool extra secondary animation potential.
I also wanted big f*cking guns,! having a character master template to which I could "plug" in the different guns made sense. Meaning I could have a base sprite with a area reserved for the different gun designs.
Right now it seems like a Metal Slug like setup makes the most sense, any other things I should think about?
You guys are pretty awesome, thanks again for all the great feedback and information
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 30, 2012, 03:14:29 AM
One thing to remember is that you have limited space, so you should probably cheap-out on some frames where possible so that you can have lots of varied sprites in general.
Your gun idea could work, but would probably result in it being harder to manage. With the approach I mentioned (make the sprite and then split it up into chunks after the fact), you could get away with alot more obnoxious animations.
However, you'd have more space used up trying to make all of the varieties you'd probably want.
Might not be a huge problem though . It depends how often the gun changes. You can always just load new graphics off a CD when you need to change appearance.
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 30, 2012, 03:58:58 AM
what would the lag be like when loading a new gun? I rather have one gun with different shot types, than have a whole bunch of guns that could kill the pace of the game due to load times.
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 30, 2012, 04:12:20 AM
Well, if you plan on say 5 guns, and have access to 5 guns in each level, it could be kinda lame to keep loading.
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 30, 2012, 04:30:38 AM
Reload
Reload
Reload
Time crisis nightmares!!
2 Guns per level really, MAYBE three guns, stock and two others per level. Guess the player could always pause and switch weapons while a little SideArms logo floats around.... :D That wouldn't kill the action, would it? For some reason I think the Metal Slug setup might be easier to manage? yes, no?
Anyway, that's my idea for one player type.
Other player type is inspired by Mizubaku (http://www.pcengine.co.uk/Images-Screenshots_L-R/Mizbaks_Adventure_02.gif) and mystic defender (http://www.consoleclassix.com/info_img/Mystic_Defender_GEN_ScreenShot2.jpg)
with power ups coming in the way of "familiars" like Air Zonk.
Title: Re: Question about sprite layering on the PCE
Post by: Arkhan on April 30, 2012, 04:39:52 AM
its going to be one of those things you wont know til you try.
You have to see how many frames each thing turns out to be to see how much space your sprites take up. :-/
Title: Re: Question about sprite layering on the PCE
Post by: Nando on April 30, 2012, 05:44:32 AM
TO DA DRAWING BOARD!
Title: Re: Question about sprite layering on the PCE
Post by: spenoza on April 30, 2012, 09:45:10 AM
Well, with the protocard heralding a new rom-based card, and the new flash card on the horizon, I'd say a cart game would probably work pretty well, too.