• entries
    500
  • comments
    1888
  • views
    333622

Animation.

Sign in to follow this  
EDI

58 views

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.
Sign in to follow this  


2 Comments


Recommended Comments

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.

Share this comment


Link to comment
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.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now