Breush

Good job!

Just one more remark: you should replace the calls to getObjectInstance(std::string objectName) by getObjectInstance(const std::string& objectName) in order to avoid useless object construction.

@lucid Thank you so much for your answer. Using "getObjectInstance()" seems very logical, I did not see it sooner somehow. However, I'm always getting (0, 0) via myBox->getSize(). (Even after a myEntityInstance->reprocessCurrentTime()). So, I suppose there's a bug. By the way, what's the convention for size and scale: do the size is the effective one (already scaled)? For the zOrder, that's all right, I guess it's not a big overhead. I was just wondering. And, I suppose it would require a Spriter update to enable boxes/points with no zOrder information.

I wanted to encode a collision box in Spriter using the "box" feature. Can I retrieve the current box bounds in SpriterPlusPlus by its name "hitbox"? And I noticed the box is in the zOrder even if renderDebugBoxes is disable, is this expected behiaviour?

I found out what the problem was, and it was not SpriterPlusPlus fault but mine. Reason was: I use a "model" image to place the different limbs of my animation correctly in Spriter. However, it becomes useless once in game. So I removed the line "<file id="6" ... />" by hand (back in the day) from the SCML file. But the current loader is guessing the file id, and not reading it, so all files id afterwards where wrong for SpriterPlusPlus. That's it. (Reloading the broken file in Spriter and saving a new version fixed it easily).)

@lucid Hey, awesome work! That does fix some animations issues I had left. Thanks! No more problem so far. Oh, in fact, one problem: "SpriterEngine Error: EntityInstance::getFile - file id -1 out of range", any idea why this happens? You should take the pugixml loader from there: https://github.com/Breush/SpriterPlusPlus As my fork won't be useful anymore, I'll just delete it. Well, I might make a final pull request fixing the compiler warnings (signed/unsigned comparisons + constructors reorder).

Oh, Okay. As I left-clicked the play button, I thought this button did not what I expected it to do. English is not my native language and "Repeat Playback" tooltip was not very eloquent to me. But I understand now, thanks. So now that I tested it with a file containing a non-looping animation, I can safely say it's not working in SpriterPlusPlus. -> Happens when I have a time step that does not divide the length (in time) of the animation.

I needed to set looping to false for a specific animation. I made a way to overwrite the default value via entityInstance->currentAnimation->isLooping but that did not work. Is looping a thing yet? And, I must say I did not find any option to turn looping off in Spriter itself too.

@lucid OK thanks, nice new wrappers. I updated my fork https://github.com/Breush/SpriterPlusPlus with the PugiXml loaders. You should check example/override/pugixml* and the pugixml at the root directory. Works all right for me.

So, here's a quick sum-up from my experience. Cool: It works great! And that's a good point. It fixes problems I had using scml-pp concerning negative scaling. It's easy to interface with user's pre-existant factories. Question: I see the functions to override for debugging, but I didn't find any option to activate it. (Excepted it to be in global/global.h). Not so cool: Triggers (sounds at least) do not work properly. Either I get infinite of them or none. I spent way too much time writing a XML loader. The basic functions and types that are specific to the XML library need to be factored out from the document structure. That way one would just need to write the content of predefined basic functions (getAttribute, getFirstChild, etc.). Every time I see a "new ..." in the code I just wonder who should delete it... For instance "new SfmlSoundObjectInfoReference" in example/sfmlsoundfile.cpp Something to do: Functions in global/global.h are "static" but should be "inline" instead. I think this is due to a misundertanding of what "static" means outside a class definition. So, I'm very happy with it! But right now my biggest issue concern sounds, I hope to understand the problem soon enough. And by the way, "To provide feedback, report errors, or give suggestions, please use the relevant Spriter forum thread", this is the one, right?

@lucid @darkgod As my pull request got merged, the compile-time errors should be fixed. I work with C++11 and the STL, so I'm OK with the current implementation but others might be concerned these requirements, notably on small systems like smartphones. By the way, I had to make a loader using pugixml, I can share it with you guys later, once I sure that the problems I'm experiencing are not linked to that change.

Well, that's awesome! I'll try integrating it to my SFML-based project right now. Thanks to the example, I guess it won'tbe so hard

Any idea of a date for that public testing?

Nice to hear, thanks a lot :) Spriter is a very intuitive and complete software, the only important thing it's missing is this reference implementation. Thank you again for your great work.

Quick question here: Will this implementation be compatible with the mesh deformations (skin feature)?