DeltaTime/ Limiting framerate

Is it possible to limit framerate?? I'm making a Flappy Bird clone and my game is having significant slowdowns and lag. How do i fix the lag, and limit the framerate??

Well, we can't really help fix the lag if we don't know what to fix. It would be nice if you could share the project.

snap limits framerate to 67, and in most cases browsers limit it to 60. there's no reason you would need a framerate limit on a flappy bird project and you shouldn't be having any lag. limiting framerate isn't a good solution to lag anyways

Why 67, exactly? Is there any reason?

https://snap.berkeley.edu/embed?projectname=flappy%20bird&username=dextron&showTitle=true&showAuthor=true&editButton=true&pauseButton=true

Here it is! The issue is when i draw the text in front. If i just print out the text, it appears behind the pipes. The way i put it in front now causes lag constantly.

Ah, sorry. Still working on the game; i will share it in a moment.

I think that limiting the FPS to 30 would give a more stable framerate, because there's more time to process therefore less lag drops. It would also be nice if i could run everything at the same speed. not dependant of FPS.

Limiting the fps to 30 won't do anything about reducing lag, in fact, it would probably lag even more. The issue is not the fps at all, instead something in your code.


I looked at your code, and figured out what was causing the lag. At first I though it was how you were displaying the score, but that was not actually the issue. The issue was how you were detecting scores.

This script in sprite (2) (the pipes)


can be improved by doing this instead.

Moving the sprite up and down, then checking if the player (sprite) is touching, is actually not necessary, since the player never moves left and right. You only need to check if the pipe is in the center of the screen (you can't be sure if the x position will be exactly 0, so I used < and > to check whether it's in the range).

Since this is no longer checking if it's touching the player to detect score, you can use check if it's touching the sprite to detect when the player loses.

As for the delete this clone block, I added that, because the clone is not deleted when the script ends, so the amount of clones will always increase, which can add a lot more lag.

Since the scored variable is now a script variable, you no longer need the scored sprite variable, so this script
flappy bird script pic (2)
can now be this
flappy bird script pic (3)

Now, displaying the score can be optimized even more. Since the score only updates whenever you go between a pipe, there's not really a reason to always update the score display. Instead, only tell the score display to update whenever you go in a pipe. This can be achieved by doing this.

and in the score display sprite (sprite (3)), do this
flappy bird script pic (5)
flappy bird script pic (6)

Here's the project: Snap! Build Your Own Blocks

My improvements actually made it run with no lag at all.

yes, you can hide lag spikes under a smooth consistent layer of lag. that's not really solving the problem though, it's the kind of thing you should apply carefully and as a last resort, and certainly shouldn't be done for a project this simple or even close to it.

there's a few issues you have:

  1. writing text with the pen is very slow, you should only do it when the score actually changes. i'd reccomend a broadcast that sends the current score to the score sprite
  2. multiple forever loops are pretty slow, again it's best to use one loop and broadcast to sprites since this also lets you control script order
  3. there's no reason to paste sprite3 on itself, it already has that costume! there's some other things you can remove from it like hide/show, and the double clear.
  4. i'm not sure what the "bwarrr" broadcast is but every single set of pipes broadcasts it every frame, i'm not sure why anything in this project would be needed multiple times in a single frame, or depend on how many pipes there are

note that when using broadcasts, every clone recieves the broadcast too. it's good to only broadcast to a specific sprite when you can.

most performance issues i know of in snap generally come from pen usage and many loops, and snap doesn't have great performance for a lot of things games tend to do. try to avoid running code as much as possible. snap has a very high clone limit, it might be more efficient to use clones instead of pen where possible, but i haven't tested that yet.

That's not entirely true. I've used pen in many of my projects to write text in a sprite every frame, and have not run into a performance hit.

That is true about controlling script order, but that's actually not true about broadcasting to reduce lag, in fact that's actually slower than multiple forever loops. It runs fast in scratch, but in snap, it actually lags a whole lot. It's best not to broadcast, and instead write the main script inside the forever loop, and only broadcast when needed.

It's not necessary when only one sprite receives it. There's not a huge performance difference when sending it directly to the sprite vs sending it like normal. The option was was added so if multiple sprites receive the same broadcast, you can send it to only one of the sprites.

Actually, that's slower. Writing a text engine in snap is really slow, since it uses a lot of code. Using the primitive write block is the easiest and fastest.

Oops. I was using the "bwarr" broadcast to just test. Thanks for the recommendations, @ego-lay_atman-bay and @sarpnt !!! My game is pretty much lagless now and i learned a lot more about Snap!