• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion GMS2 future Spine support plans...

rIKmAN

Member
As a Spine user, I realise GMS1 will not be getting any further updates past the one currently available in the EA, and so with one eye on the future I am obviously looking at GMS2 and have been mulling over whether to purchase it.

If I did, I would also be purchasing the "Mobile" exporter for iOS / Android development when available, so it's a decent chunk of change and not something I can afford to purchase and never use, or have it be unsuitable.

So, currently I'm quite disappointed with the Spine functionality in GMS - even with the newest update that added Events it's still a pretty slim implementation of the Spine Runtimes and all the functionality it offers.

There are about 12-15 skeleton_* commands available to work with and manipulate Spine sprites and animations, which in the overall scheme of things in terms of the Runtimes is pretty slim pickings.

So I am wondering if it would be possible for @Mike, @rwkay, @ShaunJS or any of the YYG staff to let me (and other Spine users) know if there are any plans to implement more Spine related functionality in GMS2 going forward?

Are there any plans to bring the GMS2 implementation in line with the features already included and offered in the Spine Runtimes?

Hopefully there is, but if not could you elaborate why not?

I love Spine, and it being supported in GMS1 was one of the reasons I decided to give GMS a go, but compared to other languages and engines the features and functionality for Spine animations is pretty basic.

I've even used 3rd party wrappers of the very same Official Runtimes written by individual community members of pretty niche products that offer way more functionality.

This isn't a complaint, or an ultimatum or anything of the sort - I'm merely asking so I can plan ahead, and either get my head into GMS2 knowing that new features will be added to the Spine support, or save my money, move on and invest it elsewhere in other tools that will compliment the superior Spine support I already have in other languages and engines.

I've read GMS2 is written from the ground up with extensibility in mind, and I know you can't give me a concrete answer - but is it something that you agree needs working on and would be looking to improve going forward, or are you reading this thinking that the current implementation and available commands are more than enough and wondering wtf I am talking about?

If you need any examples of the sort of things I'm talking about I'd be happy to provide them if requested (and I'm sure other Spine users might chip in with their own) but this post is already way longer than I anticipated!

Thanks for reading, and apologies for a bit of a ramble.
 
Last edited:

ShaunJS

Just Another Dev
GMC Elder
Hello, could you be a bit more specific about what sorts of things you're after?

We're certainly not dropping our support for Spine, and we want as many features as possible but we just have to evaluate features in terms of priority etc.

So if we know more about exactly what you need it's easier to evaluate and lets us give you a better answer than "sure, one day!" =)
 

rIKmAN

Member
Hello, could you be a bit more specific about what sorts of things you're after?

We're certainly not dropping our support for Spine, and we want as many features as possible but we just have to evaluate features in terms of priority etc.

So if we know more about exactly what you need it's easier to evaluate and lets us give you a better answer than "sure, one day!" =)
Hey Shaun,

It's not really a single specific feature I am talking about, moreso the bringing in line of the GMS integration of the Spine Runtimes to match the functionality already provided in the Runtimes themselves - the available functions / features / commands in GMS pales in comparison to what the runtimes actually contain and already have available for use.

I would hope that YYG can see how limited the Spine support in GMS is, especially when dealing with large or intricate animations, but it kind of feels like the support was added as minimally as possible to be able to claim "Hey we support Spine" - which while technically correct, is a far cry from the functionality that the official runtimes provide to be able to control and manipulate animations programmatically.

Events just now being added is an example of this.

If there are ways to do any of this stuff already then please enlighten me, but from looking at the (very minimal) docs I see about 15 skeleton_* commands with which I am supposed to get the same functionality from as the (too many to count) properties and functions available in other implementations of the runtimes.
The maths just don't add up, it's like to trying to play an orchestral score with 15 pots and pans.

If you need some more specific examples for whatever reason, here are a few off the top of my head:

1) The ability to set the colour of a slot.
This is very basic, not sure why it wouldn't be one of the first things implemented but it seems you cannot programmatically set the colour of a slot.

2) The ability to find which slot in an animation is under point x/y (ie mouse x/y, player x/y etc)
This probably comes under helper functions, but none the less is something that is a standard feature in other language / engine implementations.

Imagine I build a GUI with buttons, gadgets etc, or a big boss enemy with multiple body parts all animated and able to be individually damaged.
How can I tell using the current GMS commands which button (slot) is pressed on the GUI, or which slot (body part) gets hit by a bullet so I can change the slot to show the damage?
I again spoke with @obscene regarding this, and he has had the boss issue himself recently and had to implement an ugly heavy workaround to alleviate the problem of not having a simple "skeleton_slot_at_xy(x, y)" function which returns the current slot found under x/y.

3) The requirement that every bone, even if not used in the animation, has to have all keys set for it to work properly in GMS.
Now there may be some reason for this specific to GMS and the way it works behind the scenes, but I have a lot of animations that work perfectly in another language using the Spine Runtimes which I wanted to bring over to GMS to basically compare the workflow between GMS v other language.

They were all broken in GMS.

After much hair pulling @obscene helped me out and it turns out that (as above) I needed to go through every one of my animations, and add keys to every single bone even if it was not used in that animation at all - that is waaaay too much work when I have a couple of hundred animations with an even bigger number of bones.

This is not a requirement of the Runtimes, as like I said the exact same animations work perfectly in another language using the same runtimes, so it's some weird requirement of GMS that unless this happens then things just don't work.

Those are just 3 off the top of my head as I said, and maybe could be implemented by the user in GML ourselves, but AFAIK there is no way of getting to the Spine data itself to access what we might need, we are just stuck with the 15 or so skeleton_* commands.

As I said this isn't a rant or a moaning thread and I don't "expect" or "demand" anything - and I hope it isn't take as such - but I would like to know where YYG staff see the Spine support going so I can plan ahead.

I use Spine a lot as a licensed user and want to continue doing so, but the current state of the support in GMS1 and GMS2 is so limited that if there are no plans to improve the functionality in GMS2 going forward, then I don't want to invest time and money that could be better spent elsewhere, where I can get access to the full range of functionality that Spine provides.

Sorry for the long post again.
 
D

Drenathor

Guest
I'd like to +1 this. I just started looking at Spine the other day and was considering purchasing a copy but after reading this thread I might hold off for a bit until GM's support for it matures.

Speaking of the integration... would the fact that GM supports skeletons mean that it supports BrashMonkey's Spriter as well? or is this integration limited to Esoteric's Spine currently?
 

rIKmAN

Member
I'd like to +1 this. I just started looking at Spine the other day and was considering purchasing a copy but after reading this thread I might hold off for a bit until GM's support for it matures.

Speaking of the integration... would the fact that GM supports skeletons mean that it supports BrashMonkey's Spriter as well? or is this integration limited to Esoteric's Spine currently?
Spriter isn't supported, although it may be possible via an extension.

There is a thread on the Spriter forums where work is being done to try and get it working by (and I assume this is the same person as on here) @hippyman although there seem to be some difficulties.

There have also been mentions of converters to convert Spriter and DragonBones exported files into Spine files that GMS will accept, and a converter was even made for DragonBones - but using these in any game violates the Spine Licence.

Basically you need to own a Spine licence to use the runtimes in your games (which GM does), at which point you have a licence for Spine - so you may as well just use Spine.

There was some ambiguity over this in another thread but Nate (the creator of Spine) posted on the thread to clear up the misconceptions.

YYG chose to go with Spine, which I fully support as it's superior in every way to both DragonBones and Spriter imo (I also own a Spriter Pro licence), although people are moaning that is costs money and isn't free. You get what you pay for (again just imo).

However the implementation of the Runtimes in GMS just isn't up to what it should be, given the direction that YYG are taking with GMS2. (ie. more serious indie development), and that it's "officially" supported within the engine, to provide ~15 commands to deal with everything Spine has to offer and provides within it's runtimes is just silly.

Of course this is all IMO, and is why I'm asking the questions - so I can plan where I go from here with regards to the engine / language / framework or whatever I use going forward, as it's going to include a lot of Spine work.

If YYG think the current Spine support is fine and there are no plans to add any other features / commands / ability to programmatically manipulate animations using GML etc then that is also fine and is YYGs prerogative.

I'd just like to know so I don't waste time and money (I'd also buy 'Mobile' exporters) on a product that isn't going to be able to do what I want to do with regards to Spine and it's runtimes.
 
Last edited:

hippyman

Member
That is my thread. I was trying to make my own implementation and have ran into a snag and temporarily abandoned the project. Somebody else managed to make a dll to use Spriter animations but it was a little buggy when I tested it. It might have been updated since then but I have no idea. It does function though but scaling caused some issues. You can find that here.
 
Z

zendorf

Guest
I am seriously considering getting a Spine license. Does GMS2 even support all of the Pro features like meshes, deformation, path constraints, etc?

Such a shame that the Pro version is so much more than Essentials, as doing any animation without IK would be going back to the dark ages, so Essentials isn't really much of an option. $300 is some serious coin to throw down for a application like this, especially since I already have Moho, Spriter and After Effects. Would like to know what the Spine limitations are in GMS2 are before investing...
 

rIKmAN

Member
That is my thread. I was trying to make my own implementation and have ran into a snag and temporarily abandoned the project. Somebody else managed to make a dll to use Spriter animations but it was a little buggy when I tested it. It might have been updated since then but I have no idea. It does function though but scaling caused some issues. You can find that here.
Ahhh it was you, I knew the name rang a bell! :)
The only thing with that DLL (unless I'm mistaken) is that it will only work for Windows Desktop, and I remember reading somewhere that Steam doesn't allow / accept games that use 3rd party dll files.

I am seriously considering getting a Spine license. Does GMS2 even support all of the Pro features like meshes, deformation, path constraints, etc?

Would like to know what the Spine limitations are in GMS2 are before investing...
The recently released GMS1 EA and GMS2 both support Spine v3.4.02 - info taken from the SDK Setup articles here for GMS1 and GMS2 - and earlier version of GMS1 support Spine v3.0.0.
Another member tested 3.0.10 and reported in another thread that it worked, although I can't remember the GMS version he used for the test.

Everything found in those versions of the Spine Editor should be supported in GMS, but there is just such a limited set of commands to programmatically manipulate them via GML.
 
Z

zendorf

Guest
Ahhh it was you, I knew the name rang a bell! :)
The only thing with that DLL (unless I'm mistaken) is that it will only work for Windows Desktop, and I remember reading somewhere that Steam doesn't allow / accept games that use 3rd party dll files.



The recently released GMS1 EA and GMS2 both support Spine v3.4.02 - info taken from the SDK Setup articles here for GMS1 and GMS2 - and earlier version of GMS1 support Spine v3.0.0.
Another member tested 3.0.10 and reported in another thread that it worked, although I can't remember the GMS version he used for the test.

Everything found in those versions of the Spine Editor should be supported in GMS, but there is just such a limited set of commands to programmatically manipulate them via GML.
Ok thanks, good to know. There is very little info on the web on using Spine with GMS. Has anyone successfully used Spine and in particular Spine deformation meshes in a commercial GMS2 game? Would love to see any links anyone has...
 

rIKmAN

Member
Ok thanks, good to know. There is very little info on the web on using Spine with GMS. Has anyone successfully used Spine and in particular Spine deformation meshes in a commercial GMS2 game? Would love to see any links anyone has...
Not sure about in commercial games, but you just have to create an animation that uses mesh deformation in Spine. All you can do with GMS is play the animation, so there is no reason that it shouldn't work as it did in the Spine Editor.

I agree with the lack of examples / documentation though - even the Spine article on the blog just shows how to import the sprite, get/set the animation and attachments, change the skin etc, basic stuff.
 
Z

zendorf

Guest
Was hoping that there may have been some released games using a Spine/GMS pipeline, as it would have given me some more confidence in buying it. There are a ton of released Unity games that have used it, but I couldn't find any GMS games that have used it.

Most of my game uses sprite animation and procedural FK animation, but I have been thinking of using Spine for my large boss characters as it would be ideal for this. Will probably just buy the essentials version and see how that goes as a starting point. It is a shame they don't have a 30 day full demo that does exports, so i could really try out its' viability. I am also pissed that I didn't buy it when it first came out (about $55 if I remember correctly). I did actually try out the first few beta versions, but ended up going with Spriter, as I was using Construct at the time...
 
D

Drenathor

Guest
Spriter isn't supported, although it may be possible via an extension.

There is a thread on the Spriter forums where work is being done to try and get it working by (and I assume this is the same person as on here) @hippyman although there seem to be some difficulties.

There have also been mentions of converters to convert Spriter and DragonBones exported files into Spine files that GMS will accept, and a converter was even made for DragonBones - but using these in any game violates the Spine Licence.

Basically you need to own a Spine licence to use the runtimes in your games (which GM does), at which point you have a licence for Spine - so you may as well just use Spine.

There was some ambiguity over this in another thread but Nate (the creator of Spine) posted on the thread to clear up the misconceptions.

YYG chose to go with Spine, which I fully support as it's superior in every way to both DragonBones and Spriter imo (I also own a Spriter Pro licence), although people are moaning that is costs money and isn't free. You get what you pay for (again just imo).

However the implementation of the Runtimes in GMS just isn't up to what it should be, given the direction that YYG are taking with GMS2. (ie. more serious indie development), and that it's "officially" supported within the engine, to provide ~15 commands to deal with everything Spine has to offer and provides within it's runtimes is just silly.

Of course this is all IMO, and is why I'm asking the questions - so I can plan where I go from here with regards to the engine / language / framework or whatever I use going forward, as it's going to include a lot of Spine work.

If YYG think the current Spine support is fine and there are no plans to add any other features / commands / ability to programmatically manipulate animations using GML etc then that is also fine and is YYGs prerogative.

I'd just like to know so I don't waste time and money (I'd also buy 'Mobile' exporters) on a product that isn't going to be able to do what I want to do with regards to Spine and it's runtimes.
Thanks for the info! I only recently heard of Spine so this is all new to me. Guess that settles which one I'll go with once there is more support for it. The 2 things that originally had me looking at the other one were the cheaper price and the marketplace of what seemed like very reasonably priced assets and effects to use in your projects. But like you said, if I need to buy spine to use Spriter I might as well stick with Spine. Here's to hoping that we can get more support for it. Thanks again for that info!
 

rIKmAN

Member
Thanks for the info! I only recently heard of Spine so this is all new to me. Guess that settles which one I'll go with once there is more support for it. The 2 things that originally had me looking at the other one were the cheaper price and the marketplace of what seemed like very reasonably priced assets and effects to use in your projects. But like you said, if I need to buy spine to use Spriter I might as well stick with Spine. Here's to hoping that we can get more support for it. Thanks again for that info!
Just to be clear - you don't need to buy Spine to use Spriter - that would only be the case if you were going to convert Spriter / DragonBones exports into Spine files which were readable by GMS, because GMS uses the Spine Runtimes which require you to have a Spine licence to use them and distribute your games.

It's really all about using the Spine Runtimes which requires a Spine licence.

Spriter alone will work with many other engines and languages, as will Spine, so if you aren't limited to just using GMS and can use another engine or language then Spriter may be a worthwhile option for you - it's a decent piece of software but I prefer Spine personally.

For GMS at this moment in time though, only Spine is supported so the options are limited - hence the reason I made this thread regarding improved support for the only natively supported skeletal animation pipeline.

Just wanted to clear that up.
 

Mick

Member
The only thing with that DLL (unless I'm mistaken) is that it will only work for Windows Desktop, and I remember reading somewhere that Steam doesn't allow / accept games that use 3rd party dll files.
This i just a sidenote: The limitation for Steam and dlls are only concerning Steam Workshop items. You can include dlls when you release a proper Steam game.
 

rIKmAN

Member
This i just a sidenote: The limitation for Steam and dlls are only concerning Steam Workshop items. You can include dlls when you release a proper Steam game.
Ah OK, I stand corrected - thanks for the clarification Mick! :)
 

rwkay

GameMaker Staff
GameMaker Dev.
@rIKmAN - you still have not told us what you would like to do... Without examples I find it difficult to see what else we could do... currently we allow you to do what we can think of we would want to do with spine animations...

give us examples of what you want to do and we will take a look at adding functionality (not promising it at this point, but talk to us)

Russell
 

rIKmAN

Member
@rIKmAN - you still have not told us what you would like to do... Without examples I find it difficult to see what else we could do... currently we allow you to do what we can think of we would want to do with spine animations...

give us examples of what you want to do and we will take a look at adding functionality (not promising it at this point, but talk to us)

Russell
Hey Russell,

I gave 3 examples off the top of my head in my second post in this thread (post #3), not sure if you missed it or just scrolled through to the bottom?

https://forum.yoyogames.com/index.php?threads/gms2-future-spine-support-plans.15280/#post-100221

What sort of examples do you want, specific to me, or to other Spine users in general?

I will post up a function list from another implementation of the Spine Runtimes for comparison to the available GMS functions in a short while.
 
C

Claire

Guest
I think Russell is asking you to be specific in what missing functionality is actively blocking you from development, either at the moment or in your future plans.
If you can provide a priority ordered list then you are more likely to get the things you really need than if we are given a long list of theoretical problems. It's all about prioritising against other work and seeing if we can fit something into the schedule.
 

rwkay

GameMaker Staff
GameMaker Dev.
@rIKmAN - my apologies I did not see those in the wall of text... can you please take each one individually and add them as suggestions at the GMS2 bug report website (i.e. http://www.yoyogames.com/bug2) and we will take a look to see what can be done, none of your requests are things that we have wanted to do ourselves but they are reasonable, we should be able to add them

Russell
 

rIKmAN

Member
@Claire - I was halfway through writing a reply to you and then Russell posted, but thanks for taking the time to reply, I appreciate it.

@rwkay
@rIKmAN - my apologies I did not see those in the wall of text...
LOL! :p - It wasn't meant to be that long but I got carried away.
can you please take each one individually and add them as suggestions at the GMS2 bug report website (i.e. http://www.yoyogames.com/bug2) and we will take a look to see what can be done, none of your requests are things that we have wanted to do ourselves but they are reasonable, we should be able to add them
OK will do - I didn't actually realise you could submit suggestions, I thought it was just bug reports.
Should I do this for other suggestions in future as well or do they need to be vetted on here first?

The fact you think they are reasonable and should be able to be implemented is great news, and I appreciate you being willing to consider adding functionality even though you may have never wanted to do it yourself.

I'm not sure what you've been doing to never have wanted to colour a slot programmatically or find which slot is under point x/y (ie. the mouse, player etc), but I'll give you the benefit of the doubt! :)

For the requirement of GMS needing every single bone to have keys at the start & end of every single animation even if they aren't used at all - is this because of under-the-hood requirements of GMS itself or just the way the runtimes have been implemented?

ie. Could this be changed or is it set in stone?

It's not a requirement in any other implementations of the runtimes I've used, and creates so much more work than should be required.

Thanks for your time and replies so far - I appreciate it!
 
L

Lemth

Guest
Just wanted to chime in that any additions to the support for Spine might really get me to go all in on the Spine+GMS2 combo. Since there aren't many alternatives to the potential that this has; it's just that it's current state has a few things lacking.

Think the suggestions for @rIKmAN are fair and I can associate with them.
 

rwkay

GameMaker Staff
GameMaker Dev.
I did not implement the Spine support so I am not sure why we have that requirement, we just build on the C++ runtime so I suspect that this is for some internal reason, it does sound like an onerous requirement, I will review it in the new year and look to remove this requirement.

Russell
 

rIKmAN

Member
I did not implement the Spine support so I am not sure why we have that requirement, we just build on the C++ runtime so I suspect that this is for some internal reason, it does sound like an onerous requirement, I will review it in the new year and look to remove this requirement.

Russell
This sounds great, I can't ask for much more than that.
Thanks for being so receptive to future changes and additions in functionality, it's very much appreciated!

I'll get those suggestions added to the bug report website later tonight.
 

rIKmAN

Member
@rIKmAN - my apologies I did not see those in the wall of text... can you please take each one individually and add them as suggestions at the GMS2 bug report website (i.e. http://www.yoyogames.com/bug2) and we will take a look to see what can be done, none of your requests are things that we have wanted to do ourselves but they are reasonable, we should be able to add them

Russell
I did not implement the Spine support so I am not sure why we have that requirement, we just build on the C++ runtime so I suspect that this is for some internal reason, it does sound like an onerous requirement, I will review it in the new year and look to remove this requirement.

Russell
So I finally got around to adding these via the bug website as you suggested, I submitted 3 separate reports, all quite in depth with detailed descriptions, examples of usage etc.

First, I received an email back asking me to submit a project with an example of the problem.

After explaining that I felt it was impossible to submit examples of suggestions for functions which didn't yet exist, and that I thought the person who replied had not even read the reports I was then told that it was an incorrect macro that had replied to me.

Then all 3 suggestion reports were merged, resulting in me receiving around 8 emails, which I could no longer make any sense of due to all 3 suggestions seemingly being mushed together and no longer making any sense.

I asked how I could keep track of my suggestions, and was told that it was no longer possible on the GMS2 version of Mantis, all my suggestions were marked as "Solved" and I was told all I could do was check future versions of GMS2 to see if they had been added. Brilliant.

Overall - honestly, I feel like I wasted an hour even bothering to file the reports.
I understand Spine improvements might not be at the front of the priority list at the moment, but considering I was specifically asked by you to submit these suggestions, I feel like I have been fobbed off by front line support and the suggestions marked as "Solved", merged into a big mess and put to one side.

I'm currently holding off on buying the Mobile, UWP and Desktop modules of GMS2 because of beta bugs, and currently the features available to manipulate Spine skeletons programmatically aren't suitable for me going forward, so to not even be able to have features I would like before I purchase added to a list I can keep an eye on is disappointing to say the least.

So in the meantime, could you please tell me how I can get the current slot / attachment of a Spine skeleton that is currently under the mouse cursor?

I know I can detect the skeleton as a whole, but what if I want to specifically detect the arms, legs, body or head slot / attachment of a skeleton?

Thanks.
 
Last edited:

rIKmAN

Member
I'm currently holding off on buying the Mobile, UWP and Desktop modules of GMS2 because of beta bugs, and currently the features available to manipulate Spine skeletons programmatically aren't suitable for me going forward, so to not even be able to have features I would like before I purchase added to a list I can keep an eye on is disappointing to say the least.

So in the meantime, could you please tell me how I can get the current slot / attachment of a Spine skeleton that is currently under the mouse cursor?

I know I can detect the skeleton as a whole, but what if I want to specifically detect the arms, legs, body or head slot / attachment of a skeleton?
@rwkay
I wouldn't normally bump and tag so soon, but I've seen you replying to other threads so I'm not sure if you got the original alert from my previous post.
 

Dan

GameMaker Staff
GameMaker Dev.
I'm not going to answer your gamedev support question, I'm afraid, but I will nudge Russell just now...

However, I will apologise for the mess which was made of your tickets. Multiple little things went wrong there to cause a lot of needless confusion, so I'm sorry that happened. I have now tidied up the mess and you have three individual suggestions in the bug database. You can see the suggestions just fine, as they are in the publicly-visible Runner project (they are not GMS2-specific suggestions and have nothing to do with the IDE):

0025516: Suggestion: Sprites: Ability to define the colour of a Spine slot during runtime

0025597: Suggestion: Sprites: Remove need for Spine Translate/Rotate/Scale keys for bones not actually used in an animation
0025598: Suggestion: Sprites: Ability to find which Spine slot is located at a given x/y

And sorry once again for all the confusion.
 

rIKmAN

Member
Thank you @Dan , I appreciate the honesty and you fixing the tickets to be readable again, and your reply of course.

Just to clarify, where and how should I file future bug reports and suggestions?

I'm not sure if the method I used to report them contributed to the mess or not, but I just want to make sure I'm using the right links and reporting forms so I can make sure any future reports go as smooth as they should.

One of the reporting forms doesn't even have Spine listed as an option in the category drop down menus, so it might be worth adding it to the list?

Thanks again!
 

rIKmAN

Member
@rIKmAN - you still have not told us what you would like to do... Without examples I find it difficult to see what else we could do... currently we allow you to do what we can think of we would want to do with spine animations...

give us examples of what you want to do and we will take a look at adding functionality (not promising it at this point, but talk to us)

Russell
Hey Russell,

Is there any news on if/when any of the Spine suggestions I submitted might be added to GMS2?

It's becoming a real chore trying to work around the limitations - mainly detecting a slot at a given x/y position as it makes having any sort of finite control over Spine sprites, collision detection of individual parts within a skeleton etc much more difficult than it should be.

Also colouring a slot programmatically during runtime which allows almost infinite variations of customisation to a skeleton using a single greyscale image and colouring it using code.

Imagine a character where you could colour a hair slot, boot slot, clothes slot etc, or a vehicle which you could change the colour of rather than having to provide a bloated skeleton with separate images for each colour you wanted to include.

They are on Mantis (links above) and are marked as "assigned" but there is no information other than when they were added.

Cheers.
 
Last edited:

rIKmAN

Member
Another week, another bump for @rwkay.

Spine isn't even on the roadmap at all, not sure if that means anything but confirmation one way or the other would be appreciated.
 

JeffJ

Member
Just saw their release post yesterday, and thought I'd have to bump this thread. Imagine the joy when I saw Russell had already done that.

I really hope you guys implement support for everything up to and including 3.6 - there is some extremely useful stuff in there.
 

rIKmAN

Member
We are investigating what is required to support this runtime update - no dates as yet though
I know you said no dates (and that's fine, completely understandable), but I just wanted to add that I hope it doesn't take so long that we end up in a position of you unveiling a 3.6 runtime update when Spine is on v4.x or something similar.

That would be the same "out of date runtimes" situation we are in now, but with different version numbers.

Hopefully you can work out something where future updates can be implemented a lot more easily, maybe more incrementally with regular minor additions to keep it on a par with Spine rather than the massive task it currently seems to become when it's left for so long between runtime updates.

I have faith, and remember that the Esoteric guys are more than happy to help if you wanted to reach out to them! :)
 

rwkay

GameMaker Staff
GameMaker Dev.
Depends on what Esoteric do... when we have the time we will update the runtime to the most recent (stable one) at that time... but it is when we have the time.

Frankly Esoteric's handling of versions is shocking and they need to up there game.

I would also like to move everything into a plugin such that you could upgrade it yourself if you so desire, so you are not waiting for us, but that will take considerably longer to extract and package properly (as it has both compile time and run time components).

Russell
 

rIKmAN

Member
Depends on what Esoteric do... when we have the time we will update the runtime to the most recent (stable one) at that time... but it is when we have the time.
Not sure what you mean about what Esoteric do, or how what they do affects how high up your priority list updating Spine is?
Frankly Esoteric's handling of versions is shocking and they need to up there game.
Again not sure what you mean by this so I may be misunderstanding your point, though I do find it strange that it's GMS that is lagging behind and all the other "officially maintained" runtimes are upto date with 3.6 already, yet you are telling them to up their game.
Sounds a little pot, kettle, black - unless I'm misunderstanding what you mean, as I mentioned.
I would also like to move everything into a plugin such that you could upgrade it yourself if you so desire, so you are not waiting for us, but that will take considerably longer to extract and package properly (as it has both compile time and run time components).
This is something I was going to suggest a while back, but I figured if it was tough finding time to just update to the latest runtime then doing something like that with the work involved might be near on impossible.

Do you think having Spine as a plugin/extension would offer good enough / comparable performance to the current integration?

It's something I suggested to the Esoteric guys (them maintaining an official Spine extension) but they seemed to be worried that because you mentioned how they would need access to the backend compiler (when they offered to help with integration) that they thought an extension might not be able to offer the performance needed for it to work as well as possible.

Do you think it might be a viable option to use an extension, and would performance suffer much in your opinion?

Thanks for your reply.
 
Last edited:

rwkay

GameMaker Staff
GameMaker Dev.
What I meant was if Esoteric release several versions (and not releasing a stable runtime) before we get around to updating the runtime then it may be out of date, we will integrate the latest stable runtime at the point we do the integration - if Esoteric release a new stable between the time our integration is written and it is released to our users, then that is out of our hands.

We WILL integrate the latest runtime at the time we do the integration - but there is always lag (in versioning)

Russell
 

rIKmAN

Member
What I meant was if Esoteric release several versions (and not releasing a stable runtime) before we get around to updating the runtime then it may be out of date, we will integrate the latest stable runtime at the point we do the integration - if Esoteric release a new stable between the time our integration is written and it is released to our users, then that is out of our hands.

We WILL integrate the latest runtime at the time we do the integration - but there is always lag (in versioning)

Russell
Yeah that's understandable, it wasn't clear in your previous post but I totally get that.
Esoteric did say via email that one of the previous updates would have been a pretty easy one to update to, there exact words were "almost a copy and paste", but I do appreciate that that is using the runtimes directly and you have to of course integrate them into GMS which is a much larger job, and I assume is what takes so much time and manpower.

What are your thoughts on having Spine as an extension?
Would it even be possible with the way it's integrated with sprites etc, or could that be sidestepped to be used completely externally via external .json and texture sheets?

If so do you think performance would be an issue when using it via an extension?

Thanks again for the reply, I appreciate it.
 

rwkay

GameMaker Staff
GameMaker Dev.
As I said above - long term I would prefer Spine to be integrated as an extension, but that is more complicated as it is more integrated than other extensions usually are, so it will take time to get to that point.

I would also like that extension's source to be on github (or similar) so that others can extend or modify it if they wish.

Russell
 
A

ancientarts

Guest
reading these i guess mesh is not included yet lol. just will have to render them out and use the frames.
 
Top