Jump to content

Candidate for final file format.Feedback and requests.(Rev1)


lucid

Recommended Posts

Developers, this discussion has moved to a new topic:

viewtopic.php?f=2&t=545

image and SCML file below updated to reflect suggestions made by developers:

Revision 1: 5/12/12 6:04PM EDT

Hello everyone,

Over the past two weeks I've been designing the candidate for the 1.0 version of Spriter's file format. Today I'm presenting it to the community of developers as an initial proposal. I request your participation so you can help shape the file format you'll be using, and ensure it's something you'll enjoy working with.

The format as it's presented here is meant to be able to grow with Spriter. Down the line when new features are added, such as procedural animation or deformation, it should be possible to make these additions without affecting anything else in the file format. Another primary goal of this design was to allow for many different styles of animation with minimal effect on implementation and the format itself. These are the two main goals that decided the overall structure of the format.

As of now, the full version of this specification will allow for the following features: sprites, collision boxes, action points, variables, sound effect triggering, character maps, tweening, bones, sub-entities(containers and subanimations), user mods, and spritesheets. Though each individual feature is very straightforward, the entirety of all those features would probably be overwhelming in one dose. Today we'll just be looking at the features that were available in the beta, and the differences in the way they're handled in the new version of SCML.

The following is a grid visualization of the downloadable .SCML(XML) version of the format description. Certain items have a default value. In the visualization and the SCML download, default values are indicated as the value corresponding to the attribute or element. The value will be displayed at the precision it will occur in the file. For example x="0.00000" indicates that 'x' is a float with 5 digits of precision with the default value of 0.0. If an item is of this default value, that attribute or element simply won't appear in the file at all. This is meant to save space and avoid checking values just to confirm they don't need to be used. (Anything in parenthesis) is not part of the default value, but an explanation of that value.

spritesonly.png

Basics

    [*:119cxisc]For now, just think of an as a complete character. There can be any number of s per file.
    [*:119cxisc]Each can contain any number of s.
    [*:119cxisc]Each has exactly one (main timeline). This has to do with tweening, and will make sense once that part of the format is presented.
    [*:119cxisc]The can have any number of s.
    [*:119cxisc]Each can have any number of sprites, whose drawing order is the order they appear in the key.

If you implemented the beta version of SCML, you'll notice quite a bit has changed. Aside from the feedback I got, the beta format's basic design was mostly legacy from the way the old version of Spriter worked. There are some of the differences:

    [*:119cxisc]Elements that can occur more than once have an value. It is an integer unique to that instance of that item at that depth.
    [*:119cxisc]Each does not show the duration that key should remain on screen. It shows the time in milliseconds that the key occurs in the animation. Example: If there was a 1 second animation with 4 evenly spaced keys in it. The beta format would give each key a 'duration' of 250. In this version each key would have a time within the 1000 millisecond animation, and the keys' 'time's would be 0,250,500,750.
    [*:119cxisc]Frames are no longer listed separately from the animation and referenced from keyframes. The key itself contains the information needed to display the frame.
    [*:119cxisc]Width and height('w' and 'h') are no longer pixel size values, they are ratios to the original size of the image. For instance, if an image is 50 pixels wide, and the 'w' value is 1.0 it should be displayed at 50 pixels wide, if w="0.5" it should be 25 pixels wide, etc.

Please post your thoughts on what's explained above, ask questions, give suggestions, and post feedback before we move on to the other parts of the format. Thanks everyone.

Link to comment
Share on other sites

Hey, nice file format! Will require a rewrite of my structure for sure, but it's nice haha :D

I'd like something to be added: a parameter width and a parameter height on the elements. This would be the pre-calculated dimensions of each key, with all the sprites inside it, with their scale and rotations in mind. This would help enormously if we're using a cached blitting technique in our renderers, as we won't have to determine those dimensions in-game, which would be a waste of resources.

Also, I'm not sure, but I'm assuming the folders is all the images used in the spriter right? How do they work exactly? Also, I don't think the image width and height is needed, we can retrieve this from the code easily anyway.

One last suggestion. The frame w and h properties are a bit confusing. Right now, I'd name them scaleX and scaleY (or sx and sy for short...), because it's what they represent, the scale, instead of width and height.

Thanks!

Abel.

Link to comment
Share on other sites

Image data -> the width and height: are these handy as default width/height for the sprite data (where w and h are ratios)? The width/height perhaps optional; if left out then their values defaults to the widht/height of the image file.

Could be handy to have it somewhere, to use it to position the sprite correctly. And you're given the option to overwrite the width/height at this level.

Just a suggestion! I'm fine with the best solution, advice and your experience :-)

@abel: scaleX and scaleY: could suggestion!

Best regards,

Ronald

Link to comment
Share on other sites

One last suggestion. The frame w and h properties are a bit confusing. Right now, I'd name them scaleX and scaleY (or sx and sy for short...), because it's what they represent, the scale, instead of width and height.

Agreed. And why can't they be bigger than 1?

How would nested folders work? Would the folder name be something like "outer folder/inner folder"?

Link to comment
Share on other sites

The animation key doesn't seem to have any curve data. Does that mean that it's going to export one key per frame or that only linear tween is possible?

If it's the first case then the Key doesn't really need the time.

If it's the second.... well, I hope it's not.

Link to comment
Share on other sites

The programmer in me thinks that it would be nicer to use guids for ids rather than integers. That would avoid conflicting id references between files -- like when merging two files together programmatically, inserting elements like key elements, parsing the document into a dictionary, or just searching the document. With that, I think it would make sense for element to reference folder id and image name, since ids would always be unique, but names would only be unique within a folder context.

The programmer in me also thinks that rather than storing x,y,sx,sy,r, store the first six elements of a 3x3 2d transformation matrix -- where the last three elements are assumed to be 0,0,1. Though, the tradeoff would be that it would make it less human readable, but I think its a worthwhile tradeoff, and support for skews would be a pleasant plus.

Lastly, I kinda feel like the should be a reference -- like images -- rather than a hard coded value per frame. But, that more of a feeling than having a real rational objective...

Those are my initial thoughts anyway, and these are just suggestions that cater to my programmer side. My artistic side thinks the format is structurally sufficient.

Link to comment
Share on other sites

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 ;)


  1. [*: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.

Link to comment
Share on other sites

Personally I would prefer the color be separated into RGB values because most times with color I am using a function like glColor3f, a Direct3D macro like D3DCOLOR_ARGB, or editing a tint color for a material in the Unity editor that already has them in that format.

Although those examples use different scales I would think using normalized floats for the RGB values and the Opacity would help make things more consistent. This way scaling, color, and opacity would all be 0.0 -1.0 values. I was tempted to say that for angle but it's just easier to work with when it's 0-360.

Link to comment
Share on other sites

I think the file format looks good, though I do understand the concerns that others have expressed. I was curious if you guys were planning on supporting a compressed version of the file format for loading reasons when releasing a game using Spriter. I know that in this modern age, that load times for 2D games are not a common concern, but it would help a lot when loading a bunch of spriter elements on underpowered devices like phones and handhelds.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

I'd strongly suggest that color becomes r, g and b. Otherwise trying to tween color between two values breaks nastily.

That depends on the implementation. Internally I'd definitely store it as separate r, g, b values, but as far as the format goes... Well, I don't see any advantages to using a single number but its certainly possible.

Link to comment
Share on other sites

From an animators point of view, I'd vote against limiting the scale between 0.0 and 1.0... Effects like squashing and stretching kind of require the ability to scale an object over its boundaries, distortions be damned.

Also +1 for setting alpha between 0.0 and 1.0.

Link to comment
Share on other sites

sorry for the hugely long reply, I hadn't expected so many replies so quickly, I'll try to check back here more often for this review process, so there isn't as long as a reply needed next time. I was going to split this into many posts, but in the interest of...not doing that...just please excuse this one TL;DR reply if you want my responses to what you or anyone else said so far

I'd like something to be added: a parameter width and a parameter height on the elements. This would be the pre-calculated dimensions of each key, with all the sprites inside it, with their scale and rotations in mind. This would help enormously if we're using a cached blitting technique in our renderers, as we won't have to determine those dimensions in-game, which would be a waste of resources.

good idea

Also, I'm not sure, but I'm assuming the folders is all the images used in the spriter right? How do they work exactly? Also, I don't think the image width and height is needed, we can retrieve this from the code easily anyway.

also easy to retrieve in any gfx libraries I've used. if others agree, I'm fine excluding these

One last suggestion. The frame w and h properties are a bit confusing. Right now, I'd name them scaleX and scaleY (or sx and sy for short...), because it's what they represent, the scale, instead of width and height.

agreed

Image data -> the width and height: are these handy as default width/height for the sprite data (where w and h are ratios)? The width/height perhaps optional; if left out then their values defaults to the widht/height of the image file.

Could be handy to have it somewhere, to use it to position the sprite correctly. And you're given the option to overwrite the width/height at this level.

you can able to change width and height per keyframe, if that's what you mean. The default for xscale and yscale(w and h) will be 1.0, meaning if they don't appear, you use the images' default size

Agreed. And why can't [width and height ratio] be bigger than 1?

oops. just a typo. definitely will allow larger than 1, and less than 0 values for x-axis-flipped images

How would nested folders work? Would the folder name be something like "outer folder/inner folder"?

as of now, I've avoided the possibility of nested folders, though it's not something that definitely has to be excluded. The reason for this is the way character maps will work(which will be explained soon), and also to make it simple for folder to refer to 'spritesheet', and each image be a texture in the atlus

The animation key doesn't seem to have any curve data. Does that mean that it's going to export one key per frame or that only linear tween is possible?

If it's the first case then the Key doesn't really need the time.

If it's the second.... well, I hope it's not.

just wanted to start off this review process with the bare minimum. Everything you see here would be read by Spriter and implementations as containing No tweening, not even linear. The full version of the format which we'll review once everyone's happy at this level, will contain the possibility for the following curves: instant(like now, no tweening), linear, quadratic, and cubic. It will be easy to expand to higher order curves as well, but those options allow for ease-in, ease-out, and ease-in-and-out. I personally would prefer to use additional keys rather than have any more control over the curve speed at that point, but this is definitely open for discussion. Also, if you're curious, the control points for the curves will be defined as sliding numerical values, so it's not just ease-in or not, you will have control over the exact acceleration/deceleration

Will it be possible to have a JSON format?

possibly in the future, but in the interest of making it easy for artists to sell art packs, and know they'll work for everyone everywhere, and to speed up the adoption process, and make universal support as quick and painless as possible I think we should focus on one version of the format until it becomes very widespread. There are many free webbased XML to JSON converters online(seriously, there's alot), and if a particular target platform will work much better with JSON, I encourage those developers to support that, and just let the users know to convert to JSON

I really think that the file attribute under the sprite node should be called image, or vice versa (image changed to file under the folder node) to keep consistency...or am I missing something?
that does make sense, and we can do it that way. the logic behind it though, was when other things come into play like sound effects, and a more advanced feature sub-entities, those key entries would all use the same 'folder'/'file'.
The programmer in me thinks that it would be nicer to use guids for ids rather than integers. That would avoid conflicting id references between files -- like when merging two files together programmatically, inserting elements like key elements, parsing the document into a dictionary, or just searching the document. With that, I think it would make sense for element to reference folder id and image name, since ids would always be unique, but names would only be unique within a folder context.

interesting. There's a few additional concerns that enter when character maps are introduced, and I'd be interested to hear your thoughts once those factors apply

The programmer in me also thinks that rather than storing x,y,sx,sy,r, store the first six elements of a 3x3 2d transformation matrix -- where the last three elements are assumed to be 0,0,1. Though, the tradeoff would be that it would make it less human readable, but I think its a worthwhile tradeoff, and support for skews would be a pleasant plus.

If many agree with you about the transformation matrix, I'll be more than happy, but personally, I strongly prefer the human readable separation of x,y,etc. Aside from my personal preference, I think developers creating implementations for game authoring tools, rather than libraries and apis, will usually have alot of extra work to do to convert a matrix to useable values, whereas programmers working in DX, opengl, etc can easily convert to a matrix
Lastly, I kinda feel like the should be a reference -- like images -- rather than a hard coded value per frame. But, that more of a feeling than having a real rational objective....
Hmm...Again give me your thoughts once we expand to show tweening, as colors will also be tweenable, I'd be interested in your thoughts when you see how tweening will be handle in the format

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.

yes, stay tuned for Character Maps in the expanded description
I'll like to suggest an optional attribute in the tag. A "colormode" attribute defaulting to "multiply" describing how the "color" attribute is used.
this should be doable
I agree with the previous posts. "Width" and "Height" are scale attributes and should be allowed to be greater than 1.00000.
yup, just a mistake, above 1, and below 0 will both be supported
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.
I agree with all of this, though probably 'a' instead of 'alpha' you say below. If no one else has a problem with it, I would prefer this method as well.
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".
Again, I personally prefer this method, unless anyone objects
I think I would prefer the more mathmatically counterclockwise for angle direction.
this, let's wait and hear more opinions. The beta format used counterclockwise, and there was a bit of confusion/requests to change it. I hope a few people will weigh in, so we can choose by popular vote. Obviously, either way is very simple to implement Spriter side
Will there be an attribute or tag describing interpolation between key frames? I'm thinking what kind of interpolation will be used?
yes, see the response to the other interpolation question above
Personally I would prefer the color be separated into RGB values because most times with color I am using a function like glColor3f, a Direct3D macro like D3DCOLOR_ARGB, or editing a tint color for a material in the Unity editor that already has them in that format.

Although those examples use different scales I would think using normalized floats for the RGB values and the Opacity would help make things more consistent. This way scaling, color, and opacity would all be 0.0 -1.0 values. I was tempted to say that for angle but it's just easier to work with when it's 0-360.

I responded above to RGB(I agree), and I also agree angle should stay 0-360
I think the file format looks good, though I do understand the concerns that others have expressed. I was curious if you guys were planning on supporting a compressed version of the file format for loading reasons when releasing a game using Spriter. I know that in this modern age, that load times for 2D games are not a common concern, but it would help a lot when loading a bunch of spriter elements on underpowered devices like phones and handhelds.
possibly, and if we do, the compressed format will also be created through a similar review process. However, we definitely want to stick with one format for now, until it's more widely adopted however, the format will never become a standard if there are too many flavors starting out

The start of the file

Consider having sure thing

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.

version info was definitely planned. The generator tag is a good idea, too

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

another good idea
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.

the array thing, yes. the id's will simply be array indexes in most cases. the other devs can weigh in as well, but personally, I don't like 1 indexing. 0 indexed is most universal for programming, at least for the platforms/languages I've had experience in, and there's certain mathematical tricks that just don't work without 0 indexing. but again, this isn't set in stone, so if the majority agrees, I have no problem with that

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.

right, it will always use the lowest unused integer(starting at 0)

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.

hmmm...interesting. Well we can discuss this further as we look at more of the format. There's a few other things that need to be decided with IDs as more of the format comes into play. For the most part, with what's been presented here so far, you can see the IDs aren't really needed much yet

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?

agreed. typo again. I thought I had corrected that already

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)

sounds good, though the opposite might be better (instead of the 'image' attribute, it could be the 'file' attribute), as it will make it more consistent with other elements we will discuss in the expanded format review
Key

Will the first key always have time="0", and will subsequent keys be in ascending time order?

yes. we can make that the default value so there isn't a wasted time="0" for every first key

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.

k, that's +2 for counterclockwise

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.

definitely. the 1.0 limit was just a typo, got a little overzealous copy pasting the 0.0 - 1.0 range

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.
I agree, this will make it more simple for me as well

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

See the note above, about considering not supporting nested folders. If we do, however, another possibility is actually nesting the tag itself?

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".

sounds good to me, anyone else have any thoughts on having the attribute as a separate
I don't see any particular need for the image width and height.
+3 for not needing that

Thanks everyone...please keep up the great participation

Link to comment
Share on other sites

Ok two more things:

Each can have any number of sprites, whose drawing order is the order they appear in the key.

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This looks good to me, and a little more straightforward than the beta format.

I think the "angle" field needs some kind of annotation to help the runtime determine which direction to rotate when interpolating keys. The simplest method would probably be to just let the angles keep whatever value the animator gives them (that is, less than 0 or more than 360 would be fine).

For instance, assume that the .scml has neighboring keys where the angles are 5 and 355. If I know the angles are always 0-360, I can't tell if the "right thing" is to rotate the short way (subtract 10 degrees over the time between keys) or the longer way (add 350 degrees). If the angles can be outside of 0-360, I just interpolate from the first number to the second and use the resulting angle.

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...