lucid

Just wanted to share some of my work and possibly get some feedback, I think I'm getting the hang of spriter ' v'
If you want to check out some other spriter works I've tweeted some over at https://twitter.com/Soulgryn
Idle
Casting
Casting ended

Hi @adamcreator,
I sent you a link to your fixed file through the support system, but I'll detail the issues I found here, in case someone ever has similar issues.
First, there were some png images that weren't importing to C2 correctly.  This is usually caused by software that saves or converts pngs in a nonstandard way.  I did a batch action in photoshop that just resaved the pngs.
The jpgs were coming up as missing images in Spriter, this could cause issues with the save, which would make it not import correctly into c2.  Your jpgs weren't loading correctly in Photoshop, so I saved blank pngs of the same size with the same names (just paste your jpgs into these pngs and save the png).

Then you had certain objects with an exclamation point in the name, which was preventing c2 from generating the same name for the sprites.  This may not have caused issues, since the associate action specifies the filename, but to be safe I renamed every object in the project by replacing the  !'s with _'s.  There were also files with '!' in the filename, which would eventually cause issues with on piece of software or another, so I changed those as well.

Lastly,  I'm not sure how it happened but there was an object listed in your file that no longer existed in the project.  Because of the way it was being stored in the scml file, the scml plugin couldn't finish loading the file, so I removed that as well.

On a side note, when I was attempting import, C2 was having issues with your wav files, and couldn't import them.

In general, I'd advise not using special characters in filenames and object names, and if you're using any obscure software to save or convert images or sounds, that seems to be the root of a lot of issues, as Photoshop, C2, and Spriter all had trouble with some of your files.

-cheers

 

That is awesome, thank you SO much! I'm going to get to everything at the start of my next work day. It may take me time to find out why my PNGs and JPGs are saved in an unusual way, as all my image work and saving is simply done through "Adobe Photoshop CC (64 Bit)", but I'm just so glad to finally know what the cause(s) are. Thanks so much!

For complicated reasons UE4 requires that plugins have to be recompiled every time they are packaged into a game. So game-makers need the libraries and their header files in the project or they couldn't use my plugin. Trust me, I know what I'm doing.

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