Animations Info Management

[smashthewindow]

Just curious, how are everyone managing their animations system?

I don't want a bunch of big enums or defines in code, so I'm thinking of creating a separate XML file to save the animation info there. (Or I might just save them as entity keys and cast them...)

How are everyone managing animations?

[Rick]

Stored in SQLite. Read in when loading the scene which creates a class instance for that model and looped through adding Animation instances to a map for each animation.

[smashthewindow]

Stored in SQLite. Read in when loading the scene which creates a class instance for that model and looped through adding Animation instances to a map for each animation.

 

is there a significant speed difference or advantage between saving it as SQLite database and XML file?

[Clackdor]

Whats wrong with use enums?

 

Hrumph.

[Rick]

http://stackoverflow...-for-a-database

 

The entire this is interesting to read, but look at the very last question. The thing that stands out the most about the last post is that the programmer doesn't know if the way he was parsing XML was the fastest way or not. The nice thing with using SQLite is that the file I/O is done for you in the fastest way it could be so you don't have to care about that stuff. There are lots of good points about both but I would ask is speed really that big of an issue? If reading your data from XML took 2 seconds vs say 2.3 via SQLite, will that sell you on using XML? I feel SQLite's benefits are far more than XML's for game data, but I know SQL. If you don't know SQL you might not see it that way. As some in that post have pointed out (correct in a sense), XML is basically designed to transfer data between systems in a uniform way.

 

 

Whats wrong with use enums?

For animations, it's just hardcoded in your program and any tweaks you want to make requires recompiling. It can just be more efficient if all that is defined outside your app.

[smashthewindow]

http://stackoverflow...-for-a-database

 

The entire this is interesting to read, but look at the very last question. The thing that stands out the most about the last post is that the programmer doesn't know if the way he was parsing XML was the fastest way or not. The nice thing with using SQLite is that the file I/O is done for you in the fastest way it could be so you don't have to care about that stuff. There are lots of good points about both but I would ask is speed really that big of an issue? If reading your data from XML took 2 seconds vs say 2.3 via SQLite, will that sell you on using XML? I feel SQLite's benefits are far more than XML's for game data, but I know SQL. If you don't know SQL you might not see it that way. As some in that post have pointed out (correct in a sense), XML is basically designed to transfer data between systems in a uniform way.

 

TinyXML is pretty mature & stable, and the only place where I have to save to an external file is settings & animations (since my game doesn't even have save), so I'll still to XML for now.

When I work on something more complex, I guess I have to option but to learn SQL.

[Rick]

I've used TinyXML and it works well too. If you don't know SQL then for sure stick with XML. I would recommend learning SQL at some point for any programmer because it's very handy in a million different ways. It's very powerful stuff and would serve you well in any corporate setting you may find yourself in. I can almost promise you once you learn it, you'll most likely never go back though It's that good, powerful, easy, & fun!

[smashthewindow]

I've used TinyXML and it works well too. If you don't know SQL then for sure stick with XML. I would recommend learning SQL at some point for any programmer because it's very handy in a million different ways. It's very powerful stuff and would serve you well in any corporate setting you may find yourself in. I can almost promise you once you learn it, you'll most likely never go back though It's that good, powerful, easy, & fun!

 

Thanks for the replies.

[Road Kill Kenny]

I am also storing my animation start frames end frames and speeds in sqlite.

[Pixel Perfect]

To be honest anyone could learn the basics of SQL in a day. It should never be held up to be an obstacle to using SQL Database technology. Plus, its unlikely anyone will be querying more than one table at a time which further simplifies the scripts, its not like the constructs are going to resemble a huge relational database! With a good SQL front end for editing purposes this is almost a 'no brainer' for storing game related (especially configuration) data.

[Road Kill Kenny]

Yeh I agree with pixel. You can learn the basics of SQL in a day or less. At least enough to use in your games. I'm living proof. I just did it last Thursday.