Jump to content

Final SCML Specification Candidate


lucid

Recommended Posts

Hello everyone,

The upcoming version of Spriter will be here soon. After our last discussion about the file format, I began rewriting the Spriter animation system to incorporate this new design. Using what I learned while implementing it, and everything we discussed, I refined and reworked from the previous spec. This is the final format candidate. I will incorporate or change anything high demand before the upcoming release. Please take a look, and give any feedback or suggestions you have.

In the upcoming release, Spriter will be using a small subset(specifics on release) of the features of this specification. However, at that point the format will have been finalized, and developers will be able to begin to implement the entire feature-set of the format. The editor will catch up to the feature-set throughout the coming months, and of course be fully compliant with the specification.

There will thorough documentation at some point, but for the purposes of this discussion, please review our previous thread linked above to gain a basic understanding, or to refresh your memory. Also, please feel free to ask questions about anything, even if we've covered it.

Click here to view/download a basic guide to the format

Also, one thing I'd like to point out if anyone needs clarification on the license:

it's being released under the Modified BSD License. This means that there are very few limitations on how you use SCML. If you redistribute the format specification document itself, you must retain the copyright notice. You may modify the document as well, but it must retain the copyright notice, and you may not misrepresent Brashmonkey, LLC as being responsible for the modifications. You don't need to display the copyright notice in your game, and you are of course allowed to incorporate support for loading and displaying SCML into any software without our knowledge or permission, for free or for profit.

Looking forward to your input!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Thanks timpart for your sharp eye. I fixed the errors, and updated the file. I agree about the tag/variables in meta_data and that is updated as well. Very busy until launch date in a few days, but I'll elaborate further on the documentation where you mentioned it was vague, and expand on the aspects you were questioning after this upcoming release

Link to comment
Share on other sites

Minor change in the order of things. Moved and information above the information. Everything in will always be needed for "sprite" s within the tag, so anyone wanting to read the file sequentially and build a mirror data structure that refers to this information would have needed to read through the file twice. Also, corrected an omission. The tag was missing the "parent" attribute.

Either on the next release on the 15th or shortly afterward, I'll publish more thorough documentation of the currently implemented(in editor) subset of SCML, as well a sample file.

Link to comment
Share on other sites

  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

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