Question about sprite layering on the PCE

[Arkhan]

beef tips!

[Bonknuts]

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?

 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.

[spenoza]

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.

[Arkhan]

That's why it is best to predraw everything and make chunks up after that. 

[Nando]

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

[Arkhan]

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. 

[Nando]

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.

[Arkhan]

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.

[Nando]

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.... 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

and mystic defender


with power ups coming in the way of "familiars" like Air Zonk.

[Arkhan]

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.   :-/

[Nando]

TO DA DRAWING BOARD!

[spenoza]

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.