Big lag for seemingly no reason

What's problem you are encountering?

when bullets are on screen the fps drops by 20-30. there are also lag spikes the almost freeze the game when spawning them. the game is also laggy overall

What have you tried that didn't work?
i tried alot of things. ive tried changing the fps cap (which is at 100 by default), splitting the bullet sprites into 2 that operate seperately, making more custom blocks, messing with dmg but idk how much that has to do with this, and a few more things that did a bit but not enough.

Post a project example, link, or screenshot:

i think it has something to do with the repeat until but i dont know any faster alternatives

edit: the bullet lag spikes are gone (for the most part) but there is still a lot of fps lag

removing this wait seemed to improve things for me

image

i dont see any diffrence (although im testing on a bad school computer), what happened when that was removed?

the purple "bullets" moved at a reasonable pace

they're supposed to be slow, the main problem is the bullets lowering the fps by alot. although i should increase the speed for the enemy and plasma projectiles (which are very slow rn).

ok i just removed a wait block from the fps counter and suddenly the entire game is much smoother idk why that fixed it

When you have a wait (n) secs block in a loop, it only runs the code every n seconds. That’s why it’s choppy. For smooth movement, instead of:

move (10) steps
wait (1) second

for example, you would use

move (1) steps
wait (0.1) second

Dividing both inputs by the same number (in my example, 10) will make movement much smoother. So it’s probably not your FPS dropping, it’s just a long wait between moving because of the wait block. That’s why cymplecy’s solution of removing the wait block makes your movement smoother (although it potentially removes a bit of functionality). Is that helpful?

the wait was 0.01 seconds, although for some reason when removing the wait block from just the fps counter it started running faster. the wait blocks are everywhere in order to limit the speed on everything (so that you can actually see whats going on) which is why i cant remove them from everything.

if something is too fast, you should move it slower, not move then wait, move then wait, move then wait...
when walking you don't sprint then pause for a second, you just walk.

this likely doesn't have anything to do with the lag you're talking about though
i can't look into it right now, but i would suggest finding whatever lags the worst and removing parts of it. if the lag stops, it's that part that's causing the issue and you can look into it more.

ye im trying to do that, the thing is if i make it slower and remove the wait then on slower devices everything is going to be going extremely slow while fast devices will have stuff still going at high speeds.

snap has a framerate limit of 67, and in most cases browsers limit to 60. as long as your framerate doesn't go below that, there won't be a difference on any devices.

if your framerate DOES go below that, it's an issue to fix, not to try and work around. wait blocks aren't precise, they only wait until whatever frame is past the time given, which means it's still slower on a lower framerate.

1: the fps is dropping very low thats the whole point of the topic
2: fps is limited to 67 even with turbo mode?

turbo mode doesn't change the framerate limit, it just changes when frames are drawn. without turbo mode, a frame happens when all the running scripts hit a wait (the end of a loop, wait block, or recursion), and then the scripts won't happen until 1/67th of a second later. with turbo mode, it only MIGHT do the frame after all the scripts hit a wait, so it might run the scripts, for example, 5 times in a frame. the scripts still stop for the frame and wait until the next, and the framerate is still only 67

limiting the framerate doesn't make the framerate higher, it just makes it always low instead of only sometimes low. this project isn't complex enough that it should be lagging, so you should just figure out why the project is slow and fix it. you can't learn anything by lowering the framerate and you can't just keep lowering it every time you run into issues with lag. you might do whatever causes the lag again if you don't figure out what it is.

i looked at the project again, i don't think you should be using turbo mode for it. the times that turbo mode scripts run at is in bursts, not at all consistent. mixing it with wait blocks to control sprite speed just causes all sorts of problems where even if the framerate is the same movement could speed up or slow down rapidly because of tiny inconsistencies.

for example, just having one enemy on screen for me halves the script speed compared to just the player since two things moving around is twice the amount. since the wait blocks are inconsistent and the code isn't designed for changing script speeds in other ways, everything slows down.

if you want to use turbo mode, you need to handle variable script speeds. note that this includes removing any wait blocks that need to be precise or fast (any wait block under 0.2 seconds is probably too short).

it would be much easier to just not use turbo mode (and still remove the wait blocks!), then fix anything that puts the fps below 60.

OTHER ISSUES RELATED TO LAG:

a lot of these sprites are only slightly adjusted copies of eachother (same code, including same strewn about blocks), it's very difficult to manage. a lot of these sprites should be merged together and just use multiple costumes and some variables to manage the slightly different behavior. any other identical code should go into blocks.

i see a lot of LAUNCH blocks around the project that are completely unneccecary because there's no waits or loops inside them. launches are quite slow (and iirc they're especially slow if you put the ring directly in it, i think they recreate the ring every time in that case)

i have no idea what the "timer" custom block is but it's another very short wait so i don't think it should be used.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.