Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Breush

  1. @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.

  2. 29 minutes ago, lucid said:

    @Breush Thanks!  I added the pugixml loader.  

    As far as the getFile error, if you don't mind, please email me the Spriter project you're using, and I'll see if I can find out what's going on. 

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

  3. @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).

  4. 57 minutes ago, BrashAdmin said:

    To set looping off for an animation once its in the game, just click the looping icon at the right side of the time-line palette in Spriter. (the button will go dark to represent "off", the button is orange when "on" by default)
    Playback in Spriter is always looping if you left click the play button. BUT, if you right-click the play button the animation will play just once and stop.

    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.

  5. So, here's a quick sum-up from my experience.


    • 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?

  6. @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.

  7. The current mesh deformation is just a proof of concept. This implementation will form the framework for future Spriter versions, and includes a lot of groundwork that will be used for the full mesh deformation feature. Because of this, it will be trivial to update the reference implementation and and all ports with mesh deformation once it's complete in Spriter.

    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.

  • Create New...