TFS!!

Great work, bwwd.

Make box (collision) and give it a name. Save file. Change mind. Load file and delete box. Make new box. Can't use same name. Reference to the original box still exists in .scml file. Sometimes (while creating) boxes don't seem to render until mouse-up (win7 x64). Would be good to document that boxes can have negative dimensions depending on the corner/direction the artist starts creation from - had assumed they'd be positive and in a test today was wondering why collisions were giving oddball results.

"Crashing" is a bit too vague - I've used Trixt0r's lib for some personal pet projects to play with and can say reading scml's worked just fine for me (on physical devices). It would be near impossible to guess what the problem is without some more information. I assume you've debuged the apk with Eclipse/DDMS (or the equivalent in Android Studio), debug window should print out some kind of exception error or whatever which should be giving you an idea of the problem (?)

Didn't have a chance to play with Trixt0r's latest update, unfortunately. Will try to get to it this weekend, if possible. Boind, do you have a project you can share demonstrating your memory issue? In my case I was only seeing small bits of mem being collected constantly and I was able to resolve them. A standard/typical test case would be handy because I am doing things radically (horrifically) different from the start :)

trix: Very cool, will take a look soon!

Hrm... That seems a bit excessive, but I haven't profiled multiple Spriter files yet. It would be nice if Spriter had a built in option to strip out all the useless whitespace in either of its xml/json formats, we could then use slightly smaller buffers and it would be faster to parse. So, one experiment would be to strip it yourself beforehand. I'm going to assume the xml parser will be able to manage it. JSON would be a bit better, but Spriter's JSON (SCON) format seemed a bit off to me compared to all the JSON I'm used to seeing, and someone would have to add a parser/loader but that's not a huge deal... Also, are you Atlasing your textures on the fly? (this is not ideal) There's probably an impact there that needs examining.

In a game loop, anything that give the GC something to do needs re-thinking :) Performance is not the problem, but the GC kicks it in the balls when it is invoked. It's more a separate technical issue - and I tested on Nexus 7s, not exactly weak devices. That's also a reason why libGDX provides its own implementation of collections, it hangs on to its iterator so it doesn't get GC'd. There are some limitations to it, but it works well. Personally, I avoid iterators altogether. Of course, in dropping them you'll trade a little elegance but the end result is what matters.

Nice work, Trixtor. The Good: Looking good after refactor, and quite easy to use. The Not so Good: A cursory test on Android reveals the garbage collector is constantly kicking in, causing stuttering. The liberal use of iterators (ugh) in the library is leaving a quite a bit of memory (tracked in DDMS) out to hang every frame on 6-8 concurrent animations, regularly collecting ~512k. Not acceptable for any serious project :) Easy to remedy, if you wish to be friendly to the Android platform.

Unless I'm mistaken, it's just a configuration problem. In libgdx, you'll need to find your entry code (desktop and android have their own) and it may look similar to: public class Main { public static void main( String[] args ) { LwjglApplicationConfiguration config = new LwjglApplicationConfiguration(); config.title = "My App"; config.useGL20 = true; new LwjglApplication( new App(), config ); } } In a GL10 configuration, your textures must be power of two (if the useGL20 option is set to false, libgdx defaults to GL10). You'll want it to be set to true to avoid these errors, as GL20 can handle non-POT textures.

Odin Sphere (PS2) & Dragon's Crown (PSV/PS3) are worthy mentions. Vanillaware's tools are more advanced tools as they allow deformations, but perhaps Spriter will work that in eventually. The larger enemy types in games like the Castlevania games for GBA/DS often operate the same way, built with bones/joints...

Sounds good, Zelex. Looking forward to checking it out...

Interested - count me in :)

Since it seems that manually moving or deleting images can cause issues, I might recommend that the program notify the user when it comes across non-existent files as a sanity check. And if the user desires, perhaps Spriter should clean up after itself and eliminate all internal references if the user doesn't care for the missing image(s)? I ran across this scenario like a couple others on this board, in my case (and I only just started playing with Spriter) I added a mockup image to my project to help me place & align pieces, then I wanted to get rid of the mockup, or at least tag it somehow so my own exporter can deal with it - but no real options to best manage this case (unless I missed something). I manually deleted the image, loaded the project and resaved. The internal reference is still in the scml, which means adding some hackery to my own exporter to get around this... Perhaps some thought could be given to this, or project management and flexibility in general. Cheers