• 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.

OFFICIAL GMS2 Spine Runtime Update 2.2.2

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
Beta IDE Release Notes
Beta Runtime Release Notes
Beta Opt-In FAQ
 (How to get on the Beta Channel)

This topic is for the discussion of issues relating to Spine Runtime Update. However, this does not replace our normal bug reporting system and you should report all bugs as normal using https://www.yoyogames.com/bug


Goal: Send us feedback and sample projects for when things do not work as expected. Any critical additions we should be considering at this time?

• The IDE now imports sprites exported using Spine 3.7 - see this guide for more info
• Fixed issues where importing new Spine sprites to replace existing data didn't clear the old files from your project folder
• Added support for several spine features and you can find the detail for these in the manual:
• Clipping attachments - These are attachments assigned to Spine slots which clip away parts of the sprite.
• Per-attachment colours - We now support tinting attachments based on their assigned colours.
• Per-slot blend modes - We now support per-slot blend modes as specified in the Spine IDE.
• Partial tint-black support - Note that this requires the use of a custom shader (see our manual).
• Multiple texture page support - We now support Spine sprites which use atlases referencing multiple image files (see this guide)
• Floating point frame indexes - so you get super-smooth animations, especially noticeable for slow-mo or speed-up effects

We have used a public fork of the spine runtimes (see https://github.com/YoYoGames/spine-runtimes/tree/3.7-beta). We plan to use this repository going forward, so if you are interested in seeing which changes, we have had to make, or which changes/fixes we have taken from the original Esoteric repository, you can.
 
Looks like us Spine users get ourselves a second Christmas! Thanks to the staff for giving Spine some love, the new features sound great.

Quick question for per-slot blend modes: how does this work out in terms of vertex batches etc? Say I have a bunch of sprites for I don't know like a checkerboard, and every other square is its own bone and the blend mode down the list is like:

square 1, 1 - normal
square 1, 2 - additive
square 1, 3 - normal
square 1, 4 - additive
...etc

1) Is that going to make the code go through the list of bones in their draw order running gpu_set_blendmode() over and over?

2) For optimization would we want to make sure all the stuff at the top of our draw order in Spine uses additive so there's just one switch? Like:

square 1, 4 - additive
square 1, 2 - additive
square 1, 3 - normal
square 1, 1 - normal
...etc

3) If I have a Spine sprite that just has one gpu_set_blendmode switch because I've followed question 2 above, and I have to draw 100 of them, if I do a with (obj_spinething) to draw them all at the same time (so it's just one texture page swap), would that still end up being 100 different gpu_set_blendmode switches (unless the entire spine sprite was additive blending of course)?

Just curious, this will be a huge time saver that's worth a slowdown hit if I have to take it, just for the ease of not having to make separate skeletons with additive stuff on them to work around this limitation lol

Thanks again for the hard work!
 

JeffJ

Member
First issue I've noticed is that the example snippet in the docs on how to make a Spine character's head aim at the mouse no longer seems to work:
Code:
var map = ds_map_create();
skeleton_bone_state_get("head", map);
var xx = ds_map_find_value(map, "worldX");
var yy = ds_map_find_value(map, "worldY");
var deltax = mouse_x - (x + xx);
var deltay = mouse_y - (y + yy);
var angle = -radtodeg(arctan2(deltay, deltax));
ds_map_replace(map, "angle", angle);
skeleton_bone_state_set("head", map);
ds_map_destroy(map);

It just does absolutely nothing. I wonder if maybe some of the internal values, such as worldX and worldY has changed names - tried a few different ones (like "x" and "X"), but to no avail.

EDIT:

My mistake! Turns out it was because the Spine sprite hadn't been updated. Works like a charm.
 
Last edited:

Dan

GameMaker Staff
GameMaker Dev.
There is an updated beta release out now, so please update when you can - https://forum.yoyogames.com/index.php?threads/gms2-version-2-2-2-beta-release.58932/ for further info.

It doesn't contain any specific fixes for Spine functionality, as (amazingly) none have been reported so far, but it does contain very important stability fixes to stop code editor crashes which might be impacting on your use of the beta version, so we would strongly advise you update.

If you do have any Spine issues with this 2.2.2 update, let us know asap, please!
 

rIKmAN

Member
There is an updated beta release out now, so please update when you can - https://forum.yoyogames.com/index.php?threads/gms2-version-2-2-2-beta-release.58932/ for further info.

It doesn't contain any specific fixes for Spine functionality, as (amazingly) none have been reported so far, but it does contain very important stability fixes to stop code editor crashes which might be impacting on your use of the beta version, so we would strongly advise you update.

If you do have any Spine issues with this 2.2.2 update, let us know asap, please!
I can't speak for anyone else, but I haven't been able to test much of the Spine stuff too in depth due to the crashing / freezing issues of the previous beta.
You might get a few reports now that the new beta update is out which seems to have fixed things in that regard.

Will test over the weekend, thanks for getting the update out so soon.
 
Looks like us Spine users get ourselves a second Christmas! Thanks to the staff for giving Spine some love, the new features sound great.

Quick question for per-slot blend modes: how does this work out in terms of vertex batches etc? Say I have a bunch of sprites for I don't know like a checkerboard, and every other square is its own bone and the blend mode down the list is like:

square 1, 1 - normal
square 1, 2 - additive
square 1, 3 - normal
square 1, 4 - additive
...etc

1) Is that going to make the code go through the list of bones in their draw order running gpu_set_blendmode() over and over?

2) For optimization would we want to make sure all the stuff at the top of our draw order in Spine uses additive so there's just one switch? Like:

square 1, 4 - additive
square 1, 2 - additive
square 1, 3 - normal
square 1, 1 - normal
...etc

3) If I have a Spine sprite that just has one gpu_set_blendmode switch because I've followed question 2 above, and I have to draw 100 of them, if I do a with (obj_spinething) to draw them all at the same time (so it's just one texture page swap), would that still end up being 100 different gpu_set_blendmode switches (unless the entire spine sprite was additive blending of course)?

Just curious, this will be a huge time saver that's worth a slowdown hit if I have to take it, just for the ease of not having to make separate skeletons with additive stuff on them to work around this limitation lol

Thanks again for the hard work!
Any advice from the YoYo staff on my questions above? Anyone using Spine for heavy duty art-heavy games is going to need to focus on optimization with Spine sprites requiring individual texture page swapping so I'd imagine other users will eventually ask the same questions when they get that far.

I'm doing a lot of glow effects with my Spine sprites in a SHMUP that I've had to separately store bone x/y positions for and trigger spawning my own separate objects on an Additive layer because Additive Spine layers weren't supported before and it would be a lot faster to do that all in Spine but I want to make sure I've got the least blend_mode switches possible 'cause obviously with a SHMUP every bit of optimization counts lol



Aside from that the only weirdness I've run into and I'm only mentioning it for anyone else who's coming from the last Full Release to this Beta like I just did: "worldX" and "worldY" must have been giving the wrong coordinates in the last Full Release because in that one I had to add the object's X to the Spine sprite bone's worldX to get the position right before, but after updating to this Beta I had to remove all those object X pluses and just use the worldX that skeleton_bone_state_get() returns...which is exactly what I would EXPECT to have to use, so that's great lol I didn't see "worldX" and "worldY" changing mentioned anywhere in the Release Notes so I'm guessing it happened in a much earlier Beta or something...I'm only mentioning it here because other Spine users lured into trying the beta for the Spine upgrades might run into this lol

I was already exporting Spine sprites from the latest version of Spine even with the last Full Release of GMS2 and it was all working fine (I just don't use any of the fancy Spine effects) so I don't think it was anything to do with having to re-export JSONs with the newest Spine release but I have no idea and don't care enough to figure out why it was different, I have too much cool Spine stuff to get making now! :D

About to test out slot blendmode stuff, if it isn't a big memory hog and I can finally do my Additive blending inside Spine instead of all this separate skeleton and tricky "spawn an Additive sprite when this Event triggers" juggling, I'm going to be one mighty happy camper lol

Thanks for getting the update out!
 
• Per-slot blend modes - We now support per-slot blend modes as specified in the Spine IDE.
Sorry I must be totally misunderstanding what this means...I just set some Slots to Additive/Screen for some fx in my Spine file but they just come out drawn solid opaque when I draw the sprite in-game, just like before. What exactly DOES this line in the release notes mean??? lol
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The blend mode stuff is possibly badly worded... it means the ability to set the colour and alpha on a slot, NOT the actual pixel blendmode. See skeleton_slot_colour_set() in the Beta manual.
 
The blend mode stuff is possibly badly worded... it means the ability to set the colour and alpha on a slot, NOT the actual pixel blendmode. See skeleton_slot_colour_set() in the Beta manual.
ohhhh...disregard my questions above then lol it should probably be reworded or the difference explained somewhere because GML using gpu_set_blendmode(bm_add) to do cool Additive glow effects combined with Spine's IDE calling the Additive/etc settings "Blending" is ripe for this type of confusion especially for a newbie lol

Thanks for the quick reply! I couldn't figure out how it would even work tbh lol but at least I've got my workarounds for doing glowy stuff already figured out so it's all good
 
Do all the Spine Pro features work? I know clipping was just supported. But Free-Form Deformation, Meshes, Weighted Meshes, IK Constraints, Transform Constraints, and Path Constraints? Are these supported?

From this page, it seems like just weighted meshes and audio aren't supported. https://www.reddit.com/r/gamemaker/...an_spine_do_in_game_maker_studio_2_right_now/

(Also, I don't know where else to ask this.)

I am asking before I buy the Pro version. Thanks!
 
Last edited:

Dan

GameMaker Staff
GameMaker Dev.
After speaking with the dev who did the Spine update, I have the following answers (in his words, not mine):

Okay, to answer BPOutlaws_Jeff questions first:

A1) Yes.

A2) Yeah, it won't set blend mode redundantly so attachments drawn one after another with the same texture and blend mode will be in the same batch. The basic idea is that each part of a Spine sprite is drawn in a specific order. In that order, if the blendmodes alternate: e.g. normal, additive, normal, additive, then it'll have to switch four times, whereas if the blendmodes are grouped together: e.g. additive, additive, normal, normal, then it'll only have to switch twice. However, if you draw 100 of these sprites then it won't draw the additive bits of all the sprites all together as it draws each sprite individually, so it'll have to change blendmode 200 times (twice for each sprite).

A3) Unless every part of the Spine sprite uses the same blend mode then it'll have to switch for each one (to maintain the drawing order of the attachments) so you'll end up with 100s of blendmode switches. Basically each Spine sprite is drawn as a single thing (otherwise the sorting will potentially be wrong) so it'll switch blend modes for each one.

Bonus answer) What Mark says isn't correct - it is actually the pixel blendmode. But in order to maintain the previous behaviour it's off by default and needs to be enabled. Probably the reason it isn't working is because you have to call "draw_enable_skeleton_blendmodes(true);" to enable it.


To answer FlameRooster's question about supported features: I couldn't answer specifically for each feature, but since we've upgraded to the latest runtime we should support everything that does - apart from audio. We may not provide runtime (GML-level) control of all features, but anything setup in the Spine editor should work.
 

Dan

GameMaker Staff
GameMaker Dev.
So there you go - anything which contradicts the above, send us a sample project ;)
 

JeffJ

Member
After speaking with the dev who did the Spine update, I have the following answers (in his words, not mine):

Okay, to answer BPOutlaws_Jeff questions first:

A1) Yes.

A2) Yeah, it won't set blend mode redundantly so attachments drawn one after another with the same texture and blend mode will be in the same batch. The basic idea is that each part of a Spine sprite is drawn in a specific order. In that order, if the blendmodes alternate: e.g. normal, additive, normal, additive, then it'll have to switch four times, whereas if the blendmodes are grouped together: e.g. additive, additive, normal, normal, then it'll only have to switch twice. However, if you draw 100 of these sprites then it won't draw the additive bits of all the sprites all together as it draws each sprite individually, so it'll have to change blendmode 200 times (twice for each sprite).

A3) Unless every part of the Spine sprite uses the same blend mode then it'll have to switch for each one (to maintain the drawing order of the attachments) so you'll end up with 100s of blendmode switches. Basically each Spine sprite is drawn as a single thing (otherwise the sorting will potentially be wrong) so it'll switch blend modes for each one.

Bonus answer) What Mark says isn't correct - it is actually the pixel blendmode. But in order to maintain the previous behaviour it's off by default and needs to be enabled. Probably the reason it isn't working is because you have to call "draw_enable_skeleton_blendmodes(true);" to enable it.


To answer FlameRooster's question about supported features: I couldn't answer specifically for each feature, but since we've upgraded to the latest runtime we should support everything that does - apart from audio. We may not provide runtime (GML-level) control of all features, but anything setup in the Spine editor should work.
Greatly appreciate the in depth reply in regards to how things are handled behind the curtain. If you guys haven't already, remember to include information like this in the docs - this is crucial to document for performance. It will also avoid dozens of topics asking these questions in the future.
 
That's good to hear. Only problem I am still having are the fragment lines that are appearing all over my character.pic1.PNG pic2.PNG pic3.PNG pic4.PNG

The bleed option is Spine is checked, so I don't know what the problem is. Looks completely fine in the IDE.

I did send a project and explained, but I didn't get a reply.
 

rIKmAN

Member
That's good to hear. Only problem I am still having are the fragment lines that are appearing all over my character.View attachment 23281 View attachment 23282 View attachment 23283 View attachment 23284

The bleed option is Spine is checked, so I don't know what the problem is. Looks completely fine in the IDE.

I did send a project and explained, but I didn't get a reply.
When you say they look fine in the IDE, do you mean in Spine or in the GMS2 preview?

A few things to check:
  1. Did you remember to reimport the files into GMS2 after saving / exporting from Spine?
    I've done this more times than I care to admit! haha!

  2. Have you tried toggling bleed off as well, just to test?

  3. Try adding a couple of pixels padding in the Spine export settings.
 
When you say they look fine in the IDE, do you mean in Spine or in the GMS2 preview?

A few things to check:
  1. Did you remember to reimport the files into GMS2 after saving / exporting from Spine?
    I've done this more times than I care to admit! haha!

  2. Have you tried toggling bleed off as well, just to test?

  3. Try adding a couple of pixels padding in the Spine export settings.
My character looks completely good in both Spine and in GMS2 preview.

1. I just made this character today, using version 3.7.90 of Spine and exported through that version.

2. I haven't tried this! I will try.

3. I added about 3-4 pixels of padding. Gonna try 6 pixels.

My character has pretty high resolution, but I don't think that should be a problem. (Like 2480x3500 resolution)

Edit: I tried doing 6 pixels of padding along with unticking bleed and getting the same results with the pixel fragments on my character. I tried unticking both bleed and premultiply, ticking premultiply, and then ticking bleed again. They all don't work. Ticking bleed or having it unticked gives the same results in-game of GMS2. Ticking premultiply makes the pixel fragments more visible.

I did all the above with 6 pixels of padding, so I don't think padding is the problem.

Weird because, before I installed the beta, the bleed option worked and my Spine characters looked 100% perfect in-game. Now the bleed option doesn't seem to do anything.
 
Last edited:

rIKmAN

Member
Edit: I tried doing 6 pixels of padding along with unticking bleed and getting the same results with the pixel fragments on my character. I tried unticking both bleed and premultiply, ticking premultiply, and then ticking bleed again. They all don't work. Ticking bleed or having it unticked gives the same results in-game of GMS2. Ticking premultiply makes the pixel fragments more visible.

I did all the above with 6 pixels of padding, so I don't think padding is the problem.

Weird because, before I installed the beta, the bleed option worked and my Spine characters looked 100% perfect in-game. Now the bleed option doesn't seem to do anything.
Sorry, I didn't realise you'd updated this post as you don't get alerts unless tagged or watching the thread - I usually see things on the "New Posts" page.

It's possible it may be a bug with the new beta / Spine update if the same skeleton worked fine in the previous version of GMS2 and exported with an older version of Spine - that's pretty much what this thread is for after all! :)

The only thing I can offer is if you wanted to PM me the Spine project I would be willing to take a look and see if I can see what the issue might be?

If that's not an option then tag Dan here and see what he says, or file a bug and attach the relevant files (GMS2 project, Spine project, exported json files) and see what the helpdesk says.
You can mark it as private if your files need to be kept away from public view.
 
After speaking with the dev who did the Spine update, I have the following answers (in his words, not mine):

Okay, to answer BPOutlaws_Jeff questions first:

A1) Yes.

A2) Yeah, it won't set blend mode redundantly so attachments drawn one after another with the same texture and blend mode will be in the same batch. The basic idea is that each part of a Spine sprite is drawn in a specific order. In that order, if the blendmodes alternate: e.g. normal, additive, normal, additive, then it'll have to switch four times, whereas if the blendmodes are grouped together: e.g. additive, additive, normal, normal, then it'll only have to switch twice. However, if you draw 100 of these sprites then it won't draw the additive bits of all the sprites all together as it draws each sprite individually, so it'll have to change blendmode 200 times (twice for each sprite).

A3) Unless every part of the Spine sprite uses the same blend mode then it'll have to switch for each one (to maintain the drawing order of the attachments) so you'll end up with 100s of blendmode switches. Basically each Spine sprite is drawn as a single thing (otherwise the sorting will potentially be wrong) so it'll switch blend modes for each one.

Bonus answer) What Mark says isn't correct - it is actually the pixel blendmode. But in order to maintain the previous behaviour it's off by default and needs to be enabled. Probably the reason it isn't working is because you have to call "draw_enable_skeleton_blendmodes(true);" to enable it.


To answer FlameRooster's question about supported features: I couldn't answer specifically for each feature, but since we've upgraded to the latest runtime we should support everything that does - apart from audio. We may not provide runtime (GML-level) control of all features, but anything setup in the Spine editor should work.
Awesome! Thanks a ton for the information!! I wasn't expecting to get an answer lol This is exactly the info I wanted to know for optimizing and deciding how and when to use Spine.

I found one tiny bug with the Screen blending (Additive and Multiply work fine), where the edges of the sprite bleed to the borders of the sprite so you can see the full square surface instead of the alpha stuff not being shown even though the exact same sprite works perfectly if it's set to Additive instead of Screen. I'll grab a screenshot and file a bug report when I get a chance here.

Some notes for Spine users from quick testing:

- the blend mode stuff works in GMS2 exactly you'd expect it to when you set it up in Spine, and Additive, Multiply and Screen are all supported so go nuts

- remember that blending will go underneath sprites in front of your sprite...but this could be something you actually DON'T want, like if you wanted sprites to be able to walk in front of a fire sprite but be covered in a big fat red glow from it as simple lighting

- keep in mind all the optimization stuff above 'cause if you're doing bullets or something with a glow on them, all those swaps and blend mode changes are gonna add up FAST...it can be worth coding glows attached to bones to draw them all at once in an End Step on a small surface scaled up for situations like that so there's only one blend mode change, for keeping things optimized

- try to sort your sprite drawing so that you draw all the objects that use the same Spine sprite at the same time if your game can play fast & loose with the draw order (like an isometric game you're out of luck but for a side-scroller you could have all the goombas drawn in front of all the turtles etc). You can draw like 10,000 Spine sprites running perfectly smooth without a single texture swap or vertex batch break doing it that way. You could use a drawing object that goes through each type of sprite and draws that group or just make layers in your room for "goombas" "turtles" etc...

...actually if you wanted to get fancy you could optimize it so each type of enemy has its own layer and then have your code change the layer depths on the fly based on which enemy is closer to the player so if a turtle or goomba gets closer to the player that layer is drawn on top, while keeping all the optimization of drawing the same enemies using the same Spine sprite at the same time. Just thinking out loud here lol

- ...I had more but I forget now, I just woke up lol Is there a Spine in GMS2 guide or wiki or something somewhere that a person can contribute notes and guidelines and code related tips & tricks and stuff to? It seems like there should be one especially with how much a little Spine animation can enhance even simple programmer art: https://twitter.com/BPOutlaws/status/635092073411055617 It would be awesome to see even more people using Spine in GMS2
 

Dan

GameMaker Staff
GameMaker Dev.
"I'll grab a screenshot and file a bug report when I get a chance here." < remember to send it as a helpdesk ticket, not just add it here ;)
 
Dan, can you fix this?

A previous version of GMS2 and Spine made my characters appear perfect. My characters are getting some sort of black artifact lines in certain areas. I am going to try importing the spine character into a different engine.

Edit: Yeah, my Spine characters look perfect in a different engine. GMS2 has a bug of some sort that creates artifact lines across my characters. I tested a lot trying to get it to work with GMS2, but it just doesn't. (Huge headache since I have a business and I am making a living with my game.) Really happy that I found the issue and that it is GMS2 and not something wrong that I am doing, lol.

I will be forced to move to another engine if this doesn't get fixed, sadly.
 
Last edited:

Dan

GameMaker Staff
GameMaker Dev.

rIKmAN

Member
Anyone else have issues with this bleed functionality now?
When I tried I couldn't reproduce it when exporting to Windows, but I did a test of the HTML5 export and that did give me the result that FlameRooster is seeing.
Everything was exactly the same other than changing the export to HTML5, but I haven't had time to look into it and do any more testing.

What export are you using @FlameRooster?
As I said previously if you want to link me to one of your skeletons / Spine projects I can try it my end too to confirm the issue is the same here.
 
IDE v2.2.2.401 and Runtime v2.2.2.314 are now rolling out, so you should get an update notification in the near future: https://forum.yoyogames.com/index.php?threads/gms2-version-2-2-2-beta-release.58932/

@FlameRooster I will find your updated ticket and look into this again asap next week, but your original report and sample didn't reproduce any issues for us and no-one else on here is reporting the same issue.

Anyone else have issues with this bleed functionality now?
Thank you!!

When I tried I couldn't reproduce it when exporting to Windows, but I did a test of the HTML5 export and that did give me the result that FlameRooster is seeing.
Everything was exactly the same other than changing the export to HTML5, but I haven't had time to look into it and do any more testing.

What export are you using @FlameRooster?
As I said previously if you want to link me to one of your skeletons / Spine projects I can try it my end too to confirm the issue is the same here.
I am using both Windows and HTML5 exports and they occur on both. I will send you a Spine project.
 

Dan

GameMaker Staff
GameMaker Dev.
As this issue is being discussed here also, we did indeed look at this issue again a couple of times since my message above, and it was huge sprites going through multiple size changes and doing lots of re-scales along the way. Simply increasing the texture page size in game options to 4096x4096 so the sprite wasn't immediately scaled down fixed the issue each time.

(The ticket has been replied to already.)
 
As this issue is being discussed here also, we did indeed look at this issue again a couple of times since my message above, and it was huge sprites going through multiple size changes and doing lots of re-scales along the way. Simply increasing the texture page size in game options to 4096x4096 so the sprite wasn't immediately scaled down fixed the issue each time.

(The ticket has been replied to already.)
Thank you Dan!!

I did try doing 4096x4096 for the texture page size but it didn't work before because I didn't clean the project. I set it to 4096x4096 and cleaned the project just now and the artifact lines don't appear in-game anymore. My Spine images as you said are way too big. Instead of doing 4096x4096 for texture page size, I will just scale down my spine characters down to a value around that will fit 1920x1080 screen size, because my game lags and pixelates at 4096x4096 texture size. I will likely also change my regular screen size 848x450, to something else that scales better to 1920x1080.

Thanks for clearing up this headache for me! It was a tough month or so trying to figure this out on my own!
 
M

Michael Park

Guest
EDIT: Sorry, wrong thread and I see there's now a 406 download although the beta release notes page still points to 401.

ORIGINAL:
401 isn't even launching for me on macOS. I'm running 10.14.3 and in the console I see:

Unhandled Exception:
System.TypeInitializationException: The type initializer for '<Module>' threw an exception. ---> System.Exception: This assembly has been built with SmartAssembly {8e7255a3-e84e-465e-88f6-44c3e2a09c55}, which has expired.
at #3nb.#T3.\^A () [0x0003d] in <434b40a442f341848633ad7f5cacb0cb>:0
at #3nb.#T3.#2nb () [0x00000] in <434b40a442f341848633ad7f5cacb0cb>:0
at <Module>..cctor () [0x00004] in <434b40a442f341848633ad7f5cacb0cb>:0
--- End of inner exception stack trace ---
at YoYoStudio.AppDelegate..ctor () [0x00036] in <7786e5858070462281c7044da5f51310>:0
at (wrapper managed-to-native) AppKit.NSApplication:NSApplicationMain (int,string[])
at AppKit.NSApplication.Main (System.String[] args) [0x00041] in /Users/builder/data/lanes/5143/09806627/source/xamarin-macios/src/AppKit/NSApplication.cs:100
at YoYoStudio.MacMain.Main (System.String[] args) [0x00025] in <7786e5858070462281c7044da5f51310>:0
 
O

oliverr

Guest
Hi,

There are issues with the HTML5 export with Spine. In the attached images you can see the problem. Desktop works perfectly, but HTML5 version doesn't export the images correctly, if you use more than one spine animation it replaces the animations with the same sprites.

In the second attached image you see the exported files, the bug is causing the images not to be exported correctly.

Is this a bug you are currently looking to fix?

Thanks
 

Attachments

rIKmAN

Member
Hi,

There are issues with the HTML5 export with Spine. In the attached images you can see the problem. Desktop works perfectly, but HTML5 version doesn't export the images correctly, if you use more than one spine animation it replaces the animations with the same sprites.

In the second attached image you see the exported files, the bug is causing the images not to be exported correctly.

Is this a bug you are currently looking to fix?

Thanks
It won't get fixed unless someone reports it as a bug - make a small project that reproduces the issue and attach it to your bug report.

You can report a bug from the Help menu in the IDE, or via the website.
 
Last edited:
Hello, I'm facing bugs with clipping attachments. It seems that something's not working properly as the result in GM is different than what's displayed inside spine.

<<< Animation in Spine (there are multiple clipping attachments, one is clipping the background, another one is clipping the sword, but foreground elements are not clipped. It is the wanted result.

<<< Becomes a mess in GM2.0, looks like the whole animation is being clipped by the first clipping attachment ?

There are 4 clipping attachments in the animation.

Here is the link to a zip containing the export skeleton, project file, atlas ... > Here

I'm on Spine 3.7.9.4 Professional.
GM version is 2.3.1.542


EDIT : so I'm trying multiple clipping attachment, in a blank project file everything's working as it should, I wonder if that's because Spine has some tolerance with the clipping attachment's "end" bone. I'll keep testing to understand why my animation is not understood properly at the moment.

EDIT 2 : issue is finally fixed :-D
What was happening : I had a clipping attachment in the clipping list of another clipping attachment. This was creating the bug. After removing that second clipping attachment it worked.
So maybe it's a GM bug but easy to workaround.


In case you read this because you're having issues with clipping in your Spine animation in GM, check if you did some clipping overlap (in terms of list, geometric overlap works fine) and remove it as much as possible.
 
Last edited:
Top