My game, Temple Jumper, is running pretty slow, especially when you die. I have removed all unnecessary forever loops and done most of the common procedures to fix this, but, as you can see, it still runs quite slow. Does anyone have any suggestions? Thanks!

P.S. The game is still a work-in-progress, so just ignore the sprites like the sticky platform, ladders, and any other scripts that look like a work-in- progress

I did not lag when I tried it. Wow! That's a good-looking game! And great sound!

What kind of computer are you using? Is it an old one with limited RAM?

It didn't seem too slow to me either but I noticed in the stage scripts a couple of forever loops that seem a bit unnecessary; the one constantly setting brightness and volume and the one constantly checking if music > 6. So maybe there is more you could do!
You could probably use

to tidy up those scripts

footsocktoe wrote:

I did not lag when I tried it. Wow! That's a good-looking game! And great sound!

What kind of computer are you using? Is it an old one with limited RAM?

Thanks! The computer I'm using has 8 gigs of RAM, so I don't think that's the problem, though. How much RAM does yours have?

gor-dee wrote:

It didn't seem too slow to me either but I noticed in the stage scripts a couple of forever loops that seem a bit unnecessary; the one constantly setting brightness and volume and the one constantly checking if music > 6. So maybe there is more you could do!
You could probably use

to tidy up those scripts

I did use play sound until done blocks… and the forever loops are needed to set the brightness in the options and to make the music switching capability go in a loop. I suppose I could change them to repeat until level = 1 blocks, since you cannot change the brightness or music once it is not level 0, but once I add in the pause function you will be able to access options from there, so that wouldn't work. Thanks anyway!

11harry9 wrote:

gor-dee wrote:

It didn't seem too slow to me either but I noticed in the stage scripts a couple of forever loops that seem a bit unnecessary; the one constantly setting brightness and volume and the one constantly checking if music > 6. So maybe there is more you could do!
You could probably use

to tidy up those scripts

I did use play sound until done blocks… and the forever loops are needed to set the brightness in the options and to make the music switching capability go in a loop. I suppose I could change them to repeat until level = 1 blocks, since you cannot change the brightness or music once it is not level 0, but once I add in the pause function you will be able to access options from there, so that wouldn't work. Thanks anyway!

Anything in a forever loop is being checked 30 times a second. You should always consider if you really need to do it that way. Especially for things that only happen occasionally in the game. The pause function can use an “if key pressed” hat block. You don't need a forever loop to pause.

footsocktoe wrote:

11harry9 wrote:

gor-dee wrote:

It didn't seem too slow to me either but I noticed in the stage scripts a couple of forever loops that seem a bit unnecessary; the one constantly setting brightness and volume and the one constantly checking if music > 6. So maybe there is more you could do!
You could probably use

to tidy up those scripts

I did use play sound until done blocks… and the forever loops are needed to set the brightness in the options and to make the music switching capability go in a loop. I suppose I could change them to repeat until level = 1 blocks, since you cannot change the brightness or music once it is not level 0, but once I add in the pause function you will be able to access options from there, so that wouldn't work. Thanks anyway!

Anything in a forever loop is being checked 30 times a second. You should always consider if you really need to do it that way. Especially for things that only happen occasionally in the game. The pause function can use an “if key pressed” hat block. You don't need a forever loop to pause.

Music/brightness changes could occur often or not; it is impossible to tell when the player decides to change those settings beforehand. That is why I used a forever block there (for the time being, anyway (I may alter it once I add in the pause function)). A “when key pressed” block would work, and that is what I was already going to use for the pause function. I did use “when sprite clicked” blocks in the sprites to change the settings, and I could make it so it would broadcast when it is clicked, instead of using volume, brightness, and music variables, but the change from that would be so minuscule it would not make enough of a difference. Thanks for trying to help anyway!

11harry9 wrote:

footsocktoe wrote:

11harry9 wrote:

gor-dee wrote:

It didn't seem too slow to me either but I noticed in the stage scripts a couple of forever loops that seem a bit unnecessary; the one constantly setting brightness and volume and the one constantly checking if music > 6. So maybe there is more you could do!
You could probably use

to tidy up those scripts

I did use play sound until done blocks… and the forever loops are needed to set the brightness in the options and to make the music switching capability go in a loop. I suppose I could change them to repeat until level = 1 blocks, since you cannot change the brightness or music once it is not level 0, but once I add in the pause function you will be able to access options from there, so that wouldn't work. Thanks anyway!

Anything in a forever loop is being checked 30 times a second. You should always consider if you really need to do it that way. Especially for things that only happen occasionally in the game. The pause function can use an “if key pressed” hat block. You don't need a forever loop to pause.

Music/brightness changes could occur often or not; it is impossible to tell when the player decides to change those settings beforehand. That is why I used a forever block there (for the time being, anyway (I may alter it once I add in the pause function)). A “when key pressed” block would work, and that is what I was already going to use for the pause function. I did use “when sprite clicked” blocks in the sprites to change the settings, and I could make it so it would broadcast when it is clicked, instead of using volume, brightness, and music variables, but the change from that would be so minuscule it would not make enough of a difference. Thanks for trying to help anyway!

But the difference to be made is miniscule.

Let's say Scratch can handle doing 100 things at 30fps. If you try to do 101, then one thing gets skipped each frame, each time something different. So 30 times a second something is skipping. If you had your visuals synced to the audio, now you find they are no longer in sync.

So yes, it's possible that changing one little thing can make a big difference. Setting options by the player should be a “when key pressed” not a forever loop. Avoid forever loops as much as possible and your game will run smoother.

footsocktoe wrote:

11harry9 wrote:

footsocktoe wrote:

11harry9 wrote:

gor-dee wrote:

It didn't seem too slow to me either but I noticed in the stage scripts a couple of forever loops that seem a bit unnecessary; the one constantly setting brightness and volume and the one constantly checking if music > 6. So maybe there is more you could do!
You could probably use

to tidy up those scripts

I did use play sound until done blocks… and the forever loops are needed to set the brightness in the options and to make the music switching capability go in a loop. I suppose I could change them to repeat until level = 1 blocks, since you cannot change the brightness or music once it is not level 0, but once I add in the pause function you will be able to access options from there, so that wouldn't work. Thanks anyway!

Anything in a forever loop is being checked 30 times a second. You should always consider if you really need to do it that way. Especially for things that only happen occasionally in the game. The pause function can use an “if key pressed” hat block. You don't need a forever loop to pause.

Music/brightness changes could occur often or not; it is impossible to tell when the player decides to change those settings beforehand. That is why I used a forever block there (for the time being, anyway (I may alter it once I add in the pause function)). A “when key pressed” block would work, and that is what I was already going to use for the pause function. I did use “when sprite clicked” blocks in the sprites to change the settings, and I could make it so it would broadcast when it is clicked, instead of using volume, brightness, and music variables, but the change from that would be so minuscule it would not make enough of a difference. Thanks for trying to help anyway!

But the difference to be made is miniscule.

Let's say Scratch can handle doing 100 things at 30fps. If you try to do 101, then one thing gets skipped each frame, each time something different. So 30 times a second something is skipping. If you had your visuals synced to the audio, now you find they are no longer in sync.

So yes, it's possible that changing one little thing can make a big difference. Setting options by the player should be a “when key pressed” not a forever loop. Avoid forever loops as much as possible and your game will run smoother.

All I am trying to do though is to decrease lag. The difference in this is probably none, or such a small difference that no one can see it. I see what you are saying, but it is not like that in this case. Nothing is getting “skipped,” my game simply isn't running as fast as I would like. No offense, but please only continue posting if you have something else to contribute. Thanks!

“Skipped” was the wrong word. Better said this way… if Scratch can do 100 things at 30fps and you ask it to do 150, then everything will happen 50% slower and the fps will drop.

In a big, complex game, fewer things to do can mean a faster game. That's all I am saying. But if it's already running at 30fps, that's as fast as Scratch will go.

footsocktoe wrote:

“Skipped” was the wrong word. Better said this way… if Scratch can do 100 things at 30fps and you ask it to do 150, then everything will happen 50% slower and the fps will drop.

In a big, complex game, fewer things to do can mean a faster game. That's all I am saying. But if it's already running at 30fps, that's as fast as Scratch will go.

I understand what you mean, but some forever loops are necessary. Thanks anyway!

Usually for menu settings, while a project is already running, broadcasting is a better option rather a forever loop checking if there is some change.
I've noticed that in the fifth level when touchnig the flames a black box is showed for a moment.

How do you add projects to other peoples studios?

asivi wrote:

Usually for menu settings, while a project is already running, broadcasting is a better option rather a forever loop checking if there is some change.
I've noticed that in the fifth level when touchnig the flames a black box is showed for a moment.

Yes, that is because of the lag. The black box is the hitbox, and it is never supposed to show but the lag makes it glitch and appear for a second.

_SwagX_ wrote:

How do you add projects to other peoples studios?

Remix?

To hide the hitbox you may set the ghost effect to 100 at the first place inside the forever block, and change it to 0 at the end when the costume changes to player.

asivi wrote:

To hide the hitbox you may set the ghost effect to 100 at the first place inside the forever block, and change it to 0 at the end when the costume changes to player.

I know that would work, but I have it right now so that the player slowly fades out before respawning. Besides, it works how it is right now on a fast computer, it is a problem with lag, not precisely with how the game is actually played, if you know what I mean.

Do you want to show the time without decimals?
If yes you may do this

instead of

asivi wrote:

Do you want to show the time without decimals?
If yes you may do this

instead of

I used to have my code like that, but I wanted to include decimals, so I changes it a bit. There is probably a better way to do it than the code I have now, but it works fine for the the present. I may change it back to

but for now it is fine as is. Thanks!

Hi!
I'm running the project on my school computer, and it runs absolutely fine, until you die via falling.

I looked into the project, and narrowed it down to your Restart Level custom script, in the sprite “player.”
First off - your script is marked run without screen refresh, so your ghost effect script

To solve your problem, all you need to do is disable the “run without screen refresh” check in the Restart Level custom block
Not only can you not see the fade out, as the entire screen doesn't refresh until after that has completed, and the sprite doesn't actually change its ghost effect (straight to 100),

You noticed this of course, and tried to fix this by adding the

to it, as you thought the problem was that it was changing too fast.

That is where the lag comes from.
Putting a wait timer in a custom block with no screen refresh causes the definition of lag - the project cannot continue and refresh the screen until that script it over - however you have a 1 sec in there.
So nothing can happen until 1 sec later - which makes it appear to lag.