1. Hey! Guest! The 36th GMC Jam will take place between February 27th, 12:00 UTC - March 2nd, 12:00 UTC. Why not join in! Click here to find out more!
    Dismiss Notice

[Answered] Multiple spine "skeletons" inside a single spine export. Is it possible?

Discussion in 'Programming' started by gkri, Feb 13, 2020 at 6:15 PM.

Tags:
  1. gkri

    gkri Member

    Joined:
    Jan 4, 2020
    Posts:
    10
    I was wondering if GMS2 can handle more than one skeleton from same json file (single spine export). I see on line many examples with a single skeleton but nowhere a case with 2 or more. I can not even tell if possible from the GMS2 manual.

    Can anyone confirm it?
     
  2. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    5,043
    I'm not sure what you are trying to do, but Spine will export multiple skeletons inside the same project as seperate .json for each skeleton.

    You can choose to share a single .atlas between them in the Spine export settings, but GMS2 wouldn't make use of this as it uses an atlas (or multiple atlases if required) per skeleton even if it's the same one being used by both Spine sprites.
     
  3. gkri

    gkri Member

    Joined:
    Jan 4, 2020
    Posts:
    10
    In order to understand better; Lets say a I have 10 skeletons that they share the same atlas (eg a single png 2048x2048), GMS2 will have in its memory this particular png x10 times?

    And another question if you allow me; Let's say I have an instance of an object containing a spine skeleton, inside a room, will I able to switch the skeleton with another skeleton as I could normally do as it was a normal sprite?

    Thank you! You are very helpful!
     
  4. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    5,043
    From my understanding each .json when loaded as a sprite in GMS2 also loads it's own atlas / set of atlases specific to that sprite even if it is the same skeleton and same atlases that are being used in different sprites.

    You can test this by adding the same Spine skeleton into two different sprites in an empty project, assigning each one to a different object and dragging them both into the room.

    Then run the project in debug mode and use the buttons at the top of debugger window pause the game, then restart it.

    Now in the top menu of the IDE go to Debugger > Windows > Surfaces & Textures to open the "Surfaces & Textures" window, make sure "Textures" is selected in the dropdown at the bottom left and hit the "Refresh" button at the bottom right.

    You will see that the texture atlas is listed twice - once for each skeleton - even though they are identical.


    This is likely because of the way slot colouring and other functions specific to Spine skeletons work behind the scenes, and support for shared atlases is something I submitted as a feature request a long time ago so I know they aren't supported either.

    In case there is some optimisation going on in the black box you should get in touch with support and ask them to confirm, though as I say from my knowledge of things it's unlikely.

    For switching skeleton - yes you can change them just as you do with normal sprites by assigning the sprite_index to a Spine sprite.
     
    Last edited: Feb 13, 2020 at 7:28 PM
  5. gkri

    gkri Member

    Joined:
    Jan 4, 2020
    Posts:
    10
    Thank you! I am "bombarding" questions because I am trying to figure out my workflow with GMS2...
     
  6. rIKmAN

    rIKmAN Member

    Joined:
    Sep 6, 2016
    Posts:
    5,043
    No problem - I just added some extra info so you can test it yourself using the Debugger.

    My advice would be not to start over optimising before you have started making the game and if you do start to hit any issues later then to tackle them then.

    Most of the time people worry about things that really aren't going to have a noticeable effect on their game and it stops them from actually making the thing. Pre-emptive optimisation can be a curse.

    You have to be a bit more cautious on mobile but with regular on-device testing this can also be handled without too much of an issue.
     
    gkri likes this.

Share This Page