esDotDev

Nah it wasn't textures, they're relatively small. It was some weird exponential growth thing, where as the number of different anims increased, it took longer to import, and since main char had like 15, it just lockd up completely. In any case, works great, can't wait to dig in and start adding some functionality back.

Ya this behavior is super important for us as well. Our title bardbarian was created in AIR, and I authored one of the earliest spriter plugins for AS3, and now we're looking to port it to Unity. I'm happy to help contribute once the new version is posted. We really need to be able to swap pieces dynamically at runtime. Usage examples include: * Swapping Brad's head as he becomes more and more damages * Swaping Brad's guitar strum hands, to make him appear to be playing guitar in all animations. * Dynamic Blink Functionality on all characters In AS3 it was all code driven, I simply had a little string_hash for each image, and I could swap it in with any other key easily: player.swapPiece("head", "head_blink"); //Blink - Any time head should be displayed, head_blink is displayed instead ... player.unswapSprite("head");//Un-blink This also enabled really easy character skinning with just naming conventions, without really needing to rely on Spriters character maps. goblin.swapAll("_purple", "_blue"); Everything was cached, and there was zero performance cost to having swaps. Would be really great if we could figure out something as effective for Unity. ps. The new version works so much better than before, last time we tested this, it took 15minutes to finish importing our main character, now? Just a few seconds... nice work!

Any idea why this would not work on SCML files created in beta Spriter? We have some animations, created in Beta 3. I've opened them up in R4, and re-saved the file. Everything appears to look fine in the raw SCML, but for some reason, none of of the sprites are linked properly, and none of the animations play. When I create a new anim from scratch, it imports fine. Kinda stumped... [Edit] Figured it out, seems to have been caused by some forward slashes that were present at the beginning of the image names in the SCML. Lookin forward to digging into this tomorrow :)

Ya I tried process of elimination to try an narrow it down, but it doesn't seem related to any specific animation, just to number of animations contained within a single file. Most of our characters have <10, and they all import fine. Our main character, has 24 and it brutally slow to import. But I delete some of those then it begins to import faster and faster. I'll likely add a ton of API's to CharacterController, for better runtime features, but pretty stumped on where to begin with the parsing stuff. Anyways, I'm just happy to see it running at this point :) And yes, Alpha = visibility, if you fade something in Spriter, it won't be represented in Unity. I can hack it in after the fact by just setting the color.alpha = 0 for the various sprites within Unity's Animation Timeline.

Actually it does work! It just appeared to be frozen, but actually just needed about 13minutes to chew through the animations. It's almost like there's some weird exponential performance issue going on. I tried deleting random animations from the file, and saw these results: 3 Animations - 5 seconds to import 6 Animation - ~1 minutes to import 10 Animations - ~3 minutes to import 24 Animation (ALL) - 13 minutes to import Modifying any of the animations seems to cause a full 13 minute rebuild pass as well. Luckily for us, this is a port, so we don't really need to iterate, otherwise this could be a deal breaker. Another issue I've found is that alpha is not supported. It's fairly easy to hack in after importing, but again this would be a major workflow issue if we had to iterate.

I can't seem to get this to work, I replaced the 2 .CS files, but the importer just locks up everytime while "Importing Small Assets". This is with Unity 4.3.1. http://cl.ly/image/1A223b0j342N It's pretty frustrating that 2 years after Spriter started, we still don't have a working Unity importer :( Hopefully we can figure out what is breaking... I'm not sure how to even begin debugging these scripts though. [update] It seems to work ok with our simpler animations, just struggling with the main character who has a lot of different anims. I'll keep trying to isolate what's causing it.

Hi guys, Happy to announce the release of Bardbarian for iOS. You can get it here: https://itunes.apple.com/us/app/bardbar ... 14929?mt=8 Trailer here: The game is powered by Starling, and uses Spriter for all animations. Android is coming in 2 weeks, with Steam to follow soon afterwards.

I just wanted to follow up on my post earlier. I'm seeing lots of advanced feature requests here, but I really think we should take care of basic functionality first. The ability to quickly select, or stretch a group of keyframes, is absolutely core functionality that is missing right now. Would really like to see this prioritized, as it will make the tool much more of a joy to use for all users.

Here's an example. In this dinosaur animation, I want the "roar" to be about half the speed it is currently, and would like to stretch it to be twice as long.... http://cl.ly/image/1N3D0f2q2O0X I don't want to stretch the entire animation, just the selected frames. Currently this is a very tedious and slow process.

Unless I'm missing something, the latest version of Spriter is still missing some very basic functionalities: 1. Ability to easily select a group of Keyframes Say I have 10 keyframes I want to move, currently it's very laborious process of ctrl-clicking each one, one mis-click and the entire selection is lost. Would be great if I could just press shift, and click the first and last keyframes, to select all of the ones in between. 2. Ability to stretch/compress a group of keyframes Once I have the 10 frames selected, I may want to stretch or compress them to make the animations shorter/longer. Currently there's no way to do this as far as I can tell. I'd like to be able to hold "Alt" and then click either end of the selected frames, to stretch all the intermediate frames. Common use cases for this are: 1. To slowDown/speedUp specific parts of an animation 2. To quickly move a specific part of the animation along the timeline 3. To quickly delete a specific part of the animation 4. To quickly duplicate a specific part of the animation This seems like such obvious functionality... am I just being dumb and not seeing how to do it?

Bug Report: Stranded keyframe's are never cleaned up. We have an SCML file that has been through several iterations of Spriter, it's a 900ms animation, yet the SCML is filled with orphaned keyframes that are impossible to remove from within the GUI. You can see an example of 3 orphaned frames here: http://cl.ly/image/261q3e2u1x2k This is replicated over a dozen keyframes and the mainline as well, so quite a hassle to clean up by hand. Fix: Spriter should check the SCML file, and prune any keyframes that exceed the total animation duration. ie, if it's a 900ms anim, nothing should exist after 900ms.

Here's the project files for my issue: http://cl.ly/2I2r2e3p2f43/imp.zip The animation still opens and saves no problem, it's just that it doesn't play back properly. When the playhead passes the mainLine key 2, sets the foot to it's at key 6. When the playhead reaches key2 of the foot, then it snaps back, and correctly begins to interpolate to key#3. So basically, it's the foot timeline is tweening like this: Main 1 > Main 2 > Main 3 Foot 1 > Foot 6 > Foot 2 It should be: Foot 1 > Foot 2 > Foot 2

Ya Im getting that too, when opening older SCML files, everything is "Object_" and there's tons of dupes: http://cl.ly/image/2l1j0s1n0q2u Would be nice if you could smartly handle these older files.

Latest build is really shaping up! Great work dudes, I've uncovered a weird bug in the SCML generation though. Essentially, within the Mainline, spriter is assigning a keyId of the 6, when it should be 2. In the attached video, you'll see 3 mainline keys(0, 158, 319), but only 2 "footsmall" keys (0, 319). In mainline entry @ 158, for footsmall it's specifying keyId=6, this is the final frame @ 1800ms, instead it should be pointing to the keyId=2, @ 319ms. https://vimeo.com/62797995

Very cool, thanks for listening! Good luck with everything, hope that crap with your arm gets sorted out soon :(

To be honest we're starting to get into a bit of a jam. We decided to go with Spriter back in November, when everything seemed to be progressing quickly. The final version was supposed to be sometime in Dec/Jan, so it seemed a safe bet. Since Nov, nothing new has been released, and the latest build posted has a whole bunch of bugs that are killing us when trying to produce content. So now we're in a place where the final game is coming out in 6-8 weeks, and still no updated version that we can use in our production work, and the latest version posted is quite unstable. It would be great if you could issue a stability release in the next week or two, something that had feature parity with A4 that we can use going forward... we don't need bones, we don't need Onion Skins, we just need the basic features in a stable form. Since Onion Skinning and IK never really worked in the current build, could you not push those off to the next version, in favor of finishing up the core feature set and testing? From that list the core feature set seems very close to completion :) Thanks! shawn @ http://esdot.ca / http://treefortress.com

Happy to share our latest lib: SpriterAS https://github.com/treefortress/SpriterAS It's highly optimized for Starling, and offers a few extra convenience functions to allow you to do lots of cool stuff. Check out the blog for lots of examples: http://treefortress.com/introducing-spr ... -starling/ If you'd like to get notified of future updates, or new projects, just follow our blog: http://treefortress.com/blog/

I'm interpolating the positions just fine, it's just the bones that are the issue (well not really an issue, just a matter of adding support for them, time permitting). I guess my request could be described as: "The ability for my designer to use bones, as a shortcut, when animating, but, to not have that to deal with the extra overhead of processing the bones at runtime.". Maybe it's not possible, but it would be nice to figure out a way to do enable this.

Ah, ya that makes total sense. As an alternative to that, what about the concept of "Filler Keys", these are like an extra layer of keyframes that the designer can toggle on or off. When toggled on, Spriter simply insert keys at the selected frameRate, shown as a series of non-editable keyFrames of a different color. So, in your example, the animation is just 3 actual keyFrames, but to avoid bone overhead, the designer Chooses "Enable Filler Keys" and selects a target frameRate of 30, spriter slaps in a keyframe at every 33ms for the entire animation and bones are excluded from the export. Just a thought...this should saves some extra processing time at runtime.

Is there a reason that Spriter can not just export the pre-calculated position for each Timeline object?? It seems kinda redundant for the plugin to to all the work of interpolating / mapping of bones, when the end result is just modified position data of the original Object's. Why not just bake the bone-data into the object's positions themselves? I realize there's use cases for having access to the bane data, but I'd guess they are in the minority, most games will just want to run whatever the designer has created. Perhaps a checkbox to toggle this?? Edit - BTW, I'm currently working on implementations for Flash Starling and EaselJS Canvas, which will add more support than the existing plugin, like ability to swap pieces for another, or control playbackl speed. I'm 90% of the way there, remaining issues are rotation and bones.