turkey3_test wrote:

benjamin2 wrote:

When the game is inactive, my CPU usage fluctuates but never exceeds about 15-20%.
When the title screen was running, the usage peaked at 38%.
During level 2 running the usage peaked at around 60%.
It was always fluctuating. My internet security did not warn me of high usage.

A thought came to my mind. The +25 bonuses moved really fast (way too fast, actually) and they run on a ‘repeat x, move y steps’ basis, whereas the obstacles (which lag) run on glide blocks (because I could use glide blocks there and thought it would be better). Could this be a cause of the problem?

Possibly… I personally never use the glide blocks myself because they can not be stopped when gliding and are not really used in other languages.

Glides are fine. The galaga game in my signature uses them lots.
On topic though, running your game in non-turbo is much smoother and seems as fast to me.

The 2-player sprite costume1 has some rogue pixels in it which make the sprite area far larger than it should be which would probably slow down hit detection. So does 1-target. I'd be careful with your costumes.. You seem to be introducing rogue pixels and so making costumes that are far bigger than they should be. This will slow things down. Ensure they are all as small as possible. And in all the number sprites, in fact pretty much all have the problem!

FYI The rogue pixels seem to be in the top left which is why the costumes appear off centre. Make those changes and then see how things are.

drmcw wrote:

turkey3_test wrote:

benjamin2 wrote:

When the game is inactive, my CPU usage fluctuates but never exceeds about 15-20%.
When the title screen was running, the usage peaked at 38%.
During level 2 running the usage peaked at around 60%.
It was always fluctuating. My internet security did not warn me of high usage.

A thought came to my mind. The +25 bonuses moved really fast (way too fast, actually) and they run on a ‘repeat x, move y steps’ basis, whereas the obstacles (which lag) run on glide blocks (because I could use glide blocks there and thought it would be better). Could this be a cause of the problem?

Possibly… I personally never use the glide blocks myself because they can not be stopped when gliding and are not really used in other languages.

Glides are fine. The galaga game in my signature uses them lots.
On topic though, running your game in non-turbo is much smoother and seems as fast to me.

The 2-player sprite costume1 has some rogue pixels in it which make the sprite area far larger than it should be which would probably slow down hit detection. So does 1-target. I'd be careful with your costumes.. You seem to be introducing rogue pixels and so making costumes that are far bigger than they should be. This will slow things down. Ensure they are all as small as possible. And in all the number sprites, in fact pretty much all have the problem!

FYI The rogue pixels seem to be in the top left which is why the costumes appear off centre. Make those changes and then see how things are.

I can't find these rogue pixels - I've tried placing a black box over the sprite and sending it to the back and nothing happens.

Also, on your vector costumes, click and drag a box in the very top-left corner of the canvas, and then delete the invisible object. It appears on all new vector costumes. Trust me, that may help, as that invisible object greatly increases the resolution.

As drmcw says, the rogue pixels are hidden, but in the very very top left.

That very small invisible object in the top-left is also why costume thumbnails appear very puny.

turkey3_test wrote:

Also, on your vector costumes, click and drag a box in the very top-left corner of the canvas, and then delete the invisible object. It appears on all new vector costumes. Trust me, that may help, as that invisible object greatly increases the resolution.

As drmcw says, the rogue pixels are hidden, but in the very very top left.

That very small invisible object in the top-left is also why costume thumbnails appear very puny.

Thanks! Just got it. Will do this for all sprites used in level 2, and re-upload the project over the one on my test account.

Why are they here in the first place?

benjamin2 wrote:

Why are they here in the first place?

Just a bug that the ST I think knows about but never fixed.

After uploading the new version to my test account and trying it online, there is no optimisation.

I'll try running it without using Turbo Mode.

I've just found that Level 2 works perfectly if you don't use Turbo Mode.

…
…
Why?

benjamin2 wrote:

I've just found that Level 2 works perfectly if you don't use Turbo Mode.

…
…
Why?

When you use turbo mode, the computer basically maxes out everything it can do. It runs every script without screen refresh, so a really long script it will try to do in one frame. If you have any “repeat until” blocks running in turbo mode, you can run into an Infinite Loop.

When not in turbo mode, there is a minuscule delay between each block.

move (10) steps
... //there is actually a very small wait here, about 1/30 of a second
move (10) steps

but in turbo it runs it all at once, and then it refreshes the screen. So if you repeatedly move 1 step 100 times in turbo mode, what you see is the same thing as a sprite moving 100 steps in one frame.

Try and always avoid using turbo mode. The problem is it runs everything in one frame. The best is to decide what you do and don't want to run turbo by making custom blocks that run without screen refresh, which is the exact same thing.

turkey3_test wrote:

When not in turbo mode, there is a minuscule delay between each block.

No, there's a 1/30th second delay after each iteration of the script, not after each block.

turkey3_test wrote:

benjamin2 wrote:

I've just found that Level 2 works perfectly if you don't use Turbo Mode.

…
…
Why?

When you use turbo mode, the computer basically maxes out everything it can do. It runs every script without screen refresh, so a really long script it will try to do in one frame. If you have any “repeat until” blocks running in turbo mode, you can run into an Infinite Loop.

When not in turbo mode, there is a minuscule delay between each block.

move (10) steps
... //there is actually a very small wait here, about 1/30 of a second
move (10) steps

but in turbo it runs it all at once, and then it refreshes the screen. So if you repeatedly move 1 step 100 times in turbo mode, what you see is the same thing as a sprite moving 100 steps in one frame.

Try and always avoid using turbo mode. The problem is it runs everything in one frame. The best is to decide what you do and don't want to run turbo by making custom blocks that run without screen refresh, which is the exact same thing.

My scripts have occasional ‘wait 0.01 secs’ blocks in them. Don't these hold off the script?

Anyway, for now the problem seems to be fixed. Thanks for all of your help. I'll put you in the credits for helping me out, along with drmcw.
If I need help again (which I'll hopefully not) I'll come back here. So I'll leave this thread open for now.

The way I think of turbo mode is that the graphics system tries to refresh the screen 30 times per seconds so that you get reasonably smooth animation. In normal mode Scratch runs your blocks but tries to synchronise with the graphics update, so that each time something is changed that will affect the screen, scratch waits until that change is drawn. In turbo mode there is no waiting. A simple example is to have a sprite move left or right when the arrow keys are pressed. In normal mode you'll see each step, in turbo mode you'll just see the sprite at the edges of the screen and nothing in between.