lucid

UE4Spriter
UE4Spriter is a plugin for Unreal Engine 4, that allows importing and rendering of Spriter animations in Unreal Engine games (Windows only as of now).
Spriter project files and sprite images can be imported quickly. A Spriter component is responsible for rendering the animation. I tried to make the process of setting up a scene as hassle-free as possible.
The whole project is open source (MIT license) and free to use. It can be downloaded from Github.
Download
Video
Currently the plugin supports animations only. If there is enough interest I might add more features in the future.
Recent changes
Update README.md                                                         Disabled crash reporter and 'anonymous' statistics.                      Added Blueprint function to query triggers.                              Add reimport asset action for Spriter Project.                           Added Blueprint function to blend animation.                             Added Blueprint functions for stopping and starting animations.          Added Blueprint functions for character maps.                            Added Spriter placeholder image.                                         

hi @monge93 I'm not sure how the file got corrupted, but my guess is it has something to do with eventlines, and possibly deleting an object after creating an eventline.  I will look into this more.  In the meantime, though, I was able to fix the file: https://dl.dropboxusercontent.com/u/257875422/SpriterForums/v4_character_000.scml

I apologize for the inconvenience.

Hello everyone,
We're happy to announce the release of a new Spriter update build.
This new build involved making the switch to the latest version of the application framework (Qt).
Community and internal testing shows improved performance and compatibility overall, but this is a big change from previous builds, so please back up your Spriter projects before using this new build and please let us know if any new issues occur.
Beyond the improved performance and compatibility, this build offers several new features and improvements. Here's a brief overview: (full change-log at the end of this post)
 
This build seems to resolve the major visual issues for users with retina displays. Mac users report a substantial improvement in performance (FPS), and there seems to no longer be a need to disable OpenGL, however, some Mac users will get better performance with it disabled so you should try both ways and see what works best for your system. There's a new character map related color palette change feature for use with indexed color images (This new feature will be used heavily with our soon to be released RPG Animated art Pack and a SHMUP pack which will be released some time later.) You can now move animations from one entity to another. You can now specify custom trimming rectangles for export per animation. These settings are saved into your project. You can now save and load character map stacks and palette swapping information separate from your project. (ideal for complex Spriter projects where characters can be created by activating many character maps at once.)  
Stay tuned for new quick-tip videos and documentation showcasing and detailing the usage of these new features in the coming days.
 
We look forward to your feedback and hope you enjoy these new features and improvements.
 
Cheers!
 
Spriter Release 5
Released 12/11/2015
Additions and Enhancements (Manual entries and tutorial videos explaining new features coming soon)
Upgrade application framework (Qt), which will enhance performance and improve compatibility Added ability to reorder character maps Added the ability to move animations from one entity to another Added the ability to swap palettes for indexes color images Added the ability to save and load scms (Spriter Character Map Stack) files which save the current character map stack and all currently applied palette swaps Added the ability to set custom trimming rectangle settings for exporting per animation that get saved into the project Bug Fixes
Fixed memory leak when creating new character maps Fixed bug where the right mouse button image strip to choose images for sprites wouldn't show up for images in subfolders more than 2 levels deep

I think this is a good idea @lucid - I will give it a try as I think it will be cleaner code and may also make certain features easier should I decide to try to implement them, such as integrating the Cocos2d Physics system.

My SpriterPlusPlusQt is now in a working state. You should now be able to build and run it.
Using it from QML is very easy.
I created an example that's more or less the same as the SFML one (creating 100 random entities). Each frame is 10ms, so performance is good.
Now I need to add more features (sound, ...) and optimize a bit.
Still a question, are there some dimensions on the animation as a whole I could use? A bounding box.

Wow! The performance in Mac (I have a Mac-Mini) is really really better, now I can actually work with it,  (I used to work in a PC/Win when using Spriter). Really happy now, congrats! 

Yes. Thanks for all the tips. AMD drivers is the problem.
I should look for that.
(Mine is Notebook Radeon HD 8600)
 

I just tested it out on windows and seems to work great. The current mesh deformation feature never worked on my laptop before, but it does now!

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

Cool! Really good job.
I will now be able to update it to the Clickteam Fusion 2.5 tool. For what I have seen so far it should be straightforward from my existing implementation.

Hi everyone,
We're pleased to announce that at long last the wait for a fully featured and officially supported reference implementation for Spriter is at and end.
The first two languages to receive officially supported, feature complete implementations are C# and C++.
The C++ implementation is being created by myself, and should be ready for public testing in the very near future.
For the C# implementation, we'd like to give a huge thanks to community member Loodakrawa for having created it, and for working with us to make it totally feature complete, officially supported C# reference implementation.  Loodakrawa was also nice enough to agree (and take the necessary steps) to change it's license to the zlib license, which is among the most permissive licenses available. This is the license all officially supported Spriter implementations will be released under. We encourage anyone who wants to port either implementation (or future released implementations) under the same license.
In summary:

It should be very easy to port to any language of your choice with a simple copy/paste, and edit.  Also, these will be easy to adapt to any game engine or authoring tool (There is an example in the C# implementation working in Monogame).
Shortly after the release of the C++ implementation, we'll be working to port one of the two implementation to JavaScript.
We're also pleased to announce we'll be working with the folks at ClickTeam to make sure Spriter is fully supported in their latest authoring system - Fusion 3 (not yet released).
Similarly, we'll be working with Enterbrain, the creators of RPG Maker, to add Spriter support to their upcoming RPG Maker MV, which is already available for pre-order.
Once these initial reference implementations are fully tested we'll also be contacting and working with the developers of as many popular authoring systems as possible to get full Spriter support ported to their respective packages as soon as possible, so please dive in and give these implementations a test spin. Please report any bugs with the C# version to Loodakrawa's thread. The sooner we make sure they're rock solid, the sooner full Spriter support becomes commonplace for all game developers. This is currently our top priority.
In addition to this, we will be starting a thread in the near future of all ports, either complete or in the works. We will of course post any that we are directly involved with, but we encourage you to post in that thread to let us know if you're creating a port, or if it's already complete.
While the community is helping us to test and perfect these current reference implementations, we'll be working on a Spriter update build, which will hopefully increase compatibility (most notably we'll be attempting to resolved issues with Retina Displays and Wacom input devices) as well as resolve some known bugs.
As always, we greatly appreciate and are humbled by your patience and support during the long delay in meeting this critical milestone. Once this testing is complete, getting full Spriter support for any particular language or authoring system should be much easier and faster, even trivial.
In the mean time, we definitely owe you an explanation for why the full implementation took so long:
Our initial intent was to not only create a reference implementation which would support all of Spriter's current features, but which would also have the flexibility to support the substantial amount of future features we already have planned. Of course, the attempt to meet these goals necessitated fleshing out the requirements and nuances of the planned features, and taking time to make sure the structure of the reference implementation would leave the room and flexibility to easily incorporate them when the time came.
This lead to a sort of tug of war, between the potential power and flexibility of the new features, the development time to finish the first release of the reference implementation, and the limits imposed by what the current Spriter data structure could accommodate.
While grueling and time consuming, there was steady progress in many aspects of feature design, data handling routines, etc. The concepts and possibilities we discovered during this process were encouraging enough to postpone our eventual realization that unless we tweaked our approach and our actual goal, we'd be making too great a compromise, both imposing too long a wait on our users for support of the current features, and too great a compromise on the future flexibility of Spriter - with truncated versions of our new and powerful concepts shoehorned into compatibility with the current data structure.
We realized the only reasonable thing to do was to break this initial goal into three separate goals, so that milestones useful to Spriter users could be reached much more quickly:
Get support for all current Spriter features publicly released and available for all Spriter users ASAP. While this support is getting ported to as many languages and authoring systems as quickly as possible, work on an update build of Spriter, increasing compatibility and resolving as many known issues as possible. We'll also take this opportunity to add a couple of simple features specifically geared to improving work-flow. Once the update build(s) improve the current iteration of Spriter, we'll shift our focus back towards continuing where development of the future proof, uncompromising Spriter engine and data format left off. We've already made significant progress on this new core. It's a completely new design, and will be the foundation upon which we will build a new and improved Spriter, with a much more powerful and flexible feature-set. And with that, we'd like to announce our plans to develop Spriter 2. We can't disclose too much information about it or it's new features yet, but we can tell you that Spriter 2 Pro will be a free upgrade to all current Spriter Pro users. We will reveal more as things develop. Cheers!

I've added a pull request for a gcc change and a fix for header files not found.
I could build the engine now with:
cd spriterengine LANG=C g++ -std=c++14 -shared -fPIC -I. */*.cpp -o spriterengine.so (LANG=C only because I like the terminal output in English)

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

Please post bugs with Spriter R4 here.

Hi everyone,
We're pleased to announce that at long last the wait for a fully featured and officially supported reference implementation for Spriter is at and end.
The first two languages to receive officially supported, feature complete implementations are C# and C++.
The C++ implementation is being created by myself, and should be ready for public testing in the very near future.
For the C# implementation, we'd like to give a huge thanks to community member Loodakrawa for having created it, and for working with us to make it totally feature complete, officially supported C# reference implementation.  Loodakrawa was also nice enough to agree (and take the necessary steps) to change it's license to the zlib license, which is among the most permissive licenses available. This is the license all officially supported Spriter implementations will be released under. We encourage anyone who wants to port either implementation (or future released implementations) under the same license.
In summary:

It should be very easy to port to any language of your choice with a simple copy/paste, and edit.  Also, these will be easy to adapt to any game engine or authoring tool (There is an example in the C# implementation working in Monogame).
Shortly after the release of the C++ implementation, we'll be working to port one of the two implementation to JavaScript.
We're also pleased to announce we'll be working with the folks at ClickTeam to make sure Spriter is fully supported in their latest authoring system - Fusion 3 (not yet released).
Similarly, we'll be working with Enterbrain, the creators of RPG Maker, to add Spriter support to their upcoming RPG Maker MV, which is already available for pre-order.
Once these initial reference implementations are fully tested we'll also be contacting and working with the developers of as many popular authoring systems as possible to get full Spriter support ported to their respective packages as soon as possible, so please dive in and give these implementations a test spin. Please report any bugs with the C# version to Loodakrawa's thread. The sooner we make sure they're rock solid, the sooner full Spriter support becomes commonplace for all game developers. This is currently our top priority.
In addition to this, we will be starting a thread in the near future of all ports, either complete or in the works. We will of course post any that we are directly involved with, but we encourage you to post in that thread to let us know if you're creating a port, or if it's already complete.
While the community is helping us to test and perfect these current reference implementations, we'll be working on a Spriter update build, which will hopefully increase compatibility (most notably we'll be attempting to resolved issues with Retina Displays and Wacom input devices) as well as resolve some known bugs.
As always, we greatly appreciate and are humbled by your patience and support during the long delay in meeting this critical milestone. Once this testing is complete, getting full Spriter support for any particular language or authoring system should be much easier and faster, even trivial.
In the mean time, we definitely owe you an explanation for why the full implementation took so long:
Our initial intent was to not only create a reference implementation which would support all of Spriter's current features, but which would also have the flexibility to support the substantial amount of future features we already have planned. Of course, the attempt to meet these goals necessitated fleshing out the requirements and nuances of the planned features, and taking time to make sure the structure of the reference implementation would leave the room and flexibility to easily incorporate them when the time came.
This lead to a sort of tug of war, between the potential power and flexibility of the new features, the development time to finish the first release of the reference implementation, and the limits imposed by what the current Spriter data structure could accommodate.
While grueling and time consuming, there was steady progress in many aspects of feature design, data handling routines, etc. The concepts and possibilities we discovered during this process were encouraging enough to postpone our eventual realization that unless we tweaked our approach and our actual goal, we'd be making too great a compromise, both imposing too long a wait on our users for support of the current features, and too great a compromise on the future flexibility of Spriter - with truncated versions of our new and powerful concepts shoehorned into compatibility with the current data structure.
We realized the only reasonable thing to do was to break this initial goal into three separate goals, so that milestones useful to Spriter users could be reached much more quickly:
Get support for all current Spriter features publicly released and available for all Spriter users ASAP. While this support is getting ported to as many languages and authoring systems as quickly as possible, work on an update build of Spriter, increasing compatibility and resolving as many known issues as possible. We'll also take this opportunity to add a couple of simple features specifically geared to improving work-flow. Once the update build(s) improve the current iteration of Spriter, we'll shift our focus back towards continuing where development of the future proof, uncompromising Spriter engine and data format left off. We've already made significant progress on this new core. It's a completely new design, and will be the foundation upon which we will build a new and improved Spriter, with a much more powerful and flexible feature-set. And with that, we'd like to announce our plans to develop Spriter 2. We can't disclose too much information about it or it's new features yet, but we can tell you that Spriter 2 Pro will be a free upgrade to all current Spriter Pro users. We will reveal more as things develop. Cheers!

Hi loodakrawa,
See if this helps:
// before adding the parent.angle to child.angleif(parentInfo.scaleX*parentInfo.scaleY<0) // if one, but not both are negative{ child.angle*=-1; // or child.angle=360-child.angle // (if you want to keep it within the 0 - 360 range)}

Hi everyone,
We're pleased to announce that at long last the wait for a fully featured and officially supported reference implementation for Spriter is at and end.
The first two languages to receive officially supported, feature complete implementations are C# and C++.
The C++ implementation is being created by myself, and should be ready for public testing in the very near future.
For the C# implementation, we'd like to give a huge thanks to community member Loodakrawa for having created it, and for working with us to make it totally feature complete, officially supported C# reference implementation.  Loodakrawa was also nice enough to agree (and take the necessary steps) to change it's license to the zlib license, which is among the most permissive licenses available. This is the license all officially supported Spriter implementations will be released under. We encourage anyone who wants to port either implementation (or future released implementations) under the same license.
In summary:

It should be very easy to port to any language of your choice with a simple copy/paste, and edit.  Also, these will be easy to adapt to any game engine or authoring tool (There is an example in the C# implementation working in Monogame).
Shortly after the release of the C++ implementation, we'll be working to port one of the two implementation to JavaScript.
We're also pleased to announce we'll be working with the folks at ClickTeam to make sure Spriter is fully supported in their latest authoring system - Fusion 3 (not yet released).
Similarly, we'll be working with Enterbrain, the creators of RPG Maker, to add Spriter support to their upcoming RPG Maker MV, which is already available for pre-order.
Once these initial reference implementations are fully tested we'll also be contacting and working with the developers of as many popular authoring systems as possible to get full Spriter support ported to their respective packages as soon as possible, so please dive in and give these implementations a test spin. Please report any bugs with the C# version to Loodakrawa's thread. The sooner we make sure they're rock solid, the sooner full Spriter support becomes commonplace for all game developers. This is currently our top priority.
In addition to this, we will be starting a thread in the near future of all ports, either complete or in the works. We will of course post any that we are directly involved with, but we encourage you to post in that thread to let us know if you're creating a port, or if it's already complete.
While the community is helping us to test and perfect these current reference implementations, we'll be working on a Spriter update build, which will hopefully increase compatibility (most notably we'll be attempting to resolved issues with Retina Displays and Wacom input devices) as well as resolve some known bugs.
As always, we greatly appreciate and are humbled by your patience and support during the long delay in meeting this critical milestone. Once this testing is complete, getting full Spriter support for any particular language or authoring system should be much easier and faster, even trivial.
In the mean time, we definitely owe you an explanation for why the full implementation took so long:
Our initial intent was to not only create a reference implementation which would support all of Spriter's current features, but which would also have the flexibility to support the substantial amount of future features we already have planned. Of course, the attempt to meet these goals necessitated fleshing out the requirements and nuances of the planned features, and taking time to make sure the structure of the reference implementation would leave the room and flexibility to easily incorporate them when the time came.
This lead to a sort of tug of war, between the potential power and flexibility of the new features, the development time to finish the first release of the reference implementation, and the limits imposed by what the current Spriter data structure could accommodate.
While grueling and time consuming, there was steady progress in many aspects of feature design, data handling routines, etc. The concepts and possibilities we discovered during this process were encouraging enough to postpone our eventual realization that unless we tweaked our approach and our actual goal, we'd be making too great a compromise, both imposing too long a wait on our users for support of the current features, and too great a compromise on the future flexibility of Spriter - with truncated versions of our new and powerful concepts shoehorned into compatibility with the current data structure.
We realized the only reasonable thing to do was to break this initial goal into three separate goals, so that milestones useful to Spriter users could be reached much more quickly:
Get support for all current Spriter features publicly released and available for all Spriter users ASAP. While this support is getting ported to as many languages and authoring systems as quickly as possible, work on an update build of Spriter, increasing compatibility and resolving as many known issues as possible. We'll also take this opportunity to add a couple of simple features specifically geared to improving work-flow. Once the update build(s) improve the current iteration of Spriter, we'll shift our focus back towards continuing where development of the future proof, uncompromising Spriter engine and data format left off. We've already made significant progress on this new core. It's a completely new design, and will be the foundation upon which we will build a new and improved Spriter, with a much more powerful and flexible feature-set. And with that, we'd like to announce our plans to develop Spriter 2. We can't disclose too much information about it or it's new features yet, but we can tell you that Spriter 2 Pro will be a free upgrade to all current Spriter Pro users. We will reveal more as things develop. Cheers!

Hi everyone,
We're pleased to announce that at long last the wait for a fully featured and officially supported reference implementation for Spriter is at and end.
The first two languages to receive officially supported, feature complete implementations are C# and C++.
The C++ implementation is being created by myself, and should be ready for public testing in the very near future.
For the C# implementation, we'd like to give a huge thanks to community member Loodakrawa for having created it, and for working with us to make it totally feature complete, officially supported C# reference implementation.  Loodakrawa was also nice enough to agree (and take the necessary steps) to change it's license to the zlib license, which is among the most permissive licenses available. This is the license all officially supported Spriter implementations will be released under. We encourage anyone who wants to port either implementation (or future released implementations) under the same license.
In summary:

It should be very easy to port to any language of your choice with a simple copy/paste, and edit.  Also, these will be easy to adapt to any game engine or authoring tool (There is an example in the C# implementation working in Monogame).
Shortly after the release of the C++ implementation, we'll be working to port one of the two implementation to JavaScript.
We're also pleased to announce we'll be working with the folks at ClickTeam to make sure Spriter is fully supported in their latest authoring system - Fusion 3 (not yet released).
Similarly, we'll be working with Enterbrain, the creators of RPG Maker, to add Spriter support to their upcoming RPG Maker MV, which is already available for pre-order.
Once these initial reference implementations are fully tested we'll also be contacting and working with the developers of as many popular authoring systems as possible to get full Spriter support ported to their respective packages as soon as possible, so please dive in and give these implementations a test spin. Please report any bugs with the C# version to Loodakrawa's thread. The sooner we make sure they're rock solid, the sooner full Spriter support becomes commonplace for all game developers. This is currently our top priority.
In addition to this, we will be starting a thread in the near future of all ports, either complete or in the works. We will of course post any that we are directly involved with, but we encourage you to post in that thread to let us know if you're creating a port, or if it's already complete.
While the community is helping us to test and perfect these current reference implementations, we'll be working on a Spriter update build, which will hopefully increase compatibility (most notably we'll be attempting to resolved issues with Retina Displays and Wacom input devices) as well as resolve some known bugs.
As always, we greatly appreciate and are humbled by your patience and support during the long delay in meeting this critical milestone. Once this testing is complete, getting full Spriter support for any particular language or authoring system should be much easier and faster, even trivial.
In the mean time, we definitely owe you an explanation for why the full implementation took so long:
Our initial intent was to not only create a reference implementation which would support all of Spriter's current features, but which would also have the flexibility to support the substantial amount of future features we already have planned. Of course, the attempt to meet these goals necessitated fleshing out the requirements and nuances of the planned features, and taking time to make sure the structure of the reference implementation would leave the room and flexibility to easily incorporate them when the time came.
This lead to a sort of tug of war, between the potential power and flexibility of the new features, the development time to finish the first release of the reference implementation, and the limits imposed by what the current Spriter data structure could accommodate.
While grueling and time consuming, there was steady progress in many aspects of feature design, data handling routines, etc. The concepts and possibilities we discovered during this process were encouraging enough to postpone our eventual realization that unless we tweaked our approach and our actual goal, we'd be making too great a compromise, both imposing too long a wait on our users for support of the current features, and too great a compromise on the future flexibility of Spriter - with truncated versions of our new and powerful concepts shoehorned into compatibility with the current data structure.
We realized the only reasonable thing to do was to break this initial goal into three separate goals, so that milestones useful to Spriter users could be reached much more quickly:
Get support for all current Spriter features publicly released and available for all Spriter users ASAP. While this support is getting ported to as many languages and authoring systems as quickly as possible, work on an update build of Spriter, increasing compatibility and resolving as many known issues as possible. We'll also take this opportunity to add a couple of simple features specifically geared to improving work-flow. Once the update build(s) improve the current iteration of Spriter, we'll shift our focus back towards continuing where development of the future proof, uncompromising Spriter engine and data format left off. We've already made significant progress on this new core. It's a completely new design, and will be the foundation upon which we will build a new and improved Spriter, with a much more powerful and flexible feature-set. And with that, we'd like to announce our plans to develop Spriter 2. We can't disclose too much information about it or it's new features yet, but we can tell you that Spriter 2 Pro will be a free upgrade to all current Spriter Pro users. We will reveal more as things develop. Cheers!

Hi everyone,
We're pleased to announce that at long last the wait for a fully featured and officially supported reference implementation for Spriter is at and end.
The first two languages to receive officially supported, feature complete implementations are C# and C++.
The C++ implementation is being created by myself, and should be ready for public testing in the very near future.
For the C# implementation, we'd like to give a huge thanks to community member Loodakrawa for having created it, and for working with us to make it totally feature complete, officially supported C# reference implementation.  Loodakrawa was also nice enough to agree (and take the necessary steps) to change it's license to the zlib license, which is among the most permissive licenses available. This is the license all officially supported Spriter implementations will be released under. We encourage anyone who wants to port either implementation (or future released implementations) under the same license.
In summary:

It should be very easy to port to any language of your choice with a simple copy/paste, and edit.  Also, these will be easy to adapt to any game engine or authoring tool (There is an example in the C# implementation working in Monogame).
Shortly after the release of the C++ implementation, we'll be working to port one of the two implementation to JavaScript.
We're also pleased to announce we'll be working with the folks at ClickTeam to make sure Spriter is fully supported in their latest authoring system - Fusion 3 (not yet released).
Similarly, we'll be working with Enterbrain, the creators of RPG Maker, to add Spriter support to their upcoming RPG Maker MV, which is already available for pre-order.
Once these initial reference implementations are fully tested we'll also be contacting and working with the developers of as many popular authoring systems as possible to get full Spriter support ported to their respective packages as soon as possible, so please dive in and give these implementations a test spin. Please report any bugs with the C# version to Loodakrawa's thread. The sooner we make sure they're rock solid, the sooner full Spriter support becomes commonplace for all game developers. This is currently our top priority.
In addition to this, we will be starting a thread in the near future of all ports, either complete or in the works. We will of course post any that we are directly involved with, but we encourage you to post in that thread to let us know if you're creating a port, or if it's already complete.
While the community is helping us to test and perfect these current reference implementations, we'll be working on a Spriter update build, which will hopefully increase compatibility (most notably we'll be attempting to resolved issues with Retina Displays and Wacom input devices) as well as resolve some known bugs.
As always, we greatly appreciate and are humbled by your patience and support during the long delay in meeting this critical milestone. Once this testing is complete, getting full Spriter support for any particular language or authoring system should be much easier and faster, even trivial.
In the mean time, we definitely owe you an explanation for why the full implementation took so long:
Our initial intent was to not only create a reference implementation which would support all of Spriter's current features, but which would also have the flexibility to support the substantial amount of future features we already have planned. Of course, the attempt to meet these goals necessitated fleshing out the requirements and nuances of the planned features, and taking time to make sure the structure of the reference implementation would leave the room and flexibility to easily incorporate them when the time came.
This lead to a sort of tug of war, between the potential power and flexibility of the new features, the development time to finish the first release of the reference implementation, and the limits imposed by what the current Spriter data structure could accommodate.
While grueling and time consuming, there was steady progress in many aspects of feature design, data handling routines, etc. The concepts and possibilities we discovered during this process were encouraging enough to postpone our eventual realization that unless we tweaked our approach and our actual goal, we'd be making too great a compromise, both imposing too long a wait on our users for support of the current features, and too great a compromise on the future flexibility of Spriter - with truncated versions of our new and powerful concepts shoehorned into compatibility with the current data structure.
We realized the only reasonable thing to do was to break this initial goal into three separate goals, so that milestones useful to Spriter users could be reached much more quickly:
Get support for all current Spriter features publicly released and available for all Spriter users ASAP. While this support is getting ported to as many languages and authoring systems as quickly as possible, work on an update build of Spriter, increasing compatibility and resolving as many known issues as possible. We'll also take this opportunity to add a couple of simple features specifically geared to improving work-flow. Once the update build(s) improve the current iteration of Spriter, we'll shift our focus back towards continuing where development of the future proof, uncompromising Spriter engine and data format left off. We've already made significant progress on this new core. It's a completely new design, and will be the foundation upon which we will build a new and improved Spriter, with a much more powerful and flexible feature-set. And with that, we'd like to announce our plans to develop Spriter 2. We can't disclose too much information about it or it's new features yet, but we can tell you that Spriter 2 Pro will be a free upgrade to all current Spriter Pro users. We will reveal more as things develop. Cheers!

Hi everyone,
We're pleased to announce that at long last the wait for a fully featured and officially supported reference implementation for Spriter is at and end.
The first two languages to receive officially supported, feature complete implementations are C# and C++.
The C++ implementation is being created by myself, and should be ready for public testing in the very near future.
For the C# implementation, we'd like to give a huge thanks to community member Loodakrawa for having created it, and for working with us to make it totally feature complete, officially supported C# reference implementation.  Loodakrawa was also nice enough to agree (and take the necessary steps) to change it's license to the zlib license, which is among the most permissive licenses available. This is the license all officially supported Spriter implementations will be released under. We encourage anyone who wants to port either implementation (or future released implementations) under the same license.
In summary:

It should be very easy to port to any language of your choice with a simple copy/paste, and edit.  Also, these will be easy to adapt to any game engine or authoring tool (There is an example in the C# implementation working in Monogame).
Shortly after the release of the C++ implementation, we'll be working to port one of the two implementation to JavaScript.
We're also pleased to announce we'll be working with the folks at ClickTeam to make sure Spriter is fully supported in their latest authoring system - Fusion 3 (not yet released).
Similarly, we'll be working with Enterbrain, the creators of RPG Maker, to add Spriter support to their upcoming RPG Maker MV, which is already available for pre-order.
Once these initial reference implementations are fully tested we'll also be contacting and working with the developers of as many popular authoring systems as possible to get full Spriter support ported to their respective packages as soon as possible, so please dive in and give these implementations a test spin. Please report any bugs with the C# version to Loodakrawa's thread. The sooner we make sure they're rock solid, the sooner full Spriter support becomes commonplace for all game developers. This is currently our top priority.
In addition to this, we will be starting a thread in the near future of all ports, either complete or in the works. We will of course post any that we are directly involved with, but we encourage you to post in that thread to let us know if you're creating a port, or if it's already complete.
While the community is helping us to test and perfect these current reference implementations, we'll be working on a Spriter update build, which will hopefully increase compatibility (most notably we'll be attempting to resolved issues with Retina Displays and Wacom input devices) as well as resolve some known bugs.
As always, we greatly appreciate and are humbled by your patience and support during the long delay in meeting this critical milestone. Once this testing is complete, getting full Spriter support for any particular language or authoring system should be much easier and faster, even trivial.
In the mean time, we definitely owe you an explanation for why the full implementation took so long:
Our initial intent was to not only create a reference implementation which would support all of Spriter's current features, but which would also have the flexibility to support the substantial amount of future features we already have planned. Of course, the attempt to meet these goals necessitated fleshing out the requirements and nuances of the planned features, and taking time to make sure the structure of the reference implementation would leave the room and flexibility to easily incorporate them when the time came.
This lead to a sort of tug of war, between the potential power and flexibility of the new features, the development time to finish the first release of the reference implementation, and the limits imposed by what the current Spriter data structure could accommodate.
While grueling and time consuming, there was steady progress in many aspects of feature design, data handling routines, etc. The concepts and possibilities we discovered during this process were encouraging enough to postpone our eventual realization that unless we tweaked our approach and our actual goal, we'd be making too great a compromise, both imposing too long a wait on our users for support of the current features, and too great a compromise on the future flexibility of Spriter - with truncated versions of our new and powerful concepts shoehorned into compatibility with the current data structure.
We realized the only reasonable thing to do was to break this initial goal into three separate goals, so that milestones useful to Spriter users could be reached much more quickly:
Get support for all current Spriter features publicly released and available for all Spriter users ASAP. While this support is getting ported to as many languages and authoring systems as quickly as possible, work on an update build of Spriter, increasing compatibility and resolving as many known issues as possible. We'll also take this opportunity to add a couple of simple features specifically geared to improving work-flow. Once the update build(s) improve the current iteration of Spriter, we'll shift our focus back towards continuing where development of the future proof, uncompromising Spriter engine and data format left off. We've already made significant progress on this new core. It's a completely new design, and will be the foundation upon which we will build a new and improved Spriter, with a much more powerful and flexible feature-set. And with that, we'd like to announce our plans to develop Spriter 2. We can't disclose too much information about it or it's new features yet, but we can tell you that Spriter 2 Pro will be a free upgrade to all current Spriter Pro users. We will reveal more as things develop. Cheers!

Progress is indeed going smoothly. Still on target for October 18th. original post updated to reflect we're still on track for the ETA

really looking forward to this update, hope progress is going smoothly :D

Hello everyone!
    Welcome to the first post 1.0 release of Spriter.  Aside from a couple of bug fixes, this release includes a new video help option that lets you watch our YouTube tutorials in a floating window (with links to open the playlists in your default browser).  Video Help will show up immediately upon startup to give guidance for beginners, and the window has an option to disable this behavior.  Spriter will now warn you if you try to save outside the project directory that it won't be able to find it's images, and will also provide an explanation and the expected file structure when you load a file with missing images.
An important note for Mac users.  There is an optimization in this version that may correct the performance issues some users have been experiencing on the Mac.  Please let me know if this fixes the issue for you, as it seemed to make a significant difference on our machines.
We will continue to fix bugs and provide minor feature updates, but my primary focus at the moment is completing the developer documentation.
Lastly, if you're reading this and you don't already own Spriter Pro, or you have a friend who doesn't, Steam is having their Autumn Sale now, and Spriter is 50% off until December 2nd.  Spread the word!
Thanks everyone, and enjoy the new build!

download Spriter r2 here
Change-Log 11/28/2014Additions and Enhancements
Performance optimizations - possible fix for Mac slowdown issues Added Video Help on startup (with the option to never show again), and in the Help menu Added a link the Grey Guy example file in the Help menu Added a warning when attempting to save outside of the project directory(with the option to never show again) Added a warning/explanation that pops up when a project has missing images, and displays the expected file tree(with the option to never show again) Added a Help menu option to reset all 'show this message again' checkboxes Saving a resized project no longer allows you to save to your current project folder or any of it's subfolders to avoid confusion and overwriting or mixing up both projects' images Saving a resized project now confirms individual image overwrites as it creates resized copies of images Original image size data is now preserved in Missing Image placeholders Original image size data is now preserved when saving a project with missing images Bug Fixes
Fixed a crash that could occur with certain projects with missing folders and images Fixed a bug that would give autosaves the *.scon extension when working on a project last saved as *.scon, even though all autosave data is saved as scml Fixed a bug that would cause child bones created on very wide parent bones to have 0 width

Hi Everyone,
We're pleased to announce that our 4 fully animated Art Packs for use with Spriter are now available on Steam as of 4 pm today. June 4th EST.
In conjunction with their Steam release we're also introducing a new, lower price point for them and all future art packs, not just on Steam, but on our own Web Store and on affiliate stores as well.
Here are previews of all of the currently available art packs, along with their new prices:
Game Effects Pack $12.99 Basic Platformer Pack $24.99 Adventure Platformer Pack $24.99 Run N' Gun Platformer Pack $24.99 In addition to this substantial price reduction, in celebration of their introduction, all art packs are currently on sale on Steam for 50 percent off, making this an excellent opportunity to snatch up these royalty free Spriter animations Packs for your current and future game projects at an unprecedented low price. For those who have already purchased one or more of our full Art Packs from our web store or any of our affiliates (Not Steam) BEFORE they became available on Steam, please keep an eye out in your in-box for an update email (for the Art Packs you purchased) automatically upgrading it to drastically increase your content. Here's what to expect:
If you already purchased the Effects Pack, then you'll receive the Basic Platformer Pack for free.
If you already purchased any one of the Platformer Packs you'll receive all other Platformer Packs for free.
If you already purchased any of the bundles of 2 Art Packs then you'll receive all the other remaining Art Packs and the next Art Pack we release as well for free.
If you purchased the all Art Packs bundle you'll receive all current and all future art packs we release for free. If you purchased more than one art pack, but one at a time you should qualify for numbers 3 or 4 above, then please email support@brashmonkey.com with the details of each purchase and make the subject title of the email “Art Pack bundle equivalent upgrade” (without quotes) And we'll upgrade your product description in our system and send you the additional art packs. If four days from now you still haven't received your automatic upgrade email, please contact support@brashmonkey.com with your original purchase information for your art packs or bundles and make the subject title of the email “Did not receive art packs upgrade” (without quotes) 
In related news, we're currently working on 2 new Animated Art Packs which we plan to reveal more about within roughly a month.
Cheers!

Spriter R4.1 Critical Bug Fix:
There was a critical bug in yesterday's build of Spriter that made it so you couldn't edit default pivot points.  I apologize for any inconvenience this may have caused, and here is a new version that fixes the issue.  If you use the Steam version of Spriter, it should automatically update the next time you log in.
This version also contains a fix that may help some Steam users that were experiencing library issues on Linux.  
 
 
Original R4 Update:
Hi everyone,
 
We're pleased to announce the release of Spriter build R4 available for download at www.brashmonkey.com and also as an automatic update on Steam.
 
R4 is the first build to feature the newly updated manual which now covers all core features. R4 also features the long awaited hot-key list, which you can access by pressing Shift+Escape (or through the Help menu).
 
One great new feature introduced in this new build is the ability to copy a specific individual attribute of an object (such as it's x scale, y scale, position, angle, or opacity) and automatically paste to all of its other key frames.
 
This build should also fix a library issue with the 64 bit Linux version. Internal testing shows the Steam version of Spriter Pro now loads properly from Steam with Ubuntu 11.04, but so far we can only get it to run on Ubuntu 14 by launching it directly from it's Steam folder location.  It will not launch directly from Steam itself.  We will continue to look into this and thank you for your patience.
 
Here is the full changelog for Spriter R4:
 
Spriter Release 4
Released 4/22/2015
 
Additions and Enhancements
Updated manual now includes all core features Added Shortcut Key Popup (available in the Help menu, and through keyboard shortcut Shift-Esc) Added the right-click menu option on the canvas to copy a single object attribute (x,y,angle,etc) to every frame (when one object is selected) Export To PNG/Gif window now remembers 'Keyframes Only' setting   
Changes
Minor cosmetic changes Changed Export to PNG Sequence naming convention to use one underscore (myImage_000.png) instead of two (myImage__000.png), as the double underscore was causing issues on certain OS's and API's Bug Fixes
Fixed a bug that made the right click image list for sprites not show up under certain circumstances Removed the 'Program Update' settings from the Steam version, as Steam handles updates and these settings had no effect. We'd also like to take this opportunity to mention some great new Spriter implementations in the works for several popular authoring systems. Here are links so you can get the specific details for each of them. (If we missed any new Spriter implementations, please let us know and we'll mention it in our next update.)
 
Atomic Game Engine (Video) 
 
Overlap 2d
 
Clickteam Fusion  (Video) 
 
We should also mention Spriter2Unity has also been updated to work with Unity 5.
 
 
Speaking of runtimes, we'd like to humbly thank everyone again for your patience as we continue to work on the Spriter Pro reference implementation. As most of you may know, the goal is to provide a fully featured and easy to follow/port Spriter implementation, and the delay is in general because we are making sure the implementation is as flexible as possible, includes several up-coming features and improvements, and makes room for the easy addition of several planned features which will be a big part of Spriter's future. As this full and future-proof implementation develops we're very excited with what it will offer Spriter users, but it's also becoming obvious that there's a conflict between the need to make sure its done carefully and the desire to get it done quickly.
 
For this reason we've decided its best for me to switch gears and make a much simpler reference implementation which perfectly supports all current features (but not the future features) so that people who need to port or finish a Spriter implementation sooner rather than later will have a concise and easy to follow example in the near future. The much more robust implementation will be the focus once the basic implementation is made available to everyone. We will deliver a detailed update regarding this 1.0 feature complete reference implementation within the next 14 days.
 
Cheers,
Edgar at BrashMonkey