April 19th, 2013
April 19th, 2013
April 17th, 2013
Implementing all the runtime over and over (and over) for various toolkits in multiple languages has highlighted where things can be improved. I’ve just committed some refactoring for all the official runtimes (except spine-corona, which will see some attention soon). I’m now pretty happy with how they are working, so it is unlikely that there will be further refactoring like this. Sorry if this breaks your code, but it shouldn’t be too hard to fix up.
Most classes now only store data, without anything specific to rendering. The exception is an atlas page, which needs a reference to the texture for that page. Writing a renderer just means going through the data objects and rendering them. Extending a generic runtime is cleaner and takes very little code, especially for spine-c which now uses much less weird C OOP. Eg, extending spine-c for SFML is done in ~100 lines of code.
This refactoring also enables use of an atlas with multiple backing pages for C#, XNA, cocos2d, and cocos2d-x. SFML is now the only runtime that supports only a single page atlas.
We now have a pretty solid foundation for the existing runtimes. Up next is to bring spine-corona up to date, separate it into a generic Lua runtime, finish the Torque2D runtime, and create something for 2D Toolkit users.
April 15th, 2013
We are happy to announce that the Unity runtime is now available, as well as the generic C# runtime which it uses under the covers. As a bonus, we’ve also implemented an official XNA runtime, which means your XNA and MonoGame projects can now use Spine. XNA and MonoGame weren’t in the Kickstarter goals, but we are happy to have them officially supported.
The Unity runtime was implemented without any dependencies on other Unity plugins. We have yet to see if Futile or 2D Toolkit would benefit from code specific to those plugins.
We now have 8 videos on our videos page. These show how to use various aspects of Spine, so be sure to check them out! We are working on more, such as a video that demonstrates how skins are used.
April 9th, 2013
Maintaining the changelog has been a bit of a pain to keep up to date, but I know people are curious about what goes into the new builds and the Trello boards only give a high level view of what is being done. I’m going to try to keeping it up to date again, but only for editor features. For a more granular look at what is being done on the runtimes, I suggest reviewing the github commits.
Other than some relatively minor features, we’re still working on runtimes. The C# and Unity runtimes are coming together and we hope to have something to show soon!
April 4th, 2013
Recently it became time to tackle the cocos2d-iphone runtime. No one likes mixing C++ with Objective-C and they are right, it’s nasty business. Ultimately we decided to write a generic C runtime from scratch. This allows us to service C, C++, and Objective-C game toolkits with a single codebase. It is also very portable and can easily be wrapped to support other languages, such as Python.
We are happy to announce that the cocos2d-iphone runtime is ready for use! It is based on the generic C runtime (spine-c), but provides an Objective-C API to integrate better with your cocos2d code. Using it looks like this.
The other news we have is that we decided to make an organizational change to the Spine export format. Previously a skeleton was exported as a skeleton file and a number of animation files. This has changed to just a single file containing both the skeleton and all the animations for that skeleton. This makes loading skeletons faster, especially on mobile where SD card access is slow. A few hundred animations could take a multiple seconds to load if they were in separate files. Also, since this change stores animations centrally on the SkeletonData, runtime APIs are improved by allowing animation look up by name.
For those worried about loading all animations at once, don’t fret. It really is not much data, even with many hundreds of animations. In the highly unlikely case where someone needs to load a subset of the animation data, it would be trivial to modify the JSON loader for the runtime you are using.
The documentation and official runtimes have all been updated to handle the new format. We know there are a number of projects that have code using the old format. We are sorry if you have to change your code! The changes should be easy though. The data itself was not changed, only where it is located, so all your existing parsing code can be reused. We don’t change the format lightly, but decided there are enough benefits in this case to warrant the change.