Feedback Spine and texture pages

[Joshua Allen]

With a big spine update coming I would like to know if we will be getting the ability to have spine sprites share the texture pages with normal sprites. I have no idea what is going behind the scenes with the rendering of spines but could each Spine texture page be combined (added) to the main texture page like a regular sprite and pass the UV coordinates back to the Spine?


Right now each Spine uses its own texture page separate from the main one. For our game Boss 101 we have over 3000 Spine sprites being used. At any one time we are drawing 100 or more Spines which causes 100 texture swaps.


Spine has become an integral part of our Boss 101/GameMaker experience and with the upcoming incorporation of the Event system we only imagine it increasing.


Thanks for your help and for listening.


Joshua

 

[Andrey]

And for me this topic is relevant because in my new project will use many spine animation.

 

[obscene]

If YoYo could separate the Animation Update event's dependency on the Draw Event, this COULD be worked around.

I have a bunch of tentacle objects made in Spine but I do NOT draw the sprite to screen and instead just use the skeleton data to position an array of segment objects. (So each segment can have its own mask, take damage, etc.) What is crazy is that if I simply make the object invisible, or comment out the draw event, the Animation Update event fails to run so I can't get the data. So I have to enable the draw event and set alpha to 0. Unfortunately, this still causes a texture swap even at 0 alpha.

IF the Animation Update event could be allowed to run when the object is not visible or the draw event is bypassed/overwritten it would be very simple to just manually draw your own sprites from your own texture pages at the bone positions and prevent texture swaps. This wouldn't work for deformations but for simple animations this could be soooooo much more efficient.

I've also tried making the skeleton invisible via Spine. Still swaps. Tried deleting the sprites from Spine. Error when importing. Tried deleting the slots in Spine. Out of Memory error when I run. There is no bypassing this at the moment.

 

[Mike]

In theory.... if you pasted the spine textures onto a larger one, you could use a shader to separate them out again. But as far as I know, the spine stuff works everything out and will probably need a 0 to 1 UV set.

Shaders would let you rescale that and relocate it if you wanted to.

 

[Joshua Allen]

In theory.... if you pasted the spine textures onto a larger one, you could use a shader to separate them out again. But as far as I know, the spine stuff works everything out and will probably need a 0 to 1 UV set.

Shaders would let you rescale that and relocate it if you wanted to.

Mike,

I don’t think that will work. From what I am reading this would make working in Spine much harder because it would effectively take away all the “skeleton” functions. This is, of course, assuming I am reading your answer correctly.

I understand the reasoning behind having each spine having its own texture but from a development standpoint, there needs to be a better way.

To put things in context we have been using Spine for 2 ½ years during the development of Boss 101. As I mention above we have over 3000 amount of Spines in the asset library. During average gameplay we are seeing upwards of 100 draw calls due almost entirely to Spine textures. If Spine were part of the main texture pages the number would drop to roughly 3 without any effort. Our concern is performance on older (or less powerful) systems.

Appreciate your reply and thanks for the help.


Joshua

 

[obscene]

I want to point out, and you may already know this but just in case... if you have multiple instances of the same spine object on screen GM is at least smart enough to use the same texture page for each of those if their depth order is concurrent.

 

[Mike]

While you can certainly do a shader yourself, "batching" would still be based on individual sprites - which I'm guessing is what you want to "fix"??

 

[obscene]

I think the goal he is after is the same I'm after, just reducing texture swaps. Every spine sprite means a new texture swap meaning a lot of spine objects on screen at one time in GM is totally impractical.

As I said in my post, if we could at least get the animation update event to work wtihout drawing the actual sprite to screen, we could manually draw our own custom sprites and avoid an infinite number of texture swaps.

 

[rIKmAN]

I think the goal he is after is the same I'm after, just reducing texture swaps. Every spine sprite means a new texture swap meaning a lot of spine objects on screen at one time in GM is totally impractical.

Is this just "on screen", or "in the room"?
I'm using normal sprites at the moment while coding, and will be swapping them out for Spine animations later down the line so you've got me worried now!

 

[obscene]

On screen and visible. It's a new swap for each spine sprite. However multiple instances that use the same sprite won't cause swaps as long as their depth order is the same / concurrent. Same behavior as using built-in particle effects. New swap for each effect.

 

[Joshua Allen]

which I'm guessing is what you want to "fix"?

Nothing needs to be fixed because it works, what we want is an improvement allowing for a way to reducing texture swaps.