grimfang4

That would be great. Can you email it to me or attach it to a new issue?

Maybe passing nothrow to new would be better than adding exception handling?

I'm not personally against using C++11 or STL (I would prefer that, in fact), but I did get a request to make the backend more generic so that the STL would not be required. There are some cases where one would be justified in avoiding the STL... though most of those may be considered premature optimization. I haven't been maintaining SCMLpp lately, so if you want write access to the repo, just send me an email.

Oh sorry, I thought I had hit send on my reply to that last one. Oops. :( The Data objects are not needed after the Entities are created. Consider Data to be a definition and Entity to be the instance. You can create multiple instances from one definition and delete the definition any time. The definition is simply the interface to the actual SCML file. The Entity is the interface with the display/user. Entities do need a unique ID for many applications, but that is specific to the use-case. Entities are technically uniquely identified by the pointer value, so it is up to the game developer (i.e. user of this library) to decide how to store and identify them for the purposes of the particular game. However, if you think this is much easier to do already for the user, we could do it. Yes, the FileSystem storage class does not work as intended. It directly stores the SCML file/folder IDs, which are not common across multiple SCML files. What it needs to do is to provide a translation from the SCML IDs to the unique FileSystem IDs, which would be used by the Entity class.

Let me know what changes are needed. I don't know any other XML API (and I know streaming like Expat is so different), so I can't factor that out myself.

Cool. As a matter of course, I'll be replacing TinyXML with TinyXML2 when I get around to it. It's very similar and, as a convenience bonus, is contained in only two files.

Google Code does not let you just right-click and save the files that way. Those are HTML/Javascript files that control page layout when browsing the repository online. Really, a Subversion client is the way to go (how it is intended) and it's not tough at all to set up (and uninstall as necessary). You can get the raw files from Google Code with a few more clicks (browse the file, click "Show details" on the right, then click or save-as "View raw file". Here's an example of the URLs involved: Browse Doxyfile: https://code.google.com/p/scml-pp/sourc ... e/Doxyfile Raw Doxyfile: https://scml-pp.googlecode.com/svn/trun ... e/Doxyfile

Let me point out that the topic here is for an API (interface being the key). Using Box2D is an implementation detail that only potentially applies to some plugins/engines. It's more important to have similar features and similar interface no matter what platform you use to display and manipulate SCML data.

With software rendering, a painter's method is assumed. Things drawn later always draw on top. In hardware/GPU rendering, the framebuffer has a depth component in order to clip geometry (or fragments) based on the projected distance. In straight OpenGL at least, you can disable depth testing to make things draw in order.

Well, storing pointers to vector elements (in our case actually map elements) can indeed be hazardous as changes to the container can cause reallocations. However, storing pointers in a vector or map is perfectly safe. They're just integers, after all. The only way for it to go wrong is if something else tampers with the data stored at the address which the pointer points to. This is a very common problem. Using image data as a specific case, most of the time it is code (client code, asset manager, etc.) that deletes (frees) the image data and does not ensure that references to that data (i.e. the map) are cleaned up. Autopointers are often a good solution. I don't know how Shiva3D manages images/textures. Other times, memory errors (double frees, array overruns, mismatched struct definitions, etc.) can mess with the pointer value and then all bets are off. If you can set up a Linux development environment, I highly recommend using Valgrind for catching those memory errors in any code you write.

There's not a good interface for looping control yet, either. SCMLpp takes the looping setting for each animation from the SCML file. The variables which store that info are Animation::looping and Animation::loop_to (just as in the SCML spec). Animation::looping is a string, so my_anim->looping = "true" would make it loop. Animation::loop_to is an index to the key that comes after the loop (defaults to 0).

Thanks 8DashP. I'll work in those changes as soon as I can. Can you tell I don't have VS installed? :) BigJDTec, you can check the index of the current animation (int Entity::animation) and if I remember correctly, it's safe to change it as long as it stays less than Entity::getNumAnimations(). I would like to add a better interface for that. There is not currently an easy way to see how far along the animation is, but if you look at Entity::update(), you can use some similar code to compare the current time to the time for the entire animation. I invite you guys to send me any suggestions for APIs like that which you would find helpful. If you write an implementation of it, that's even better! I can set you up with commit access to the repository, just send me an email. I do intend to get all the features we need in there (including texture atlas support), but it depends on how much time I'm spending on projects using SCMLpp.

BigJDTec, that's very cool. Let me know if there are any code changes that are worth contributing. StOrM3, I'm a little busy, so it might just be faster to get you SVN client set up. I did see this floating around, but I can't vouch for its safety/reliability: http://svndownload.eu5.org/

Hey StOrM3, since I don't have or use that particular engine, could you give the implementation a go? Take a look at SCML_SDL_gpu.cpp. If you can load an image (FileSystem::loadImageFile) and draw a centered image (Entity::draw_internal), then you're all set. Check out the GETTING_STARTED.txt for a little more info.

I think tweening each bone/object is the only way to go. The results would be different if you tweened the final results instead because parent rotation tweening would be converted to child position tweening and it would be an ugly mess.