scml documentation (deprecated - use reference implementations instead)

[lucid]

Yes.  We are working on the updated documentation now.

[loudo]

Hello there,

 

what is the current status of the documentation?

 

I would like to add subentities in my engine but I'm afraid that without the updated documentation it will be really painful.

So, I hope you can help! Thanks.

[K1978]

I'm also interested in this. From an outsiders perspective, who has followed the product but have not found time to use it yet I am worried that the direction of Spriter is:

• Create new cool feature after cool feature in the editor and thus the format
• Add those features to the supported libraries

There does not seem to be a focus on documenting it properly or creating this reference implementation which has been menitoned previously. I personally want to use Spriter with Haxe + OpenFL, one of the platforms that are not officially supported. There seems to be a few attempts out there to implement Spriter support for that platform, but it is uncertain how far they've come and how well they will support it in the future, For me as a single developer using an unsupported platform I would like this priority:

• Create a new feature for the editor and the format
• Update the reference implementation and the format documentation on how
  • to implement the feature in your custom library, tips etc
  • skip implementation of the feature. If it is a feature that you don't really need. I guess certain features are a must as a lot of other things rely on them, while others are easier to skip to keep the Spriter implementation complexity from getting too big. The focus of your users are to create a game or other application using your editor and format as one piece of the puzzle, not on spending all their time on keeping up with the Spriter format

If we don't see more of this mindset Spriter will soon be impossible to use for any of the implementations that has not been written by the Spriter team. I'm a pretty experienced programmer but implementing an undocumented format which reaks of features I don't need is something I don't have time for. It's much more fun creating a game. I've bought Spriter Pro but for these reasons I've not begun using it yet, but I would like too, and soon. But I don't want my tool choice of Spriter to force my hand at choosing a specific technology.

[Mike at BrashMonkey]

welcome, K1978,

 

You'll be happy to hear that a fully featured reference implementation in c++ is exactly our focus currently and until its finished. It's Edgar's (Spriter's programmer) top priority. Until it's finished only quick bug-fix builds with simple feature improvements will released periodically based on feedback and bug reports.  This has been the case for a while now, but we;re really taking the time to make sure this reference implementation is thorough and future-proof for up coming features (will only require minor additions and tweaks, and not re-writes to support any up-coming features)

 

cheers,
Mike at BrashMonkey

[Dengar]

Out of curiosity, since I find myself fiddling with the Spriter API for Spriter2Unity, is the link in the first post still valid/recent and the whole thing to work with? Just curious and making sure.

[Mike at BrashMonkey]

Hi Dengar,

 

It is, indeed. Despite being old and missing some information, it is nevertheless accurate (minus some typos, etc.) and current... just incomplete.  It's definitely safe to use as a guide, but I recommend you contact Edgar (lucid@brashmonkey.com) if anything seems missing or unclear.

 

The goal for the reference implementation Edgar is working on is to be complete, always up to date with the latest features, and for it to basically make porting Spriter support as quick and easy as possible.  It will also offer a lot more flexibility within several of Spriter's current features. but that's all I can say about it until its out.

 

Cheers,
Mike at BrashMonkey

[Dengar]

Thanks for the swift answer. I know enough for now, but I'll keep that in mind. Thanks.

[cedega]

I've been writing Spriter integration into my own engine, and I think I've discovered and solved an error in the reference.

The issue lies in the applying of a parent's transform onto child bones:

SpatialInfo unmapFromParent(SpatialInfo parentInfo)

 

The current implementation of this function doesn't support non-uniform scaling values, and doesn't support the "flipping" of sprites via a negative scaling. I've found a fix on this forum for the latter, but the former I couldn't find any solution for. I've managed to solve the issue myself, so I would recommend anyone implementing the reference to use this version instead:

 

SpatialInfo unmapFromParent(SpatialInfo parentInfo)
{
    SpatialInfo unmappedObj = this;

    if (parentInfo.scaleX * parentInfo.scaleY < 0)
    {
        unmappedObj.angle = (360 - unmappedObj.angle) + parentInfo.angle;
    }
    else
    {
        unmappedObj.angle = unmappedObj.angle + parentInfo.angle;
    }

    unmappedObj.scaleX *= parentInfo.scaleX;
    unmappedObj.scaleY *= parentInfo.scaleY;
    unmappedObj.a *= parentInfo.a;

    if (x != 0 || y != 0)
    {
        // Negate angle if the sprite is "flipped"
        float angle = parentInfo.scaleX * parentInfo.scaleY < 0 ? -parentInfo.angle : parentInfo.angle;                                          
        float s = sin(toRadians(angle));
        float c = cos(toRadians(angle));

        unmappedObj.x = parentInfo.scaleX * ((x * c) - (y * s));
        unmappedObj.y = parentInfo.scaleY * ((x * s) + (y * c));

        unmappedObj.x += parentInfo.x;
        unmappedObj.y += parentInfo.y;
    }
    else 
    {
        // Mandatory optimization for future features           
        unmappedObj.x = parentInfo.x;
        unmappedObj.y = parentInfo.y;
    }

    return unmappedObj;
}

 

Hope this saves someone a lot of time and frustration.

 

This solution sadly doesn't preserve the Sprite structure when rotating and using non-uniform scaling at the same time. However, I've tested every other case and it works. I would imagine a perfect solution would scale the root bone around the axis of rotation, and leave the rest of the child rotations untouched, but I haven't gotten it to work yet.