Jump to content

Spriter for Torque2D


Recommended Posts

Hi Everyone,

Mike at BrashMonkey here.

As some of you might remember, from early on, when it was our intention to have first party plug-ins created for many popular game authoring systems, Torque support was near the top of our list. As we could not afford to hire an engineer outright, we had struck a deal with a skilled programmer who was nice enough to work on Torque2D support for Spriter in his spare time for the extremely modest rates I could manage to pay him out of pocket as well as the promise of a share in the revenue generated from the eventual sales of the pro version of the plug-in.

As mentioned in a previous thread, the amazing speed and enthusiasm with which members of dev communities are creating free and open Spriter support for countless authoring systems proved to us we needed to rethink our pursuit of 1st party plug-ins all together.

To those ends, Mike Ness has generously agreed to share what he'd accomplished so far with the Spriter and Torque communities so anyone interested can contribute to its development and so that full Spriter support can be available for all Torque 2D users as soon as possible!

Now I'm passing this post over to Mike Ness (the engineer) to fill you in on the technical details. Thanks so much Mr. Ness!

---------------

http://www.brashmonkeygames.com/brashmonkey/spriter/T2SpriterDemo.zip

Thanks Mike. The source archive contains a modified copy of the Fish demo that I was using as a test case. The Spriter code is in game/gameScripts and consists of three main files: spriter.cs, spriterData.cs, and spriterEntity.cs.

spriter.cs contains some helper methods to load SCML files, create entities, etc.

spriterData.cs contains the Data class which is responsible for reading and storing the SCML file data.

spriterEntity.cs contains the Entity class which uses the Data class to build an entity and attach it to a scene.

Currently the code only loads the first mainline animation frame and displays them as a set of t2dStaticSprites. No animation is implemented at this stage.

My plan had been to continue developing these torque scripts in order to implement the whole of the Spriter functionality without the need to recompile Torque. Later, I planned to write some C++ classes to take advantage of increase performance when recompiling the engine was appropriate. Integration with TGB was also in the back of my mind, but lower on the priority list. The next obvious step forward with this code would be to implement the animation system.

Feel free to use (or not use) this code however you wish. When I started this project I was new to Torque, so perhaps there are more efficient ways to accomplish the things I've done here--if so, use them! And I look forward to seeing what the community does with this project.

Thanks,

Mike Ness

Link to comment
Share on other sites

Very awesome stuff! I've been eager to get Spriter working with T2D (TGB). Quite impressive is the fact you've managed to get this "in place" without exposing it to the source first. I am definitely motivated by this, and am starting to make strides of my own make this into a full integration. I have high proficiency with Torque, and am knowledgeable with C++. The only part that is somewhat confusing to me is the format's, I do know a bit about it, and hopefully will gain broader understanding as I work through this.

I would really like to do more with this, and I believe integrating into the source code and then exposing to the editor itself would be the best place to go with it. The only part that somewhat concerns me is how the animations will be handled and whether a specific class reference will be enough for Torque. I think that if it was it's own unique element that housed similar information as Static & Animated Sprites it might function.

If anyone else would care to share some knowledge regarding this, it would most likely aid in the implementation. I will be happy to contribute towards this goal.

Link to comment
Share on other sites

Johnny, I have looked into your C++ API, and while it's complete for a generic implementation of C++ and from there to a renderer, Torque already has a lot of what is needed, it's just a matter of adding in the SCML read/interpretation to Torque script that is needed.

I am making progress by using your SCMPpp on one hand, Mike Ness's script on the other hand. All whilest comparing to what is already included in the Torque 2D Engine itself.

The "good" news is, it's not as big of a step as I once thought it might be. As Torque already has xml support, and utilizes tinyxml. I have to work-around the XMLhelper library as the way it's handled is different. I'm looking to add it as a Torque entity of a new type so that user control over it will be easier to maintain. The "trick" so to speak, is linking in the animation, but so long as I gather all the key frames on reading the SCML document I should be able to manage it.

My C++ is a little rusty, but I'm getting along ok for now. It's just sitting down and taking the time to get it right.

I've also been starting to "pool" others from the Torque community for insight in aread I'm not compeletely familiar with (such as extending the editor to allow users "ease of access", but that's really just a nice-ity moreso than a necessity.

Also, just an FYI, I tried implementing your code as whole into Torque, and after a few changes (due to what is there already, and a few minor hooks that I needed to clean up), it came up as a memory sync problem. Which is why the developers created the SimXML functionility in as a workaround. And truth be told, your code is more than what is necessary for Torque implementation.

Link to comment
Share on other sites

  • 3 months later...
  • 2 weeks later...

Yes & no, I have it close to working with T2D MIT, however I am having problems with getting the Sprites to render for some reason. Also, still need to implement the animation hooks as well. In the end, a runtime for T2D would be far better than taking the SCML data and reading through it and implementing off of that... However I don't know what steps that would entail. As soon as I get a finished working version I'll post my git extension of T2D with Spriter support.

Actually I'll post it now, maybe someone here can help figure it out...

https://github.com/Doc308/Torque2D

My setup is based off of the default Sandbox module included in T2D, my actual module for the Spriter is located under modules/SpriterToy

Also, for the record I had to create the .taml files manually for the image assets, and am working on a step around for that (for designers not wanting to have to manually do the step..).

If anyone has question, I'll be happy to answer, or if anyone figures out what might be causing the sprites NOT to show up... well, that would be greatly helpful, I have it hardlined in at the moment, but it's still not working.

Link to comment
Share on other sites

Just to follow up, I have the default monster file working now. I made a silly coding mistake that was pointed out to me, and was able to diagnose a few rendering problems (invert y, and positive vs negative angles). I am going to attempt to get the animation working script wise, but in the end, an engine specific method would probably be more ideal. I just wanted to sort out the kinks before venturing further.

For those unaware, T2D MIT is FREE! It was recently released under a similar license as Torque 3D, and is available from GitHub. You can either go to GarageGames, or use my own forked GitHub repo.

My next step is to setup the animation handler. And probably need to transfer the work to C++ and link it as it's own Asset Type for generation and hook the result back to a console grabbable object for users to control.

If anyone wishes to assist, please feel free. I am happy to help if needed as well, otherwise will push on in my own time.

Link to comment
Share on other sites

Hey everyone. This is Mich, official developer for Torque 2D. I just had a chat with Doc. I'm going to collaborate with him to get an official Spriter implementation ready for the new T2D MIT. Between his experience with Spriter and its data format, and my expertise with Torque 2D, it shouldn't take us long to have a fully functional plugin running.

I'll let Doc continue to post updates, since I'm pretty busy with multiple projects. Just wanted to jump in here real quick to say I'm entering the fray to expedite Spriter support. Cheers!

Link to comment
Share on other sites

Update: Our other official T2D developer and architect genius, Melv May, has now joined the effort. We should have a full implementation in a matter of days. We'll post some videos and guides once we are finished. Additionally, we'll include an example "toy" in the Torque 2D repository that shows how to use this. Couldn't be more excited =)

Link to comment
Share on other sites

Melv had some follow up questions, hopefulyl you can answer, we're trying to meet as much of the specification as possible.

Are bones are the way to go now or are they optional, in which case the older files are obsolete? If you can optionally use bones then that would make the animation slightly more complex.

So in a "a4.1" SCML file I see stuff like this:

So it seems that the "bone_ref" parent refers to a parent bone and an "object_ref" parent refers to a "bone_ref" as well. (?) That would make sense i.e. a bone hierarchy with objects "attached" to bones. So that begs the question then that because each "object_ref" has a parent bone but still refers to a "timeline" and "key", what do you do with those references i.e.:

...

So this "object" is referred to in the first listing as "timeline=10" and "key=0" but the object is parented to a bone_ref of:

...

... so are the x, y, pivot_x, pivot_y, angle & scales local-space from the bone? I can only presume so. What about (as in older versions) when the object is not attached to a bone? Do those become the origin of the composite/character?

For now I'm taking the following assumptions and running with them so just correct me if you know or can find more info:

Bones are optional

Spatial details of a bone are relative to a parent bone

Spatial details of an object are relative to the bone if parented to one else they are relative to the "character" origin.

Link to comment
Share on other sites

Hi Doc, I sent the reply to Kirk Sander on the 22nd. Please let me know if he didn't receive the email, as we've been having issues with our email system lately, but I'll paste my reply here as well:

Hi again,

I’ll answer inline with your questions to make sure I don’t miss anything:

Are bones are the way to go now or are they optional, in which case the older files are obsolete? If you can optionally use bones then that would make the animation slightly more complex.

Completely optional. This is to give the artists/animators maximum flexibility. Some animators and some characters or objects just aren’t suited to bone animation, or there may be a boned character that has a floating object that orbits them, or an assistant creature that should be animated with the character, with it’s own set of bones but not attached to any bone of the character. Forcing the animator to put extra bones in there just to simulate the situation is a hindrance. The easiest way to handle this is to treat the anything without a parent bone as if the character itself is the parent bone. So if the character is at xy 100,20, angled 45 degrees, and scaled 2x on both axes, anything without a parent should be transformed as if it had a parent bone with those properties. Also, doing it this way now will make it very easy to expand the implementation later when we add procedural animation capabilities to Spriter.

So in a "a4.1" SCML file I see stuff like this:

So it seems that the "bone_ref" parent refers to a parent bone and an "object_ref" parent refers to a "bone_ref" as well. (?) That would make sense i.e. a bone hierarchy with objects "attached" to bones. So that begs the question then that because each "object_ref" has a parent bone but still refers to a "timeline" and "key", what do you do with those references i.e.:

...

So this "object" is referred to in the first listing as "timeline=10" and "key=0" but the object is parented to a bone_ref of:

...

... so are the x, y, pivot_x, pivot_y, angle & scales local-space from the bone? I can only presume so. What about (as in older versions) when the object is not attached to a bone? Do those become the origin of the composite/character?

I think I answered this in the above answer, but to make sure, yes, if anything has a parent, the coordinates given in the object are in local space to the parent bone. I should also mention at this point that though it’s undocumented, a ‘spin’ of 0 means it shouldn’t rotate at all, and any difference in angle is a rounding error.

For now I'm taking the following assumptions and running with them so just correct me if you know or can find more info:

Bones are optional (PITA!)

Spatial details of a bone are relative to a parent bone

Spatial details of an object are relative to the bone if parented to one else they are relative to the "character" origin.

All correct, except the ‘PITA!’ part. Just remember that last bullet, if you wish you can even just make an ultimate parent bone that will just always set itself to the character position/angle/etc, and treat it as the parent to all nonparentd objects. Also, make sure that you’re always following the rules from this document: http://www.brashmonkeygames.com/spriter ... 8a2%29.pdf

particularly this part on the last page:

for tweening between timeA and timeB:

“make sure that when you are getting timeA and timeB of your two keys when tweening you are getting it from the 'time' attribute of the referenced in , and not the originating in . “

Also, be sure you’re tweening to the next in that timeline, or to put it another way, once you’re in that timeline/key that the object_ref pointed you to, just tween to the next key, you don’t have to/shouldn’t go back and check the next mainline key. Spriter has a feature that allows the artist to change the skeleton at any time. I believe it’s a first for any animation program. This means that a character can have a hat attached to their head bone, and on a later keyframe to remove the hat, the animator can just change it to be attached to the hand bone. Or if a character is supposed to explode into all it’s constituent parts and float back together in a completely different form, or a character that can grow extra body parts, etc. Basically, anything that is normally completely off limits for bone animation is now very easy for the animator. The beauty of this system is that as long as you follow the above this requires absolutely nothing implementation-side to make it work. Spriter will precalculate and save extra key information into the file that will make it just automatically work with a basic bone implementation without any extra programming or processing power. Also the above rules will allow us to do other types of save file ‘magic’ that will make other future features (like separate keys for angle, position, etc) without you having to change your implementation to support them.

One more thing, the latest version of Spriter will always require all timelines to be named and will assign unique names to each timeline. This doesn’t add any requirements to the implementation, but it does allow you the freedom to add this assumption to your implementation, if you want to give the developer granular control over each body part and bone at runtime. You can now allow them to do this by ‘name’, without worrying about two objects in the same animation being named “”. This could be used for component damage, or allowing body parts to receive clicks, or collisions individually, etc. Within the Spriter interface, if two s in the same have a with the same ‘name’, they are considered the same object being reused for separate animations. Again, this doesn’t add any requirements to the implementation, but it does make it simpler to add granular control features to your implementation if that’s something you’re interested in.

Please feel free to ask any additional questions if needed, and I will do my best to answer as quickly as possible.

regards,

-edgar

Link to comment
Share on other sites

Thank you for the follow up, I didn't get the e-mail, so I thought I would follow up on the forums in case of a hiccup in the system. I appreciate all the feedback, Melv & Mich have been hard at the engine integration, and I've been doing my part by providing as much background knowledge with Spriter as I can offer.

It shouldn't be too far off for implementation, and just a matter of what improvements get made that would tweak the base get put in. Can't wait to see it working! :)

Link to comment
Share on other sites

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.

 Share

  • Recently Browsing   0 members

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