timpart

Spriter scales first using the pivot point as a reference. Negative values should mirror. After scaling the sprite is rotated by any rotation amount you have specified. Do you have any rotation on your sprite? Tim

The current version of Spriter doesn't allow you to set them, but my understanding of the file format is that it does allow tags to be set at the frame of your choice. It also allows variables to be set to values (and tweened between frames) and to start playing a sound. So I presume the team intend providing these features at some point. You would need support in the plugin for your platform as well of course. Tim

@rIKmAN @wrongtarget I don't think ordering the pro version gets you access to the daily builds. See this comment by BrashAdmin Tim (not part of Brashmonkey)

The SCML file already contains locations, rotations and z-indexes and that data could be extracted out with an XML transform utility. If there are bones in the animation then locations and rotations would be relative to the bones. With an actual program it would be possible to produce a "filleted" version if you don't care about tweening as you say. Tim

To mirror someone's head, a scale of -1 on the x axis should do the trick, assuming the sprite isn't rotated. If it is rotated you will have to change the rotation to go the "other way" as well. Regards, Tim

My (unofficial) understanding is that the free version currently exports PNGs wherever you have defined a key frame. It doesn't create any intermediate positions. A future Pro version may support exporting intermediate positions, perhaps at a specified interval. The alpha version available for free from the web site supports the first kind of export already and I have successfully used it to obtain images for inclusion in a document.. Regards, Tim

I have now put version 0.2 into the DropBox https://www.dropbox.com/sh/gsmbqc62fz224cl/s82_KJhKPC It has 8 new tests. Tim

I have now posted version 0.11 to Dropbox with ids on the objects. N.B. version a4.1 of Spriter will lose the ids if you save the file from it. Tim

You are indeed correct, seems I shouldn't have trusted Spriter quite so much. I created the files with a3r1 but even a4r1 doesn't put ids onto non-tweened objects when it saves the file. (It loads and runs the files just fine though, so perhaps it is relying on something else.) I'm away from the machine I used to create the files, but I'll update soon. Thanks for the feedback, Tim

I've managed to find some time! Please see this thread http://www.brashmonkey.com/forum/viewtopic.php?f=3&t=2575 Regards, Tim

The Spriter SCML has plenty of powerful features, but can bit a bit overwhelming to implement all at once. Full blown animations can use features you haven't debugged yet and leave you wondering exactly what has gone wrong. To help overcome this I have started writing a suite of tests which go through the SCML features one small chunk at a time. That way you can concentrate on getting all the bugs out of a limited area before moving on to the next. I've put it on Dropbox as a directory of files you can add to your own drop box. https://www.dropbox.com/sh/gsmbqc62fz224cl/s82_KJhKPC Dropbox also gives the option to download as a zip file for those who aren't on Dropbox or don't want to add this to their drop box.. I am happy to have comments and suggestions about the test suite, but regret I don't have time to advise on SCML plugin implementation and debugging. Please use Edgar's official thread for that. Regards, Tim

I've been thinking of producing a series of test cases that explore SCML one feature each, but I haven't been able to find the time yet. These would be simple shapes moving around, not flashy full blown character animations; the idea being to get wide coverage of features overall and to be able to pinpoint exactly which feature isn't working properly. With a real life aninimation that isn't working well you might have to delve into thousands of lines of SCML and try to work out which feature is involved

I think the difficulty comes from an object only being able to tween between two points in a straight line and / or rotate about a point (which is possibly moving in a straight line). If there are multiple parent bones rotating individually, the path of the child can't be expressed with those two motions. It might be possible in simpler cases to eliminate a bone from the export, but I wouldn't want to be the one who has to program it so it gets it right all the time. Tim

The time attribute is the position on the timeline, not a duration. To work out the duration you'll need to find the difference of the time values on the current key frame and the next key frame. For tweened objects the has an that points to an appropriate in a You must then use the current time and the times in the and the that follows it in the file to work out the tween. Cheers, Tim

@xamar a4 is still a mid-development build, so I expect there will be plenty of opportunities to look for bugs and rough edges. It has several major new features compared to a3, as lucid mentions above.

This sounds like the feature of that particular character which I mentioned here viewtopic.php?f=2&t=3&p=1571#p1571 When there is a switch of sprite Spriter seems to keep the old sprite in its last defined position for the whole of the period between the two frames, then on the second frame switch the sprites. If you run the animation slowly you will see the hero's hand *seems* to slide along the sword. It isn't really, it is just staying still while the sword tweens and then hand sprite switches over on the next key frame. Similar things happen with the foot swapping from straight to bent. Apparently it will be possible to group sprites so they are on the same timeline, but then we'll have other changes to look out for (same timeline number but change of sprite I presume).

Alpha 3 crashes quite a lot for me on Windows 7, more so than recent builds which didn't crash at all. I can't see a particular pattern. Once I put mouse over the put a frame here button, another time I used the move to next frame on timeline button, but most of the time these don't have a problem. When exporting to PNG the status message has two problems a) The number in the message is out by one, for instance when exporting the final frame it said “Exporting key frame 9 of 10â€. I suspect this is because the images are numbered 0 to 9. b) The final “Exporting...†message hangs around after export has completed, giving the impression that is still going on. Perhaps add a final “Exported 10 frames†message. When I have a long timeline (900ms) I find it hard to work out exactly where I am on it as there is no number shown saying what time I am positioned on, nor any numbering on the line. My mouse doesn't move finely enough for me to put it on particular points, so I wasn't able to position it on a tick mark much of the time. Perhaps a numeric box showing the current position which is tweekable in some way? As a result of the previous paragraph I discovered another feature when I looked at the resulting SCML file. I had started by putting in a tweened object on a frame at the start of the animation and a frame at the end. (It was doing a rotation by a known amount). I then put in intermediate frames with a non tweened object which was rotated by the correct amount so I would have test of tweening. When positioning the frames I misjudged where I was on the timeline and got one of them on the wrong tick on the line, and I didn't notice until I'd put another one on. As I'd already typed in the right angles for both these frames I didn't want to delete them. Instead I moved the frames on the timeline to the correct position. (Or as close as I could get.) I later looked at the SCML file to check I'd got the right timings as some still looked out of place. It was at this point I discovered the feature. When a frame is inserted into a timeline where there is a tween spanning the timeline position, Spriter splits the tween at that point and stores the values of the tweened variables. If the key frame is moved the tweened values don't change, and what was a linear tween becomes non linear. So basically the positions are preserved but the timing isn't when a frame is moved. I can understand that this is desirable much of the time, but when there is a “surrounding†tween around a more detailed piece of action it could prove unwanted. Might it be better to have some way of saying “This is a defining key frame for this tween†by noting where the user changes the positions and recalculating intermediate frames when they are moved? Regards, Tim

This is of general interest since plugins will all be doing something like this. First I'm not sure about the test made by subtracting one angle from another. if(obj.angle - startObj.angle < 0 && keyFrame.spin == 1) addB = true; // if the current object's angle minus the last frame's object's angle is negitive and the keyframe's spin variable is 1 add 360 to the current object's angle in the following equasion if(obj.angle - startObj.angle > 0 && keyFrame.spin == -1) subB = true;// if the current object's angle minus the last frame's object's angle is positive and the keyframe's spin variable is -1 subtract 360 from the current object's angle in the following equasion Suppose startobject is at 10 degrees and current object is at 20 degrees and we are spining in a +ve direction Current - start is 10 degrees, and the test works correctly Now suppose start is 355 degrees and current is 5 degrees. This is still a positive rotation but because it goes through zero current - start is -350 degrees and the code above would incorrectly decide it needs to go the long way around with an extra 360 Perhaps you need a test against -180 or something and add 360 if bigger? The other possible problem is if(keyFrame.spin == -1){ System.out.println(currentTime + " " + angle); img.rotate(-angle); } The angles are always counterclockwise rotations. The spin is simply a hint to work out which way to rotate over the time period. It doesn't alter the representation of angles, so you should always be rotating by the angle and not negating it. Also your calculation of angle works out the exact total rotation of the sprite from a zero position. Does img.rotate() turn it from its current rotation rather than the initial position? If so you are turning by the total amount each frame and not just the change. Is there an image.angle() call you should use instead? Hope this helps, I've only had a brief look at the code.

Have you tried loading the beta format hero into a2 (which converts it) then using Save project as? Seems to work for me.

Animations are done relative to an origin, and the character walks etc on the spot. Is there some way of specifying how far in space the character moves in each frame? So either the bacground moves by that vector if the character is centred on the screen, or how far it moves against a static backgound. Platform games tend to have constant movement rates per kind of animation, but for realistic movement it isn't uniform through the whole cycle, and definitely not in transitions. I would think MoveDeltaX and MoveDeltaY variables would do the trick, but they would need to have standardised names for game engine plugins to know what to do with them. (That also implies that (at least some) variables are only unique to a character rather than being in a global variable space.) It would be helpful if spriter made it easy to set them to appropriate values matching a uniform rate over an animation cycle without having to get the pocket calculator to work out how far something moves in 25ms. What are your thoughts on this? I did say deltas in each frame, rather than absolute values compared to start of cycle, but the latter might be easier to work out for non-linear tweening. Would need total move in whole cycle as well though. Regards, Tim

Tweening - possible missing feature. I'm running Spriter v1a preview I loaded the previous beta format hero SCML file (containing Arthur) and said yes when asked if I wanted Spriter to guess Tweening. When I run the walk animation Arthur's right hand and foot behave strangely, with his hand appearing to move down the sword handle. On closer inspection this is due to the sprites being used with forearm0 being replaced at 150ms with forearm_nohand & hand_a, and foot2 with foot_2_bent. Because the two sprites are at 100ms but not 150ms the tweening matching can't find a position for these two sprites to move to so they stay put during the period 100 - 149ms while the rest of Arthur's body is tweened. The sprites are then replaced at 150ms with the other three sprites which then tween for another part of the animation. I'm not complaining about the tweening matching algorithm - it has nothing to go on. My question is how will the artist handle this when building something from scratch and they want to change sprite? If the original sprite isn't present in some sense on the frame where it gets replaced then tweening isn't possible. Two ways around this that I can see. 1) The object is tweened but changes the image it uses suddenly at the frame 2) The object disappears suddenly at the frame having being tweened up to that point. This would need a switch, since if just set alpha to zero that would be tweened and fade out the sprite over the tween instead. Tim

Here are my thoughts so far... It would help if there were notes on the major tags as to minimum and maximum occurances. Some seem to be restricted to being present just once andit's not always obvious which. Do you have a minimum size for an int? 4 bytes? Signed I presume. In the meta_data tag you give an example_data tag. Are you intending tags of any desired name could be inserted here? Are there any standard ones that Spriter itself will always use? I'm not quite sure how this will work out in preactise. (There can't be a document definition to verify against.) Would it better to have a kind of construct (and etc for other types) In name is an int. Surely it should be string? If it is meant as a reference to something, what does it refer to? Should the description be moved to id above? In looping "true" should be added to the allowed values. (Especially since it is the default.) In the time attribute is now integer. I think this is better than float, but do wonder if some people will want to set all their times to some fixed frame rate. If it doesn't divide evenly into 1000 they will have to compromise. In why are there r g b and a attributes? Also do bones have a default size? In the id field has to serve double duty: as the id of this bone ref In why is there no parent attribute? This stops it being attached to a bone / group. In there are attributes like x and y that can be float or int. If they are int do the decimal indicator and six tailing digits go from the number? In what is the t attribute? If it is time, why is it a float rather than an integer time in milliseconds. In is the attribute variable_type mutually excluive with object_type? In spin attribute the two values have been swapped. Anti clockwise should be +1, matching anticlockwise is positive concept for angle elsewhere. In the attributes of the enclosed tags have been extended compared with elsewhere. In make instanrt the default for strings and tags. In there is no way of overriding spin, so everything on a key must rotate in same direction. Not handy for gears. In name attribute, need a standard syntax for this. I suggest RFC 3986. In last_modified attribute need a standard syntax for this. I suggest the ISO one YYYY-MM-DD:HH:MM:SS Regards, Tim

I guess I still don't understand how c1 and c2 are used. I have a feeling it doesn't matter, because the best thing to do is support linear with no values or bezier with 4 values: cx1, cy1, cx2, cy2. :) Animation with only linear would be a huge inconvenience. lucid explained in more detail towards the end of his 14th May post in this thread. (page 2 of the thread for me)

Hi Nate, The c1, c2 confused me too. They relate to the velocity curve the speed at which movement takes place, not any physical movement in space. They are just two values not an (x,y,) pair. In your example moving from 0 to 0 can take place at any speed profile since it doesn't move at all. I do appreciate your point though that for actual movements, getting the velocities to join up at each end is tricky if the amount moved is different between different key frames. As far as I can tell you can only move a sprite position in a linear manner between two keyframes. (Or change a rotation relative to something else in a linear manner.) There are no bezier controlled movements between keyframes in Spriter. Regards, Tim

Been thinking a bit more about tweening, and realised that the only ways a sprite can move between two key frames are a straight line or a rotation (or some combination of these, possibly influenced by the parent moving too). Is there any intention in the future to have a curved movement path beween the two keys? If so it might be best to qualify c1, c2 and other related bits to make it clear they apply to the time "curve" and not a physical path to move along. (time_c1 etc) Or perhaps even split them out into a contained object (but that might make parsing a little trickier).