First off, disclaimer--I'm a college student with little game development experience that feels somewhat unqualified to make any suggestions, and some of what I say may be very naive. However I've been getting into 2d game development recently, and I'm really interested in what's been going on here with Spriter.
I took a look at your SMCLpp code and SDL renderer. First I'd just like to say, awesome work and thank you for putting in the time and taking the initiative to do the generic parsing and rendering! It's people like you that make the open source community so enjoyable, so thanks.
First off, I was concerned when I first read the code that the data structure might not be compact enough, but after reading over the spec again, I think I was just confused. Maybe I will try to write some explanation for some newbie developers like me.
In terms of reverse kinematics. All I can think about is Box2d Box2d Box2d..
For such an application, obviously runtime bone control and runtime inverse kinematics are important. The problem though is reverse constraints. How do we handle conflicts between physics and animation bone structure??
I think bone drawing would definitely be helpful. I also really like the idea of access to transform information. If I understand it correctly, this could make rendering in OpenGL more straightforward?? I think a cpp OpenGL-style renderer might be quite popular.
Lastly, I would love to see an open source xml standard for 2d games that connects Spriter animation, box2d objects, and scripting. Do you think this is feasible? I've started to think about how we could connect all these resources, and I thought you would be a good person to consult before I brought the issue to a new topic in the forums.