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 am helping someone with his project, kind of like a Terraria clone for now, hopefully we can come up with some stuff to make it more unique.
On a side note, I guess I am among the few who is using Spriter for pixel art :-P
Good efforts, some suggestions:
Your character seems to be jumping around (his legs are not on the ground at all times) especially for the middle pose. I suggest you lock the feet down to the ground using IK. I can understand what you are going for, small hops on both feet, but without the legs bending a bit it looks weird. If you are doing the same pose you would need to bend your knees a bit, do the hop and land, rinse and repeat.
The same goes for your first kick animation, the right feet needs to stay in place during the kick and not move. Also, move the head a bit less, right now it looks like a bubble head!
Sorry for being so critical!
The categories and percentages represent what's required to cover full and flexible support for all of Spriter's current features, plus some additional improvements we can't go into detail about, ATM. They do not completely cover the deform feature – though they do cover the important foundation for it – however, as soon as the percentages are all near 100 and we're ready for full testing, Edgar will switch his focus to the deform feature. It will be our main focus and will have a similar thread (with frequent updates) dedicated to it. Our goal will be to get it ready for public testing and feedback as soon as possible after the reference implementation is out.
More information about all this will be coming soon in another news update. Sorry for being more ambiguous than we'd like.
In this project I am working on, every time I try to use the IK menu I have a partial hang up...it is really weird, it looks like the mouse button stops working even in windows (i can only use keyboard). This stays until I try to force spriter to close using alt+cntrl+del.
It is really weird!!
The trick is its only available when setting a custom curve for a key for a specific object, NOT for a main-line key. Left click and drag the top of the timeline palette upward to reveal the timelines of each object,. If you set a custom curve for any of those keys (for specific objects) then you'll see the constraint check-box like in the video.
Usually I have sprite named Torso, and the the bone for the torso called BTorso.... That's easier for me to know what's a bone and what's a sprite. But Stinky's way works, also.
You have something already named Torso, it is a sprite, but i guess bones and sprite cant share the same names, the 001 is a auto-renamer function I am guessing.
I end my sprite names with _SPR, like Pelvis_SPR, so i dont accidently screw something up in the out-liner when I am animating. I have already ruined 2 animations by moving the wrong key-frames.
It would sure be nice to hide the sprite names when I am trying to animate,