timpart

Tweening Just been looking at tweening in more detail. I notice that the (timeline) key lets you change the sprite being shown. Is that intended to be a sudden change at that point in time? I presume so, rather than some strange fade in fade out process. I imagine this kind of thing would be useful if the animator wanted to change the sprites used for the body parts if the body turned from facing front to sideways. I was thinking that the animator might want to specify a start and end point for the movement, then in finer detail during that time period change the sprites used. How easy would that be to do? It would mean having the movement tween cover several key positions for sprite changes. Fortunately, if I remember correctly, the bezier style linear, quadratic and cubic tweening you are using has the handy property that you can cut it into pieces at arbitrary times and the resulting pieces can all be defined using the same method. Lots of little pieces not so handy for the animator though who might wish to edit the whole tween later. Perhaps some kind of flag saying tween is part of a larger whole? Or a flag to say that during editing a tween should be made to stay smooth with the previous and / or next one? Which might be almost the same thing, not thought it through in detail.

Parent ID I think I didn't make my question about what does the parent ID contain clear enough. I am perfectly happy with the idea of having parents and swapping them around as needed. From you previous comments you intend having groups as well as bones. They're two different types I think as bones act a bit differently to groups, though groups might be a super type of bones. Suppose a sprite has a parent. You want to put its ID into an attribute. Bones have IDs, groups will have IDs too. If bones and groups have separate ID sequences then when a sprite refers to a parent ID , that is ambiguous as we don't know if a bone or a group is intended. I would suggest that the way round this is to make bones and groups have a common ID sequence. Supertype As I mentioned before I would go further than just a common sequence. Create a super type "object" that has sub types of sprite, bone, group, collision box etc etc. Then rather than specifying different tags for sprite, bone, group, collsion box within mainline key with virtually identical attributes, just have an "object" tag which refers to the actual thing it is. That makes the format more flexible for adding things in the future. (A few sub types like axis aligned collision boxes can't be rotated, and action points have no change if rotated since they are points.) All objects would have a common ID sequentce, and the parent of an object would be another object. You have partly gone down this route already by making both ref bone and ref sprite point to a timeline. So timeline is what happens to an object over time. Instead you could have had a sprite-timeline and a bone-timeline. (I'm not suggesting that you do.) Sprite vs Timeline Key I suggested that these two are the same concept. You pointed out that you have put a time on Timeline Key but not Sprite. As a counter argument I would suggest that the time attribute is something redundant (but very useful) that you have put on the Timeline Key. If you were to get rid of it (I'm not suggesting you do) you could still find out what time the key happened, by following the link to the mainline key, in the same way that a sprite knows what time it happened by looking at the mainline key it is contained in. Equally you could put an unneeded attribute of time onto the sprite. Tim

I was wondering how to make something vanish as well. Perhaps set x-scale and y-scale to 0 so it is zero size? If objects on screen can receive mouse clicks, then something of zero size wouldn't but a totally transparent object might. Also since the format only gives moments in time, duration of something is implied by the next key frame encountered. For things like sparks from an enchantress's wand, does the mainline animation define their duration, regardless of how many tweened animations are happening in parallel? If nothing special is happening in the mainline, but a tweened thing reaches a key frame, does the mainline need a key frame at that point as well (one that would be the same as the previous one presumably)?

Some thoughts on the parents of bones (and sprites) I'm a bit concerned that there seems to me to be a combining of two concepts. The underlying bones and their rigging The bone at a particular moment in time in a key frame So when a parent attribute refers to an ID that ID is of what exactly? ID of a bone within that key frame (which only exists for that key frame) Presmably that has to be resolved to the underlying bone for use in future frames. Or is it the ID of the bone itself? How to sprites handle this when they can be contained within bones or groups? Need to have one series of IDs not a series per type in this case. If a parent is specified in a bone / sprite inside a key frame does that indicate a change of parent? So if you don't specify that attribute the parent is unchanged? You have specified a default of none, but that isn't the same thing. Possibly need two values, one for unchanged, the other to mean set to none. I don't see how the alternative of specifying parents all the time would work, as as soon as you had gone through a reassign parent animation and returned to a normal animation the parentage would be put back again. So assuming you aren't doing that , how do you set up the default rigging in the first place? I'm also a bit surprised that you are having bone, sprite specified within (mainline) key. These are all specifying how something is changed at that moment in time. Can't you have a single object supertype instead? (Or I'd call it keyed object as it is only the object at that time)

Thanks for the reply lucid, I think we are talking about the same thing. Where my diagram has an arrow the object at the end of the arrow appears within the object at the other end in the XML, and nested within the other object in your latest diagram. My box labelled Key Image (perhaps that would better be named keyed image) represents the postioning etc of an image at a key point in time, and how to tween it (or not) to the next point in time. The snag in representing it in XML terms is that it would end up within two different things which is impossible. However in memory it is perfectly feasible to include in two different lists and for it to have pointers to each of its two parents. I would suggest to you that your (first) sprite tag and your key tag within timeline both represent the same concept. You have added the (ref) sprite tag and the mainline_key attribute of (timeline) key to get around the problem that an object can't be inside two things at once. You happen to have divided the occurances into two places depending on whether they are untweenable or mostly tweenable for convenience, but I think they are the same thing and could be given the same tag name. (would still need the ref sprite and the other attribute to overcome the difficulty of things being within two things at once) Have I managed to explain a bit more clearly what I mean? I'm not suggesting that things are forced into non tweened viewpoint or tweened viewpoint, but rather both simultaneously,

OK here's my attempt to understand the tweening things as an entity relationship diagram. Arrow at end of line indicates a many relationship. The names in the boxes are my own inventions in some cases. Underneath the bottom row of boxes I've put the tag names used in SCML, one row for the untweened ones, another for the tweened ones. Looking at where the two tags named key have ended up I think it explains my confusion in thinking they were both the same thing.

Character Maps I prefer using numbers to specify files / folders What is the special value to mean not applicable. This would be the default for the attribute. I'd suggest 0, but you might have other ideas, like -1. I'm not sure I understand your explanation of replacement. I use target to mean something that gets stuff transferred to it and hit / replaced, but you seem to be saying it is`the source of the files. To make an entire folder vanish you could either have a special attribute, or perhaps set the source folder to null, but specify a destination folder. (I've avoided using the word target here.) Could do the same for a particular file as well perhaps. Tweening I appreciate why you want to have two different viewpoints. The first is time based and shows what things are around at each point in time. The other is thing based and shows what happens to that thing at each point in time (and is convenient for tweening). I am slightly concerned about the names you have come up with though (two sprites and two keys with different attributes) I'll give this more thought. Apart from showing how the z hint discretely changes over time does the second sprite type actually add anything apart from convenient cross referencing? Presumably by going through the timelines for each tweened object it is possible to reconstruct where its key frames appear in time. (This is another very good reason for specifying time from a start point rather than a series of intervals) The mathematician in me would be curious to see the tweening formulae in more detail. From the looks of it it is possible to do Velocity Acceleration Change in Acceleration 1 (linear) Constant 0 0 2 (quadratic) Varying Constant 0 3 (cubic) Varying Varying Constant So these would cover a variety of physically realistic situations. Regards, Tim

Good point 32bitkid about direction of y axis. We need to keep things consistent. Personally I think in a cartesian manner therefore I am prefering y going up. ;-) The description of id for animation seems to have suffered from excessive copy and paste. I think you meant unique within the entity. (Although I am willing to go for unique within SCML file if that makes reusing animations over several entities easier.) Regarding my preference for color to be broken up into r g and b, the processing of variables in an "SCML manner" involves altering values of variables. On page 13 of the 2D rigging in Spriter 1.x document relational variables are mentioned. If for instance we want the hero to get darker as he goes under the shade of some object we could perhaps use relational variables. (I'm not entirely sure how practical this is with my current knowledge) The intention is that as he goes under the shade he gets darker to simulate less light on him. I don't really want to have know that the distance is going to affect a color variable so it has to be split into three components before being scaled. Having r, g and b would allow them to be simply linked. I hope I've managed to explain what I mean. I agree that both Spriter and plugin needed data should go into the same file, but having different namespaces will surely bulk out the file a bit which I thought was the thing we were trying to avoid? Regards, Tim

Personally I'd avoid putting a frame rate at the start of a file. The files are meant to work on many platforms and they could have widely differing frame rates. JavaFX uses times (in microseconds!) and says the animation won't display a keyframe before the time you give, but the exact moment it gets displayed after that time could vary (matching a physical frame).

@pstudio XML readers should either give you elements in the order they appear in a document, or return a tree which can be traversed in the same order as the original (depth first). Transforms of XML can reorder things if they like but can also preserve order. XML is successfully used to represent text documents and they aren't accidentally jumbled. a z order attribute is an alternative to the hints I suggested if a sprite keeps the same value from frame to frame in an animation unless it changes z order. That would mean gaps in the sequence could be present in any given key frame though. I'd second the idea of providing a DTD or schema.

In the beta we didn't have tweening so it was possible to take each frame in its own right and just render the sprites in whatever order they turned up in. Once we get into tweening we want to match up the sprites on a frame with those on a previous frame so we can make that sprite tween as needed. I'm a bit worried about the matching process. Sprites can be inserted and deleted which isn't too bad, but the awkward bit is sprites changing z order. Suppose a sprite on the second frame turns up earlier than expected. Have the sprites that were before it been deleted, or has the z order of the sprite got earlier? This could be worked out with two passes through the data, but I'm wondering if Spriter could add a hint attribute with values like new, lower z, higher z, deleted after this frame. Then Spriter could do the hard work, with less for plugins to do. I'm not expecting the z order itself to tween, just jump to new position at the appropriate key frame. Tim

Key Will the first key always have time="0", and will subsequent keys be in ascending time order? Sprite I've noticed that angle now goes clockwise. Is this convenient? Mathematicians regard anti-clockwise as positive and many graphics packages follow suit. Clockwise might make more sense to casual human readers, but they won't be reading the file most of the time. I agree with your other posters that scale_x and scale_y would be clearer than w and h. I am slightly surprised that you can't increase an image's size but I suppose that it avoids blocky looking images. I'd strongly suggest that color becomes r, g and b. Otherwise trying to tween color between two values breaks nastily. The red channel is ok but the others can take on unexpected values. Folder If you allow nested folders I suggest you define what character is used to separate them in the path held in the name attribute, so it can be converted to other conventions easily Image Does the name attribute contain the file suffix? If some file systems have different ways of representing the file type might be easiest to leave it off and have an extra format attribute that defaults to "png". I don't see any particular need for the image width and height. Things are looking good so far and I await further installments with interest. Tim

IDs What sort of values can these take? Are they intended to allow implementations to make use of arrays to quickly locate needed objects? If so I'd suggest you don't allow negative or zero values. I'm excluding zero as some programming languages don't allow a zero index into an array, and zero is sometimes useful to represent not applicable / none. Also the various ids shouldn't get too large, and should avoid having gaps. Using 100000, 200000, 300000 as ids will need a very big mostly empty array. Will the various things that occur in multiples always be sorted in ascending order of id, or can we expect a random order? Third party tools might generate SCML with things in a random order and if plugins aren't expecting this it could cause problems. Animation Surely this should have an id attribute as well? When sub animations are included how are you going to refer to the original animation? Foreign ids in sprite For clarity I would rename folder as folder_id, and file as image_id (you don't have a file tag) Tim

This is looking good. I have some comments which I will split into several replies. The start of the file Consider having <?xml version="1.0"?> at the start, or at least things that read the file should accept it at the start if present. The spriter_data tag Consider adding a format_version="1.0" attribute containing the file format version so that plugins that read the file get advanced warning if you have changed format. Consider adding a generator="Spriter" attribute so that third parties creating SCML from their own programs can put their own name here. That way if they generate something that doesn't work with a plugin, you don't spend time wondering how Spriter generated that SCML Consider adding a generator_version="1.02" attribute. That way if there is a buggy version one day at least you know the file was created by it. File Properties You might want to have a fill in properties screen in Spriter that optionally add tags like author, copyright, license, file version, notes etc Tim

For the Pro version Collision areas In the old version documentation it mentions collision rectangles which seem to be aligned with the x & y axes. However in the API notes it suggests that a Spriter object could be rotated in its display. This implies that collision rectangles may end up rotated relative to the x & y axes. So my first feature request is Rotated collision rectangles can be put in the frame. Next up is a productivity improvement Allow a collision area to be attached to an image in an animation, e.g. a sword, then make that collision area appear in the same position relative to that image in every frame in the animation that the image appears in. This then means that as the sword image is moved frame by frame the collision area moves with it (shift, rotate and if image changes size, scale) saving a lot of work in putting the collision area over the sword in every frame. We probably also need a frame level override where the collision area is made local instead and can be edited or even deleted. Other collision shapes Triangle (Useful for pointy things. These can be combined to make general polygons if the designer is keen) Circle (If we feel bold with our collision algorithms) Thanks, Tim