pstudio

One thought about usin RGB. What about supporting different color models (rgb, hsl...)? Right now it doesn't matter but when we want to interpolate colors it makes a difference which color model is used. I've included a simple example that show linear interpolation between red and green in rgb color space and hsl color space to illustrate the difference.

I don't think that's a good idea. [*:c8cmh8fq]It's something the artist shouldn't have to worry about. [*:c8cmh8fq]It just makes importing more complicated - why should the importer support both CW and CCW? I get the feeling that people just want to use the data from the file with no preprocessing whatsoever (see also: supposed inability to interpolate colors in the current format) - I don't think that's the way to go. The file format can't just have the right values for everybody - or we'd also need an options for radians instead of degrees and so on. The second part of my post basically rendered the first part of my post invalid. I agree with you that it doesn't matter since we'll have to process the xml before using the data anyways. I probably didn't get that message out in my post but that was what I was trying to say :) Regarding artists. They're constantly told to deliver art/content in specific formats. e.g. Make sure to save in PNG with 32 bit colours non interlaced and with power-of-two or don't use more than x000 triangles in your model (and remember to triangulate your model) and z-axis must be up etc etc. Point is that artists are constantly instructed by programmers what format they have to deliver their content in. If they had to toggle an option on/off at export it wouldn't be the worst thing for an artists. At least is not something that obstructs the artist's creative process. But just to be clear I don't wan't a toggle button for counter vs clockwise ;)

I was having the same thoughts and preferred counter-clockwise since the engines I work with use Cartesian coordinates. However the best solution may be to add some settings tag/attribute at the beginning indicating if angels are meant to be read counter-clockwise or clockwise. The artist (instructed by the programmer) can simply toggle a checkbox when saving to indicate clockwise or counter. On the other hand I guess we'll all do some processing when reading the files and saving them into data structures. During that phase we'll just have to convert the angles (and possibly everything else) if they don't fit the format we need.

IMO this is not necessary. If you or your team needs all files to be packed up in zip files (or other archive files) it shouldn't be hard to do so self. But of course I won't mind if it is just added as an extra feature in Spriter. Personally I don't need this feature.

Ok two more things: Personally I don't like this. AFAIK XML readers are not required to read xml in sequential order. Though more verbose I would prefer if each sprite has a layer/z index. Will you provide a DTD document when the spec is finalised?

Ok, I'll start by admitting that I haven't tried the Spriter Beta out yet so just keep that in mind if I write something stupid ;) [*:pranpjm6]As I understand all the animations are saved under each entity. Has there been done any thoughts on sharing animation between different entities? It would be nice if an animator could create an animation library with e.g. different walk cycles (of course these animations would only work for a specific skeleton/ sprite structure) which can then be assigned to each walking entity. As I see it now those animations would have to be duplicated and saved local for each entity wasting memory and time. [*:pranpjm6]I'll like to suggest an optional attribute in the tag. A "colormode" attribute defaulting to "multiply" describing how the "color" attribute is used. [*:pranpjm6]I agree with the previous posts. "Width" and "Height" are scale attributes and should be allowed to be greater than 1.00000. [*:pranpjm6]For the "Opacity" (which could also be named "alpha") I would prefer if its range was [0.00000, 1.00000]. This prevents an unnecessary division for many libraries/frameworks where the alpha value would be represented in the beforementioned range. If a value between [0.00000, 100.00000] is needed a multiplication is at least cheaper to do than a division. [*:pranpjm6]I believe it would be better to split the "color" attribute into rgb values. Most/All graphics libraries/frameworks accept colour values in rgb but not all accept integer colour values. Using rgb attributes saves some calculations. Furthermore I suggest using the range [0.00000, 1.00000] for rgb values. If you're using rgb values it would also make sense to rename "Opacity" to "alpha" or "a". [*:pranpjm6]I think I would prefer the more mathmatically counterclockwise for angle direction. [*:pranpjm6]Will there be an attribute or tag describing interpolation between key frames? I'm thinking what kind of interpolation will be used? This is what comes to my mind right now. I'll just like to say that Spriter sounds interesting and I hope it can become a great and general useful animation tool for games.