Animation.

posted in A Keyboard and the Truth for project 96 Mill
Published November 29, 2005
Advertisement
So last night I did a bit of thinking and a bit of implementation on how I am going to handle frame-animation in the S3Engine.

Then:

In Flare3 we used 'tabled' images, like so.

[0,0][1,0][2,0]
[0,1][1,1][2,1]
[0,2][1,2][2,2]

with all of the frames in a single image, this made referencing an image simple, using an ordered pair (x,y) and you only had one image to worry about. Each 'action' would be it's own image, with frames as columns and directions as rows.


The problem?

The big issue with this method, is that the size and shape of the actual image is very determined on what you are planning to do with it.

For instance, imaagine a 128x128 frame size and a set of 20 images.

[0][1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19]

to store this image it would require a 2560x128 sized texture. Which does not play well with 3D hardware, and under some cards may not be possible at all.


Now:

The alternative to this, is to provide an interface of similar ease (rows and columns), but with a more free-form storage system, namely, induvidual frames.

So in order to do this we use XML to define an ImageTable, it works much like an HTML table, whering the table cells contain the information of what image file to use.
Next Entry more.
0 likes 2 comments

Comments

Gaheris
Have you done any tests to check what kind of performance loss you might get by having to switch between a lot of different textures?
Or will you keep, for example, all frames of an attack cycle in a single image? That should keep the image size in working bounds without having to do lots of additional, performance eating, texture switching.
November 29, 2005 10:10 AM
EDI
Well, it is a complex problem.

Currently the idea is from a game developer's perspective all of the images are seperate frames.

At the moment the engine creates a new texture for each loaded image.

I imagine that I will have to eventually implement a palette system to 'group' incomming textures.

I was recently working on a palette system, but it was begining to complicate things, and there were some doubts in my mind as to what kind of problems not having one would cause.

Since the loading of images is it's own little system, i can likely design in a palette system later if i find we are experiecing issues.


What we dont want to do is (from an art perspective) keep frames in a single image file. we did this before and it brought about some serious performance issues (that were barely fixed). the reason is that we cannot assume a max texture size, and even so certain image 'sheets' would be larger than the largest possible texture size.
November 29, 2005 12:05 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement