Ideas for Animator

I am trying to create a program that I will be able to make the animations store the data and then play back the animation in the given time. To store the data I started to use MAXML by John J. witch is great.
My problem is that to make this trick for evry keyframe I have to store the original position of the Object , the Length in millisecs of the Animation , the disired new position of the Object , a Byte to check if it is playing , and the time in millisecs the animation begun to play.
Total 5.
As I am working for 2D in BlitzMax I have.
Original Position : x:double 64 bit , y:Double 64bit TOTAL 128 bit
Length : int 32 bit
new position : like the original 128 bit
playing : byte 4 bit
Start time : int 32 bit

This method gives me total 324 bit just for a keyframe.
And other stuff to play it...

My questions are :
Is it worth it to be done this way?
Are any other methods to do this trick?
It will be good for skeleton animation?

I am not giving any code right now cause I deleted my previus job as I descovered the power of the MAXML.

EDIT:
I changed the KeyFrame and now have

Length:int -> millisecs
Angle:double[] -> for evry bone that had changed in respect with it's parent bone
preAngle:double[] -> that it's just for help to keep track what changes maded.
JointNumber:byte[] -> that it's the position in the array of the Skeleton.

I also finished the trick..

I'll give this thread a bump for you. I find it reasonbly interesting and would like to see some responses.

I'm not sure I understand exactly what you are trying to do but...
Why not just use a standard keyframe system.? You don't need to store the Old and New position just the New. The time is denoted by the keyframe number so the length and start values would not be necessary.
You can then "capture" the animation at say 24 times a second storing the X and Y position and the frame number. You can then playback at the same rate to replay the animation

For Skeletal animation it would be much better to just use a standard keyframe system - using quaternions or matrices for rotations.
The motion capture function in PaceMaker works by precisely "sampling" the position and rotation of each bone at the rate set by the user. The rotation values are transformed to a quaternion (4 floats) . The X,Y,Z position values are stored as floats. The frame number is stored as an int. That's all the data you need.

Oh it's back.
Well I finished the overall stacture I havent tested to much but it looks that it works ok.
Smiff : Capture the frame 24 time in second it's the original idea that comes with the the most file formats ( At least the formats that I have seen )
What I was thinking was to create a system that will update in real time the position of the bones.
This will result that the new position of the bones will use the CPU power to get their new values at evry game loop and the animation can become smouther as the FPS stay hight.
For example if you get 60 fps the animation will be 60 fps and as I am doing it for 2D I hope that this will stay hight.
The keyframe has changed and now it have:
Length:int -> millisecs
Angle:double[] -> for evry bone that had changed in respect with it's parent bone
preAngle:double[] -> that it's just for help to keep track what changes maded.
JointNumber:byte[] -> that it's the position in the array of the Skeleton.

I will open this to the community as I will finish it and make a proper GUI.
As I believe that the community can help to be this idea better and faster.

I don't understand - why are you using bones if it's 2d animation ?
You may get 60 fps initially without animation but this will drop as soon as you start to real-time update bone positions - especially if you use a number of animated models or models with a high poly count so there's no guarantee that the frame rate will stay at 60fps - however I'm still confused by 2d + bones so maybe I'm talking rubbish !!


I think that updating the position of the bones in real time every game cycle would result in even slower skeletal animation.
Using the inbuilt animation system would generally be faster because it is happening at a lower level using transformation matrices - there is no need for a euler to quat or euler to matrix conversion routine and normally its quicker to calculate tween values than calculate an absolute position each game loop. Don't forget that Blitz (DirectX7) has to calculate internally the position of each vertex whenever a joint is rotated as well.

Well the overall idea came from the book Illusion of Life.
Years before someone said to me that the game Another World was created with the same technic of skeletal animation of the 3D aplications.
In this thread : http://www.blitzmax.com/Community/posts.php?topic=56157
Garion talked about MoHo : www.lostmarble.com/moho/index.shtml
When I saw it I thought this is a very good idea to store animations and why not to play back them.
I started to create it and I was in a good road but then I saw MAXML by John J. : http://www.blitzmax.com/Community/posts.php?topic=56469
I was overreacted when I understanded how good is and I deleted my work to start over. But this turned good after all.
About speed I agree with you Smiff but after all it will be easy to bake the frames in any given FPS speed.
The bigest problem is that I am coding only one year as I found my way in this field only with BMax.

After looking at the MoHo link I now understand a little better. It uses 3d animation techniques to produce 2d output. I understand what you mean about the framerate now ! I think the playback method you describe would only work if you stored all the lines as vectors as well otherwise what are you going to transform ? I'n not sure how a vector system works but it's a very interesting subject !

Vectors are almost evrything ( for me ) when it comes to code anything that have realation with graphics.
The best intoduction I have found is in the www.FlipCode.com : And at the column 3D Geometry Primer : Chapter 1

I don't think you need to use Doubles for your positional data. You're talking about parts of a pixel. Pixels are so small, you aren't going to notice if a regular Float is a little bit off or slightly less accurate. I think you are wasting space with that. I'm not saying to not care about having it very precice positioning, just that a Double is not really giving you any benefit.

As to the animating itself it sounds like you're in the right direction. I don't know that you really need XML to store it, except as a file on a disk. There are more efficient formats for runtime - use an array or something.

AngleDaniel I agree for the position.
But the XML stores the data like a skeleton. Parent with Childs... It's only for storing all the others as you said are Arrays.
Also as I finished it and I know that you are a BMax user do you thing it will be good to make a thread with this before I finish the GUI.

I just finished the first very early version.
I give the source in BMax.
Here is the Link : http://www.blitzmax.com/Community/posts.php?topic=56804