Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by grimfang4

  1. That would be great. Can you email it to me or attach it to a new issue?
  2. Maybe passing nothrow to new would be better than adding exception handling?
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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.
  9. 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.
  10. 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.
  11. 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).
  12. 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.
  13. 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/
  14. 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.
  15. 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.
  16. Box2D is definitely an exciting direction to go with animation. I think the simplest way to have the physics and animation systems interact is through forces. The programmer would have to specify the max force and limits of each joint and those would be used to let the animations move through the motions as well as they can. The transform info wouldn't make drawing any easier, since the underlying animation library should take care of that. What it would do is let you know where in the world an object is more for the purpose of in-world interactions. Say you want to spawn particles where the player's torch is held or you want to tell if the hand is near a button on the wall. As for rendering, SCMLpp can use SDL_gpu or SFML to render, which both use OpenGL. An implementation to join Box2D, Spriter, and more would certainly work, but any work we do at this point is not going to be a popular solution. Whenever you go down that road, you have to make choices which either restrict flexibility (which scripting language do I use?) or increase complexity (any scripting language, but the setup is a pain and the support code is a mess). Box2D also does not support a high-level interface. You need to do a lot of work to write Box2D code that will work easily for multiple types of games. The end result once you bring in graphics, animation, audio, and scripting feels much more like Ogre or some other all-encompassing game engine that forces a structure and libraries that are hard to break out of. This early in the process (Spriter hasn't gotten to 1.0 yet), it is much more useful to write games that will act as concrete examples of how to use all these pieces together. As Spriter gains popularity, I think you'll see existing game engines incorporating it and you'll get all of those features by choosing one.
  17. No prob. Good luck on the rest of the implementation and feel free to ask more questions of course.
  18. I mentioned that it doesn't use matrix math not because you can do without matrices, but that you have to. Proper matrix math will not work with the way transforms are expected to be composed. Specifically, scaling directions are not rotated as they would be when composed as a matrix. I'm not a total fan of the way it is since it can't be represented just with matrices, but it works fine anyhow. Yes, the C++ implementation does handle bones. It should handle everything that the latest alpha version of Spriter supports.
  19. SCML does not use matrix math. There was some discussion of implementation technique in another thread. Have you gone over the plug-in documentation? The C++ API is a good reference, too.
  20. Awesome. :) Please send me the tweaks if you think they apply to others, too.
  21. If you really want Torque support that stays up-to-date with Spriter, the best bet would be to collaborate with me on the C++ API: viewtopic.php?f=3&t=1133 If someone is willing to write a Torque renderer for SCMLpp, the work would be minimal and it would be kept in sync with the other renderers.
  22. There is now an interface to get current bone and object transforms. This can be used both for drawing bones and for in-game effect placement. Let me know if you have any feedback or suggestions on this: int SCML::Entity::getNumBones() const; int SCML::Entity::getNumObjects() const; bool SCML::Entity::getBoneTransform(SCML::Transform& result, int boneID); bool SCML::Entity::getObjectTransform(SCML::Transform& result, int objectID);
  23. Yeah, r110 was replaced with r110.2: https://www.scirra.com/construct2/releases/r110.2
  24. My library complains of duplicate mainline object IDs. From a glance at the SCML, it looks like you don't specify the "id" attribute of the mainline objects. Is there a better place to host these files so that collaboration is easier? If you don't have anything else, you're welcome to merge the test suite into my repository and maintain it there.
  25. Thanks Pat. The STL is definitely avoided on some platforms for good reasons. I'll make it easy to replace for now, then in the future I can consider replacing it permanently. That concern is always in my mind when I write a library, but is usually outweighed by the comprehensive containers that the STL provides.
  • Create New...