Finished all the export options, AVI and QuickTime work. Added some lines connecting keys, so you can easily see if they are linear, bezier, or stepped. If two adjacent keys have the same value they will show up like stepped (no connecting line).

Updated links in first post to version 0.85beta. This fixes a couple crashes, adds some new zooming buttons, export dialog (though actual export is still disabled in the beta, sorry), dopesheet key lines, Mac uses command instead of ctrl for a modifier key, auto scroll when dragging outside of dopesheet/tree, and other relatively minor stuff. The app should be quite stable now. I appreciate you guys trying it out! You're the breast.

Just a quick note Nate, when a drag is initiated, stop the interpolation of the camera zoom/movement (if in there is time left to process). Scrolling fast or flinging the camera and then initiating a drag before the interpolation is over causes an unpleasant jump, breaking the otherwise silky smooth feeling of the controls

Thanks voidburn, I implemented stopping the zoom when a pan occurs. I probably didn't notice this since I use a trackball. It has a scroll wheel but is still harder to scroll and then quickly pan than with a mouse.

I ended up refactoring a bunch of stuff today, but things are quite a bit tidier. Hope I didn't break anything!

I played around with this tool for a while. It's very smooth, professional-looking. It definitely appears to be something I could use to help me make 2D art for small games, and would pay for (at least, if there would be an indie license not costing hundreds of bucks).

Probably no surprise, but I went on a refactoring spree. I had to break the project file format, so unfortunately you'll have to redo your project in the next version. I will avoid doing this in the future but these changes were big.

The biggest new feature is support for multiple skins. This allows you to reuse a skeleton and all animations with different images. This includes support for changing images in animations and the correct images will be used from the skin. I swear this is the last big feature before release. It's just that this feature had no workaround and would not have been easy to implement later.

Updated the first post with version 0.86. You will have to recreate your projects, sorry. We won't break your project files in future releases. This has all the fancy refactoring, the new skin stuff, and lots of minor polish. You can see the export features but can't perform an export as this is still a trial version.

I spent a lot of time on the libgdx runtime since it will be ported to other game libraries. After a number of iterations it has turned out pretty slick.

We are working on a simple kickstarter video and hope to have it up soon. Once that happens we will offer the full version to our kickstarter backers, which means you'll have export and the libgdx runtime available and can use Spine in your games.

I tried the editor and it seems pretty good, so I'm thinking about writing a runtime for the animations produced - any ideas on how this would be best done? How final is the actual file format at the moment? Is there any documentation on how the runtime should behave?

Porting over the libgdx runtime sounds like a good start, but I'm worried I'll have to constantly update it if there's new features etc. going in. Particularly if there's no actual documentation, just a 'de facto' standard of whatever-the-libgdx-runtime-does. (It'd be Ruby all over again! )

Not sure if Nate will be making documentation for the runtimes, but if I know him right, he probably will. We will support some of the major frameworks/engines, but I can't give you a concise list yet.

I think it is best to maintain "official" runtimes for various game libs rather than carefully spec out the data format and hope people implement it right. Also I don't see the format changing dramatically. The official runtimes could easily be used as a reference to support esoteric or one-off game libs. Developing a runtime solely from a spec of the file format would be a pain. The math for transforms itself isn't hard, but tricky to get it exactly right. The animation timelines are a little tricky to get right too. Most of the libgdx runtime isn't actually libgdx specific, you can reuse almost all of it and for the most part just swap how you draw attachments. This means if the format changes or features are added, re-porting the runtime is easy. To give you some sense of the size, the libgdx runtime is 1600 LOC, which includes both the JSON and binary loaders.

The format itself has already gone through some iterations and I feel that it is pretty stable as is. Attachments have a type, so when we add bounding boxes (relatively soonly) it won't change the format. There isn't any short term plan to change the format. Actually implementing some games with it may highlight any weak parts of the API though, so I can't claim everything is set perfectly in stone.

I'm beginning to think that that'll be downfall of Spriter.. :-/ There's been several attempts at getting their format working in java, but people disappear, don't have time, only implement what they need, use different libraries etc.

Aye, it would hobble a tool like this to not have good game library support so I think it should be part of the core development. We won't work on runtimes for game libs other than libgdx until the kickstarter though.

You and people like you disparage the whole work of Open Source community, this is a shame.Although it is really great what you've done, but this just is not fair, that you take someone's work and willingness to share their work to the community, and with that you want to earn money.

Ha! I probably shouldn't take your obvious troll bait seriously, but I'm a sucker. Maybe you should click the OSS projects link in my signature? I'm the author of libgdx upon which Spine is built. I give away libgdx, Kryo, and many other projects for free. I also maintain and support users of my projects for free. People who write OSS know what they are doing when they choose a license that allows others to profit for their work. Who are you to judge people who would follow the author's licensing to profit? There is nothing wrong with wanting to be paid for my efforts. Software engineers need to eat too.

Ha! I probably shouldn't take your obvious troll bait seriously, but I'm a sucker. Maybe you should click the OSS projects link in my signature? I'm the author of libgdx upon which Spine is built. I give away libgdx, Kryo, and many other projects for free. I also maintain and support users of my projects for free. People who write OSS know what they are doing when they choose a license that allows others to profit for their work. Who are you to judge people who would follow the author's licensing to profit? There is nothing wrong with wanting to be paid for my efforts. Software engineers need to eat too.

And finally, just to mention:

"It abstracts away the differences between writting desktop, Android and HTML5 games based on standards like OpenGL ES / WebGL, JAVA"

Dedara what exactly is the point of your posts? Now if you're complaining that we are charging for software largely built on OSS you are forgetting a couple of things. First of all spine would never have become public, we would have kept it to ourselves simply due to the fact that it would have been unpolished and pretty much impossible for others to use. By making the choice of charging for it, we have forced ourselves to polish everything, and by that needing to put far more work into it. Secondly, Nate is in fact one of the main contributors on libgdx together with Mario, hell even I have contributed things to libgdx, however limited, I am by no means an author though. I'm the guy behind most things artsy in spine, and many design decisions, if we had gone our original way, things would have been very different, and just to be able to use the runtimes you would have needed softimage to export the data from and trust me when I say it would have been far more expensive than spine will be. If you still don't approve of this, then by all means feel free not buy it and use something else, but please do not derail this thread with unfounded bile.

Reading your posts again, I realize that you're probably trolling, I simply do not believe that you can be that naive, to expect everything to be free, in your eyes all games released using libgdx should be free as well?

You and people like you disparage the whole work of Open Source community, this is a shame.Although it is really great what you've done, but this just is not fair, that you take someone's work and willingness to share their work to the community, and with that you want to earn money.

There's nothing wrong with making money from OSS. You are simply factually incorrect. I like RMS but he's not trying to create a world in which software engineers can't make money, he's trying to create a world in which software cannot restrict your freedoms.

I'd suggest you learn a little about OSS before you open your mouth again. And quite frankly, as the author of some great OSS software which other's have profited from, I think you should apologise to Nate.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org