View Issue Details

IDProjectCategoryView StatusLast Update
0030321RunnerSpinePublic2019-01-30 11:03
ReporterStewart BishopAssigned ToMike Rennie 
PriorityHighSeverityC - GeneralReproducibility100%
Status ClosedResolutionFixed 
Product Version2.2.1 
Target Version2.2.2Fixed in Version2.2.2 
Summary0030321: Spine: Sprites always play at a fixed FPS regardless of your game's FPS
DescriptionIf you have a spine sprite and set your sprite animation speed to be based on your game speed rather than a fixed speed, when you change your game's speed the animation always still play at the same speed. E.g., in the sample provided if you change the gamespeed to 60 or 30 FPS the animation will always play at the same speed regardless.

Subsequently if you enable frameskipping your animation speed for Spine sprites will be doubled.
Steps To Reproduce1) Run the sample
2) Press 1, 2 or 3 to see the differences
TagsRunner, Spine
1.4 Found In
2.x Runtime Found In9.9.1.1280
2.x Runtime Verified In2.2.2.302

Activities

Stewart Bishop

2018-12-12 16:38

Developer  

Spine Gamespeed Problem.rar (292,904 bytes)

Mike Rennie

2018-12-20 17:15

Developer   ~0062314

This is actually multiple seperate issues. In this case the primary bug reported - "Sprites always play at a fixed FPS regardless of your game's FPS" - isn't actually a bug but just the way that Spine sprites have been implemented (they've worked this way since they were initially implemented). Their playback speed is designed to match how it looks in the Spine editor regardless of the actual game speed. If this isn't desirable then that's technically a new feature.

I couldn't reproduce the other bug reported - "if you enable frameskipping your animation speed for Spine sprites will be doubled" - on any combination of machine, video card, and monitor refresh rate I tried it on, so it's possible this has already been fixed.

There was a bug whereby changing the game speed as a Spine animation was playing would cause it to jump to a different point in the animation and subsequent animation end events wouldn't fire at the correct time. This has now been fixed.