It would be easy to under-sell this. This bug has been the most annoying bug in handWavey... Probably ever.
The bug
When a resource was constrained, and the LeapMotion controller was not able to get a new frame processed in to meet the frame rate, it would just duplicate the previous frame. This meant that the deltas were normally consistent, and then when this would happen, the frame would have 0 change from the previous frame, and the next frame would make up the difference.
This may be fine in systems that use absolute positioning, but relative positioning with velocity and acceleration calculations, This had the effect of:
Normal, Normal, Normal, Normal, Nothing, ZOOM.
The solution
I've added a very primitive check to test for whether the frame has changed at all from the previous one.
I spent a few days testing and refining this while I figured out exactly how I wanted handWavey to behave in this situation.
It would be easy to under-sell this. This bug has been the most annoying bug in handWavey... Probably ever.
The bug
When a resource was constrained, and the LeapMotion controller was not able to get a new frame processed in to meet the frame rate, it would just duplicate the previous frame. This meant that the deltas were normally consistent, and then when this would happen, the frame would have 0 change from the previous frame, and the next frame would make up the difference.
This may be fine in systems that use absolute positioning, but relative positioning with velocity and acceleration calculations, This had the effect of:
Normal, Normal, Normal, Normal, Nothing, ZOOM.
The solution
I've added a very primitive check to test for whether the frame has changed at all from the previous one.
I spent a few days testing and refining this while I figured out exactly how I wanted handWavey to behave in this situation.