Spine (Keyframed) V Animated Sprite Performance

[Jonny Shaw]

Hi all, I'm working on a new slot game for mobile, some of the win icons may likely be spine animations, but some may work better as keyframed.  Having them all as spines would be simpler, but if the payoff is worth it, would look at customising each symbol type.
I was just wondering if anyone had done any benchmarking for keyframed animations in spine/pixijs v a traditional pixijs animated sprite?  Any advice greatly appreciated!

[jonforum]

2 hours ago, sHAYM4N said:

Hi all, I'm working on a new slot game for mobile, some of the win icons may likely be spine animations, but some may work better as keyframed.  Having them all as spines would be simpler, but if the payoff is worth it, would look at customising each symbol type.
I was just wondering if anyone had done any benchmarking for keyframed animations in spine/pixijs v a traditional pixijs animated sprite?  Any advice greatly appreciated!

it is not really comparable, the 2 are of interest rather different!

*If you want made sequential PNG, you should use  pixijs animated sprites
*If you want made complexe rigging animation but light weight, you should use spine.

it's not a technical benchmark but in my last performance test, my engine can hold ~~200 spine animated object before spike lag.
and ~~800 animated sprites before spikes fps.

My personal conclusion is Animated sprites are very more lightweight than spine, so recommande you to use pixi animated sprite to make simple sequential textures key animations.
i get this result on a i7 920 and gtx 1070

[ivan.popelyshev]

The next question will be "how to make animated sprite from a video"

[jonforum]

2 hours ago, ivan.popelyshev said:

The next question will be "how to make animated sprite from a video"

i will probably try a day, with small intro video ~~ 12 second.

With AE you can render the video frames to sequence png 32
this will give me ~~360 frames from video, + packing in texturePacker multipack and see if the performance and memory are better than the crap HTML video canvas player ?.

We lost the Audio api, but maybe PixiJS Sound can give some good result to synchronize with pixijs animated sprite.

[b10b]

@sHAYM4N using Spine to directly export to sequence png / atlas is a compromise worth investigating.  What it may lack in runtime flexibility and silky smooth 60fps WebGL framerate it makes up for in improved playback rate when using Canvas renderer on lowend mobile devices.  The right choice depends on who the audience is and what they are using.

[Jonny Shaw]

brilliant many thanks all.  Yeah @b10b definately something I had tried before.  Being a streamed game, atlas size is pretty important, so I think what I may try is splitting them down, e.g keyframing only certain parts of the icon where it can be done.  One solution I'm also working on at the moment is using RenderTexture to stream spines to a single texture, which seems to work nicely.  Only caveat with that is if I want to play different animations, all instances will be linked to that one rendered texture, so may have to have a think on that a bit more.  If I use too many instances of a spine icon, it will negate any gains made, so a bit of a balancing act  

[rines]

Have you tried only displaying the spines when the symbols have stopped moving and only displaying a static sprite when the symbol is moving?

[Jonny Shaw]

2 hours ago, rines said:

Have you tried only displaying the spines when the symbols have stopped moving and only displaying a static sprite when the symbol is moving?

Yes, I believe this was tried with the last slot, but was difficult to make the transition seamless, so most of the spines were just replaced, but will try it again.

 

On 10/1/2018 at 4:53 AM, b10b said:

@sHAYM4N using Spine to directly export to sequence png / atlas is a compromise worth investigating.  What it may lack in runtime flexibility and silky smooth 60fps WebGL framerate it makes up for in improved playback rate when using Canvas renderer on lowend mobile devices.  The right choice depends on who the audience is and what they are using.

Definately, the issue is we're trying to keep the initial load down as much as possible, the audio for instance is even being loaded on a seperate loader, and only begins when its ready.  Still need to make it accessible for people on 3g connections or less.  Icons are 90px squared, but have 60 frames x 12, and may need to add further animations, so really wanted to try and stick with the spines themselves first.

One thing I had wondered was if the rendering the sequences in game would be doable or worthwhile to this, so e.g. after the intial load, create the spine icons, have the ticker generate an array of textures for each icon to play out.  Once generated remove the spine and we could mask any delay behind a welcome message or something along those lines?

Not sure how it would affect drawcalls though having an array of generated textures v a pregenerated sprite sheet?

[Jonny Shaw]

reference to the last slot that was completed, this was an es5 prototype with all the spines in tact, it has since been converted to es6 in a framework, and optimised without the majority of the spines.  The new one is pretty much the same format, just with a reel system that uses less spines
http://www.digilocker.co.uk/demos/mrwonga/index.html

[b10b]

4 hours ago, sHAYM4N said:

Icons are 90px squared, but have 60 frames x 12

Is this at 60 FPS?  If so try halving it, most eyes won't tell the difference (so long as the interactive framerate is still high).  And use PngQuant / TinyPng for those spritesheets if not already doing so (to reduce initial load time).  Just in case tips.