[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Main character animations.
Quoting Steve Baker <firstname.lastname@example.org>:
> 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
> > 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
> do a back-of-envelope calculation to know whether this is reasonable
> 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
> > 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
> the weapon sprite on-demand. So you'd hand-paint a sword (say) laying
> 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 -
> 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
> 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.
> > In a 3D game this would be easy (attach appropriate weapon mesh to the
> > 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
> 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()
> cos() calls - but you can be smarter than that.
> Suppose you built (slowly) a set of tables - one for each position a
> might need to be in. Each entry of each table would correspond to one
> in the rotated image and would contain a number indicating which pixel
> a UNROTATED sprite would end up at this position in a ROTATED sprite.
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
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
> of the weapon. It could even be used to mask part of it out where the
> 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
> This would allow for interesting game play where the player can pick up
> or selected parts of the scenery and bash other hapless creatures with
Bar stool fight!!!
> Generally this kind of crude rotation aliases nastily because there is
> 1:1 relation between the 'output' pixels and the ones in the unrotated
> You could get around that (for example) by storing FOUR pixel addresses
> each location in the table - along with a number to multiply each one
> before adding them together and writing them to the frame buffer.
> would produce quite nice antialiased sprites.
Yeah... hey this could work. Fiendishly convoluted, but it would get me the
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
> this complicated process - so it's not much of a stretch to presume
> 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) ?
> * What resolution will your sprites be? (32 pixels? 100? 300?)
> * 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?
> 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
email@example.com firstname.lastname@example.org http://www.parasolsolutions.com