izb

@lucid - Frame numbers wouldn't need to be awkward at animation time either, since the UI wouldn't need to change at all - this would be a change that exists purely in the file format. Correct me if I'm wrong (I could be) but spriter still works on whole frames for setting keys?

Another preference I'd have is for things to always be expressed in frame numbers, rather than by time. Spriter does work with frames, even if the tweens will be aimed at a time-based animation. If the start of the file declared the target frame rate to be 60fps (A common monitor refresh rate) then if I had something happening on frame 4, then the time would be 0.0666666666666667s, which might be good enough, but may end up imprecise on the target playback application. "Frame 4" is always 100% precise and I might pragmatically decide to play the animation back at my monitor's refresh rate of 70fps instead for the sake of good synchronization at the expense of some accuracy with speed. If you want time, you can work it out, and this also makes the file smaller :)

One point is that there's no reference to the point around which rotation takes place, or is that always assumed to be the centre?

My main concern with this format is that it's intended to be used by game engines, but it's quite clearly in some ways oriented towards the spriter application itself. For example the references to folders hints at an IDE in which you add folders full of images to a project, which is useful when you're in a spriter application designing animations, but kinda irrelevant in the field. I'd prefer to see something stripped down and 100% focussed on what's needed by an animation playback system only, and with the spriter metadata such as folders held elsewhere. This would mean a simple list of images with full paths. (Also, to answer the question in the example schema, yes width and height in the XML would be very useful). The good news is that there's no reason why this needs to be held in a separate file. An example of project metadata in XML form can be seen in the Inkscape SVG editor. When you save an SVG file in inkscape, you get an SVG file that loads into any SVG viewer as expected, but if you open the file you see lots of inkscape-specific information intertwined with the SVG data, but in a separate XML namespace. This way an SVG viewer picks out just the SVG data by reading data in the SVG namespace (xmlns:svg="http://www.w3.org/2000/svg") and the Inkscape application can pick up application information such as what size the windows were, and what colours were in the palettes. The nice thing here is that inkscape then also has a save option for 'Plain SVG' which exports only the parts relevant to SVG viewers. If this makes no sense, download inkscape, draw a rectangle, save it and look at the file in a text editor, then save a plain SVG file and compare it. The same thing could happen in spriter; by default it could export SCML laced with as much spriter project information as it cares to put in there. If you load that into a game it'll be bigger than it needs to be, but it'll still work. Alternatively save a 'Plain SCML' file and the file will be honed just for the precise needs of an in-game animation player. The advantages are not just smaller files for games, but changes to the format of the XML used by spriter itself will not compromise the file format of 'Plain SCML'. I.e. if you decide to, for example, remove the 'folders' list from the spriter project information, then you can do that without needing a new version of the SCML spec. You can also add as much extra stuff to the XML for spriter's benefit without worrying about the impact on the game engine, i.e. the game engine requirements are not negatively affecting the requirements of spriter's persistence needs.