Jump to content

Animations Info Management


smashthewindow
 Share

Recommended Posts

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?

Blog & Portfolio

 

Current project: moon.chase.star

Link to comment
Share on other sites

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?

Blog & Portfolio

 

Current project: moon.chase.star

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. ;)

Blog & Portfolio

 

Current project: moon.chase.star

Link to comment
Share on other sites

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 smile.png It's that good, powerful, easy, & fun!

Link to comment
Share on other sites

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 smile.png It's that good, powerful, easy, & fun!

 

Thanks for the replies.

Blog & Portfolio

 

Current project: moon.chase.star

Link to comment
Share on other sites

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.

Intel Core i5 2.66 GHz, Asus P7P55D, 8Gb DDR3 RAM, GTX460 1Gb DDR5, Windows 7 (x64), LE Editor, GMax, 3DWS, UU3D Pro, Texture Maker Pro, Shader Map Pro. Development language: C/C++

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...