I am playing a bit with Snap but I noticed heavy flickering, when I run my silly example full screen:
I read a bit about browsers and vsync and found this side:
www vsynctester com
I am wondering why scrolling the whole image in the test page runs smoother than moving a tiny ball in my simple Snap program? Is there something fundamentally wrong with my program? I am using "glide" with a 16x16 sprite 25 times per second.
But I had also a version with "go to" instead of "glide". I did not notice much difference. In this particular case it might be possible to glide straight to the border in one step. But my next project should be some kind of tank game with parabolic trajectory. What else but small steps can be used for that?
Snap! threads are synchronized to the browser animation loop@60FPS (usually).
Every loop iteration imposes 17ms delay.
With the "frame duration" 40ms, you add extra delay. Sprite glides 40ms then stays in place for 17-33ms.
With the "goto" you may reduce the ball increment to get the same speed.
The "timer" has 100ms resolution. For game logic use
The "increment" is comparable to the size of the ball, so the movement may be perceived as jittered.
Dont use empty "else", it adds an extra yield (17ms).
It's a user function. Export as XML or script pic. Then import into your project.
It means non-reentrant hat script. The default policy is to break pending, long-running scripts started by a hat block if a new script is about to start. "Safe" means that the script runs until it is completed, but a new script is blocked.
Snap! throttles the max frame rate to 67, so it's possible to have a frame duration of ~15 ms, though you must have a computer that works with 67 frames per second. If your computer frame rate is above that it is throttled by (currentFrameRate / Math.ceil(currentFrameRate / 67)). For example, if your computer frame rate is 100, it is throttled to 50. If 150, it becomes 50 too. If 120, it becomes 60.