GameMaker: Studio 1.3 and Spine

Vohjiin

I thought I would go ahead and put a topic up in regards to GM:S and Spine. With version 1.3, GameMaker now supports (Officially) loading Spine .JSON files and as such our project moved over to using Spine animations directly. Here I thought would be a good place to put some pointers in using both software's in combination and the little things we have noticed thus far using them.

First off YoYo games put up a techblog regarding Spine and GM:S I'll link here http://yoyogames.com/tech_blog/55 that is a must read, but there is a few pointers worth noting in regards to the current support for Spine not mentioned. If you use the "_ext" functions for setting animations where you can define tracks and play multiple animations at the same time, on the same skeleton, keep in mind the frame counts for your animations. If the 2 animations do not share the same frame count the animation will jitter, twitch, or play just a fraction of the frames in the total animation.

We have found if all the animations contain the same frame count this doesn't happen and probably is related how GM:S handles image_index's within the software. This could be fixed later on and may very well have been hotfixed by now but it's something to keep in mind for now when using animations. Also note when you load the Spine file WAIT for GM:S to finish loading and importing the file. It doesn't tell you but if you watch the debug console you'll see what I mean. Closing the sprite dialog before it is finished has caused for us at least, for the Spine file to not load all the way.

Also if you use multiple tracks the normal draw_sprite functions within GM is not usable, it seems or we may be doing it wrong, it's a process we are working through but I thought I would mention this in-case someone had an answer.

Overall it is going great and looks fantastic so please reply if you are using GM:S with Spine as well since we have just recently started implementation of it I am curious if anyone else has been using it as well and any issues they have noticed.

Some more information to those who are curious:

If you wanted to attach images to the skeleton during runtime you should note that the functions for this, skeleton_attachment_create, skeleton_attachment_set, and skeleton_attachment_get also have a bit of a performance hit. Now under normal circumstances with just a few animations in view this is negligible and not noticeable but if you was planning for many many animations to be on the same screen you may see a slight performance drop.

Also when you define values for an animation you are setting those values for the current object using that animation. There isn't or not that we have seen a global way to define these values for all objects that use the same animation. Now you may be-able to reference a "parent's" values to use with other objects and should save you some code.

Finally the current support for Spine in Game Maker: Studio doesn't support any meshing or FFD and having this information within your animation will cause GM:S to complain the .JSON file is malformed. Disregarding that though, it has been fantastic to use Spine within GM: S and everything looks really great and works wonderfully.

Søren

Thanks a bunch for the heads up on GM:S!
Nate and I are only just finding our places again after A MAZE in Berlin (Nate might actually be traveling at this moment). We're really looking forward to see what the Game Maker community will come up with using Spine 😃

Nate

Good stuff, thanks for sharing!

Vohjiin

Some of the latest updates to Spine seems to have changed how the .atlas is exported and at the moment it causes Gamemaker to report a malformed atlas file. There is what seems a temporary fix for some in the following GMC post: http://gmc.yoyogames.com/index.php?showtopic=622594&hl=.

As stated we have notified YoYo regarding this situation and hopefully see a fix soon for this issue.

Dralger

Thank you so much for posting this Vohjiin !!

I have yet to start trying Spine with GM:S (I'm still messing around with the new SWF import and using Anime Studio Pro to make those) but I have already purchased Spine and fully intend for it to be my main animation tool moving forward (current game is simple and doesn't need intricate animations). After learning what I can do with Spine JSON sprites I don't think I could imagine wanting to do an animation-heavy game without using it.

So your post has definitely been marked for future reference by me !

jayman1000

Vohjiin I want to say I read your post with much interest. However while I have followed everything you pointed out like having same frame count, and not having animations manipulate same bones(even when they do not have same parent bone), I have found that when using more than one track and changing the animation for a track, that animation will jitter, become jumpy, or only play part of the animation. I don't know why but this happens consistently every time I change animation for a track. But I have also found that the closer that the animation in track 0's image_index is to 0 when changing animation for a track the more part of the animation is played. If for example frame count for an animation is 32 and image_index is 16 at the time that I change animation for a track only half of the animation is played immediatly, and for the rest of the 16 frames( or steps) it does not play, than after frame 32, it plays again from frame 1, but still only half of the animation. If done when image_index is 32 that animation basically does not play, because I guess it only plays for that single frame 32. I am very confused why this is so, because if you and others are able to use tracks via the _ext functions I must be doing something wrong. I just don't know what it is. Is there something obvious that what could lead to the described behavior?

Vohjiin

@jayman

From what we have been able to discern regarding this is when you change one track (namely track 0), all other tracks have their frame's adjusted to where the current frame is literally the start of that track and it plays till the end then loops back, resulting in the loss of the first set of frames. For track 0 try avoiding using the _ext functions, for whatever reason multiple tracks work fine as long as track 0 is done not using those functions. For example for our character we have 2 tracks, one for the legs and one for the arms and torso. Track 0 we used for the legs and track 1 we used for the torso area (because we would have this set of bones rotate to mouse position). Now to play animations we had to use something like this:

skeleton_animation_set("Run");
skeleton_animation_set_ext("Attack_Sword",1)

The legs still glitch out on occasion but overall the animations play regardless of when you change the animations on any track. It is important they contain the same frame count or at least multiples of each other (or of at least track 0). Skimming through the bug tracker for GM:S it looks like they are indeed taking suggestions and bug fixes seriously with the Spine implementation so hopefully we should see those soon. (and new functions!)

jayman1000

Vohjiin, thank you for the helpful answer, I will try to follow those guidelines and hopefully soon we will see a GM:S update! 🙂

Scudo

It was a relief to find this thread, because I've been struggling with the exact same issue as jayman and was thinking I was just doing something wrong. Glad to see it's not just me! I'm actually using an animation set that sounds similar to what Vohjiin described (legs for a "Run" animation and then track 1 for "Sword Attack").

I tried those suggestions to make sure they have the same frame count and not to use _ext with the base (very helpful btw) but unfortunately my sword attack still gets clipped short during its animation if the image_index of the base ("Run") rolls over to 0. Here's hoping for GM to address it soon.

jayman1000

@Scudo, last night and today I have tried the suggestions as well and it still won't work, our issues are identical I think. I also have the same frame count and does not use _ext with the base animation. Still the animation is only partly played as I described earlier.

Vohjiin

@Scudo and jayman1000

Have you guys by chance used the " skeleton_animation_mix(); " functions to make the animations interlope smoothly when switching? You set these in the create event and you define All the animations that would transition into each other, which is where I do have a mild complaint. You will have to do this with every object that uses animations, along with all animations, as it is not global which would be a nice option for GM to have using Spine is to interlope ALL animations.

Example would be you have to define interloping between "walk and run" and in reverse "run and walk", then "run and stand", "stand and run", walk and stand", stand and walk"....... You can see really quickly if you have any sizable animations that need to be smooth across the board it is a lot of stuff to define per object. (Parenting is your friend here)....

jayman1000

Vohjin, maybe we are getting away from actual Spine stuff and purely into Game Maker code, but yes, I do use skeleton_animation_mix(); and it works great but only when I am not using several tracks. However I found a small trick which results in something better, although still unacceptable. When changing track on say track 1 I use "skeleton_animation_set_ext(rifleShootAnim,1))", and at the same time I use "skeleton_animation_set(baseAnim)". And in the create event I have set "skeleton_animation_mix(baseAnim, baseAnim, 0.8 )" "skeleton_animation_mix(rifleRunAnim, rifleShootAnim, 0.1)" "skeleton_animation_mix(rifleShootAnim, rifleRunAnim, 0.1)"

This way the rifleShootAnim in track 1 is not cut short because it is in this way synced with the baseAnim. However the baseAnim is reset which is disruptive of course, but due to using skeleton_animation_mix on itself there is some interpolation which makes it seem less noticeable. However it is still visible that the baseanim restarts, it's just not so abrupt and appears less laggy.

Scudo

That's a really clever trick. I can deal with my base run animation being jumpy for now, as long as my attack and block animations play to completion. I'm going to have to use that.

Vohjiin

Just to update everyone, Game Maker: Studio's EA version includes the fixes to Spine files and support for mesh deform!!! I have not tested this out to any extent just yet, but when I can move some animations over and add some mesh deforming to start testing I will post here with my results.

Update:

I have yet to really test the mesh deform (working in that direction :S) but anyone who has been trying to use the attachment system might have found it very difficult to set the origin of the image when it's attached and we have seemed or believe to have figured this one out . By default GM does not use the sprites origin or x and y offset defined in the sprite editor to determine it's position. When you place an image on an attachment point it does so in the exact center of the image, to use the sprites origin from the editor you need to take this into account. Here is a quick simple way to translate the origin you denote in the sprite editor into origin coordinates on attachments:

sprite_get_width (ind) / 2 - sprite_get_xoffset (ind);
sprite_get_yoffset (ind) - sprite_get_height (ind) / 2;

It took a lot of messing around with grid based images / trial and error to figure out the weird way it sets the position for images on attachment points and for those wondering attachment points are defined by "slots" within the Spine software and any rotation/translation applied to the bone that slot is attached to does work in GameMaker so it makes a great way to attach weapons/armor onto skeletons outside of Spine.

Update 2:
While this is getting into more GML then Spine I'll add this small footnote regarding attachment points. Rotation through the attachment_create function will always rotate at the center of the image and NOT it's origin that you define. I want to think there is a minor glitch in GameMaker at the moment regarding the origin and rotation of this but for now it's something you will want to keep in mind if you plan on rotating images through the function.