Re: Main character animations.

[Katie Lauren Lucas <katie@fysh.org>]

Quoting Steve Baker <sjbaker1@airmail.net>:

> Katie Lauren Lucas wrote:
> > 
> > So I'm toying with this 2D spritey game idea. Has a main player
> character which
> > has lots of pick-upable weapons (guns, bows, swords, spears). So I'm
> wondering
> > how to handle this graphically. I can think of:
> > 
> >   1) Tons of sprites, going to need each weapon X each direction X
> each frame
> > of animation.
> 
> Well, modern machines have an insane amount of RAM.  You should be able
> to
> do a back-of-envelope calculation to know whether this is reasonable
> for
> any given value of X and sprite size.

RAM I don't care about. It's drawing them all that's the issue...

> >   2) Layers of sprites, one to animate the main character, one to
> overlay a
> > weapon on him/her. Issues of alignment, it might end up lacking
> graphical
> > sophistication. I have a feeling this ends up needing (weapons X
> directions X
> > frames + directions X frames) images in total.
> 
> I think this is the answer - although I'd probably write the code to
> rotate
> the weapon sprite on-demand.  So you'd hand-paint a sword (say) laying
> horizontally
> and then when the player picks it up, have the game code generate all
> the rotations
> you need into a cache.  As each new weapon is picked up, you generate
> it's sprites - and
> if your cache is full, you toss out the oldest weapon's sprites.

Hmm. That's an interesting idea.

A friend of mine's doing research into real-time volume rendering technology; 
he's got 500x500x500 volumes happening... I guess creating a set of (dinky) 
sprites from a volume set could happen...

> I doubt that the time to generate all those rotations would be too
> significant - but
> if it is, generate each of the rotations on-demand, remembering which
> ones you've
> done and which are missing.
> 
> I don't think the "Issues of alignment" should be too significant -
> although
> you might have interesting problems when you'd like parts of the
> player's body
> to block the view of the sword - whilst the sword simultaneously blocks
> the
> view of other parts of the body.

That's the sort of thing - yeah.

> >   3) Cheat. Have the player carrying an indistinct black blob.
> > 
> >   4) Sophisticated cheating. Player carries nothing, when he starts
> fighting he
> > draws a weapon. Not sure this reduces images much.
> > 
> >   5) Not caring. Player carries a sword. All the time. If he's got a
> gun he,
> > erm... appears to shoot with a sword. Heck, if RPG players can cope
> with an "@"
> > being a person...
> 
> Na - those all suck.

Heh.

> > In a 3D game this would be easy (attach appropriate weapon mesh to the
> player
> > character's "hand" matrix)... but how do people do this in 2D games?
> 
> Well, it depends on the resolution of the sprite.  If it's *very* high
> res then
> it's going to be a problem.  If it's lower res then just rotating the
> sprite
> whenever you draw it isn't impossible.

They're not just top down though - they're a 3/4 view.
 
> You are probably thinking of sprite rotation as involving lots of sin()
> and
> cos() calls - but you can be smarter than that.
> 
> Suppose you built (slowly) a set of tables - one for each position a
> weapon
> might need to be in. Each entry of each table would correspond to one
> pixel
> in the rotated image and would contain a number indicating which pixel
> within
> a UNROTATED sprite would end up at this position in a ROTATED sprite.

AH!!!

Now there's a thought... I could store the "sprites" as areas of indirections 
into a volume and indirect back through them to a volume which holds the actual 
appearance: this would mean creating just directions X frames of indirection 
data.

The "weapons" and "characters" are volumes of pixel data.. in a neutral pose, 
with the indirections giving the posing. I can then update the volume when I 
need to change something... suddenly it's practical to do things like change 
what a character is wearing...
 
> That table can then be used to render *any* weapon using a simple static
> image
> of the weapon.  It could even be used to mask part of it out where the
> player's
> body occludes it in that position.

 
> Hence *one* (admittedly large) set of tables - one for each of your X
> positions -
> will allow fast rotation of *ANY* object that the player might need to
> hold.

Yeah...

> This would allow for interesting game play where the player can pick up
> monsters
> or selected parts of the scenery and bash other hapless creatures with
> them!

Bar stool fight!!!

> Generally this kind of crude rotation aliases nastily because there is
> a
> 1:1 relation between the 'output' pixels and the ones in the unrotated
> sprite.
> 
> You could get around that (for example) by storing FOUR pixel addresses
> at
> each location in the table - along with a number to multiply each one
> by
> before adding them together and writing them to the frame buffer. 
> This
> would produce quite nice antialiased sprites.

Yeah... hey this could work. Fiendishly convoluted, but it would get me the 
results...

Nine pixels would be better, because then I can top-hat filter the anti-
aliasing so it doesn't blur the detail too much.

> Bear in mind that not many pixels of your output image have to go
> through
> this complicated process - so it's not much of a stretch to presume
> that
> you could rotate weapon sprites in realtime.

And they can be cached...

> It's hard to give advice without knowing:
> 
>   * How big is 'X' (the number of sprite positions your player has) ?

8 facings.

>   * What resolution will your sprites be?  (32 pixels? 100? 300?)

32x32 ideally.

>   * How many weapon types do you need for each 'level' of the game?

No idea. Dozens. (I'd like to be able to change the clothing as well..)

>   * What CPU speeds do you want your game to accomodate?  (Does it
>     have to run on 33MHz 486's?  Can we assume a 266MHz CPU?  Maybe
>     it's going to take a year to write and only run on cutting edge
>     processors at 4GHz?!)

200MHz as a low bound.

>   * How much RAM are you going to require the player to have? 16Mb?
>     2Gb?
> 
> The nature of the answer depends critically on these questions.

I'm going to have to sit and think about this now...


_______________________________________________________________________________
      Katie Lauren Lucas, Consultant Software Engineer, Parasol Solutions
katie@fysh.org katie.lucas@parasolsolutions.com http://www.parasolsolutions.com