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

[lucid]

everyone: Original Post updated with first revision based on feedback so far

RE: tweening. the first expanded candidate will cover the tweening. It takes zorder, direction of rotation, and many other things into consideration. Pivot Point info for images will also be covered. This first release was meant to only focus on what was available in the beta format release to let devs focus on what's been changed. I'll be releasing an expanded candidate after we're all generally satisfied as to what's here now.

izb: the folders system will work for developers as well, folders don't have to mean physical folders, and will be useful for character maps, spritesheets, and user modding, but if there is anything truly useless at gametime, I'm totally fine with having a game export option that just strips off the extra info. We'll go into greater detail in the near future.

as far as frames vs time, I'm not completely against doing things by frames if others agree, but personally, I like the idea of being able to stuff more details in animation only truly revealed when played back in slow motion. With frames, you would be stuck with the slightly awkward situation of very high frame numbers and very slow playback speed for any animation that had this type of detail. Of course this won't matter much implementation side, the awkwardness would come in for the artist and animator

[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?

[timpart]

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

[lucid]

right, in my own experience, there's is usually a variable framerate depending on the system's ability to keep up, and advancing time is tracked - and gameplay/animation determined by a delta time value which reflects how much time has passed since the previous gameloop tick. So when the system is taxed, the animation and gameplay won't slow down, but instead become choppier, so the game runs at the same speed on slow and fast systems. This logic will become a little convoluted implementationside with the addition of frame numbers and framerate I think.

edit: izb, spriter doesn't have an internal framecount. Each key has it's time value. The other issue with frames, is that the artist will still be limited by the distance between frames, so if they decided to change to a more detailed animation style, there would have to be a recalculation to make a higher frame density, resulting in altered snapping on the timeline

[mrwonko]

...

I agree with keeping Spriter-related metadata and animation-related data separate. They can share the same file, but the former is irrelevant to the game.

[32bitkid]

I think the real question about rotation being clockwise or counter/anti-clockwise can really only be answered by talking about the y axis. Is a positive up system (traditional cartesian plane) or a positive down (bitmap/screen coordinates)? If its the former then counter-clockwise is my vote. If its the latter, then clockwise is my vote. For what its worth.

And I think a non frame-based animation system is a fantastic and I like that its manifested as such in the file format.

[Trumgottist]

This would mean a simple list of images with full paths.

Maybe I'm misunderstanding you, but I don't like the idea of full paths. That would create problems for those of us who work on the same project on different computers. In my case also different operating systems, so an image path "C:\myGame\man.png" isn't even legal on my Mac. Any path must be relative to the file.

I also don't like the idea of stripping the file of information - it's not as if it'll add any significant size and it's good to have if you're sharing resources or whatever. If you want to get rid of stuff, you can always do that in an importer for your game engine.

EDIT: See VictorT's post below for what I was trying to say. ;)

[VictorT]

I completely disagree with the idea that Spriter-specific data needs to be kept out of the .SCML format. If you do split the files up, you are likely to run into trouble in a few places:

- It's harder to keep files updated in version control ("I just updated an animation. Which files do I need to check in?")

- Generating Spriter scenes from other tools gets harder when you need to write multiple files to the right places.

- Whatever data you DON'T put into the export format, I guarantee that someone will want it back in later on.

Completely aside from those concerns, I think it's safe to assume that anyone who is severely performance- or memory-limited will compile the .SCML format into smaller and faster runtime data. Because of this, it's not terribly important whether or not there's extra data in the file.

[mrwonko]

This would mean a simple list of images with full paths.

Maybe I'm misunderstanding you, but I don't like the idea of full paths. That would create problems for those of us who work on the same project on different computers. In my case also different operating systems, so an image path "C:\myGame\man.png" isn't even legal on my Mac. Any path must be relative to the file.

I think you misunderstood him - he was talking about complete relative paths, as opposed to storing filename and relative directory names separately.

i.e. path="some/folder/file" vs. dir="some/folder", file="file"

I see why keeping all spriter data in one file makes sense. It might still be good to have different sub sections with separate version numbers so importers using only a subset of the data can know they still work properly when other parts of the file change.

[pstudio]

I think the real question about rotation being clockwise or counter/anti-clockwise can really only be answered by talking about the y axis. Is a positive up system (traditional cartesian plane) or a positive down (bitmap/screen coordinates)? If its the former then counter-clockwise is my vote. If its the latter, then clockwise is my vote. For what its worth.

And I think a non frame-based animation system is a fantastic and I like that its manifested as such in the file format.

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.

[Thinksquirrel]

I think for the most part things look good.

Sorry for the wall of text, but I have a few concerns.

1:

I agree with the above comments with regard to the folder structure. I'm not sure why folders would need to be important for the data format. The folders themselves don't seem to provide any information at all, other than that they are folders and what their name is - something which is very easy to figure out from a path string. It seems to add more unnecessary complexity compared to just specifying file paths with the standard separator "/". The keyframes could just reference a file ID.

An example as to why this isn't the best idea:

Let's say I have a script that I run on my SCML files as part of my import process into my engine. This script changes goes to all of the files, places them in a path Art/_____.png , without any folder structure intact. It then changes the references in the SCML. Say this import process is because my engine doesn't support any subfolders for art assets, and art has to be in a specific folder.

If you introduce folders now instead of just paths, this import process just isn't easily done. The underlying engine needs to either conform to the SCML standard for no important reason, or the SCML needs to have a fairly significant rewrite on import to fix broken folder references. If there are just references to file paths, it's quite trivial to just change those as part of an import process.

2:

I understand that tweening isn't supported fully in this format, but there is still the issue of enabling and disabling an sprite:

If you have a moving sprite in one keyframe, and then not in the next keyframe (implying that it has been disabled), there is no way to tween the position from one frame to the next, and it will stop moving between the two frames. This causes a jitter effect, which is very noticeable if the spacing between keyframes is large.

To solve this, each sprite in a keyframe should have an enabled/disabled toggle. That way, that sprite can still have position information to tween for the next frame, but can be disabled once it reaches that position. It wouldn't be required that every frame has every sprite; sprites that don't change from a disabled state would still not be present.

For a real-world example: I have an in-development linear tweening mode in this demo using Unity - the issue can be seen here in the walking animation if you slow down the time.

http://dl.dropbox.com/u/33426743/Sprite ... Unity.html

The candidate format still doesn't solve this issue. Everything else seems set to support tweening (happy to see z-index got in there as well).

Overall, good stuff! The format seems pretty extensible (for example, keys could a to go along with the sprites).

[lucid]

Hello everyone. Last check in for today. Tomorrow, I'll post some more format info including tweening and probably character maps, since most of the remaining concerns have considerations and explanations rooted in character maps and tweening. Best to leave this as is at least over night before releasing the next batch of info to allow the rest of the time zones to check their email and weigh in on this thread.

I definitely don't mind keeping the path as one long string if that's still the consensus after I reveal character maps, but at least you'll be able to see there is logical reason why they were separated in the first place.

Also with tweening, to make things at least slightly more clear until I release the description with tweening, tweened objects will use different element/attribute structures than untweened objects, so if it looks like the current format can't possibly support it, that's because none of the element structures used in tweening are included in this limited description. I'll explain it all tomorrow.

Till then good night everyone, and please continue to give feedback. Interested parties will find an expanded format description tomorrow - most likely in a new thread to avoid this becoming 18 pages of confusion.

Thanks everyone

[Tap]

One thing I would like to do is replace a piece of a sprite (a weapon for example) with another sprite piece. Each image could be a different size, too. Is that possible using this format? I used to do similar things in the Flash IDE by placing each image on its own keyframe in a movieclip.

[mrwonko]

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.

I don't think that's a good idea.

1. [*:3v1pg2nq]It's something the artist shouldn't have to worry about.
   [*:3v1pg2nq]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.

[djkat]

I have a few questions, maybe you plan on addressing these things later but I would like to at least mention them:

1. Will you be able to use atlas animation (changing the sub-frame of a sprite over time).

2. If the answer to 1 is yes then will tweening be possible? (blend between frames)

3. Please consider adding blend modes for sprites (for source and destination).

4. Will the format support dummy nodes (useful for attaching particle effects etc)?

These are important 1.0 features in my case and I would not be able to use the editor without them. :)

Cheers,

Daniel

[djkat]

One more thing, the format does not seem to specify the "hotspot" of an image around which rotation, scaling and movement is performed? Is it implied that it is always the center of the image?

[Trumgottist]

I don't think that's a good idea.

1. [*:2ula6szi]It's something the artist shouldn't have to worry about.
   [*:2ula6szi]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.

I agree! Adding a toggle would just make things more complicated for everyone. I suppose someone may have use for that in the interface, but it doesn't belong in the file format.

[pstudio]

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.

I don't think that's a good idea.

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

[charlieman]

4. Will the format support dummy nodes (useful for attaching particle effects etc)?

+1, this will also help for attaching other sprites, like weapons, on the character.

I also like the idea of separating Spriter and SCML data with namespaces in the same file.

How does the version in the document_info part work? Will the animator have to increase it manually or will it be automatic? What about a last_modified attribute with a timestamp as well/instead?

About rotation and the y axis I think they should be CCW and positive up, the conversion to each platform should be left to the xml loader. Maybe we should add a poll? :D

[timpart]

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

[lucid]

for those currently browsing the forum

just a heads up, expect the post in the next hour or so. Just have to upload the files and type of the description.

again, will cover pivot points, tweening, and character maps

also going to poll the whole y up or down/cw ccw issue

it's definitely easy to use either one with a simple '*(-1)' either spriter side or implementation side, but I'm interested to know the majority anyway

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

[lucid]

pstudio, we want to avoid any situation where there are options like that for export. The idea is to have one file format where everything works everywhere. It would be simple to simulate the second option by simply tweening from red to yellow, and then yellow to green afterward:

Everyone, as a fresh start to avoid covering the same ground, and letting new people coming in skip this discussion, we're moving to this thread for the expanded/revised candidate:

http://www.brashmonkey.com/forum/viewtopic.php?f=2&t=545