stickfiregames wrote:

Support.
“Reverse” is a bit of an ambiguous name though, and I would change them to control blocks.

Took out the reverse since it is workaroundable and like you said a bit ambiguous

AonymousGuy wrote:

As far as I know, no screen refresh blocks are the fastest thing possible in Scratch. (They can do lots of maths and rendering almost instantly!)

I did some tests and although run without screen refresh blocks are fast, turbo is faster (try putting a change x by 10 custom block running without screen refresh inside a forever loop and compare it with the same script without the run without screen refresh in turbo mode for example)

Thepuzzlegame wrote:

AonymousGuy wrote:

As far as I know, no screen refresh blocks are the fastest thing possible in Scratch. (They can do lots of maths and rendering almost instantly!)

I did some tests and although run without screen refresh blocks are fast, turbo is faster (try putting a change x by 10 custom block running without screen refresh inside a forever loop and compare it with the same script without the run without screen refresh in turbo mode for example)

I don't think your test works.

That's because in the first test, the screen in fact is refreshing every frame of the forever loop. The custom block does nothing, because the change x by block already runs without screen refresh. However, in the turbo mode test, it's refreshing at the “end” of the loop, which really doesn't exist.

Here is my test which proves they both go the same speed, if custom block doesn't go faster. Press a, then turn on turbo and press b, and then look inside.

AonymousGuy wrote:

I don't think your test works.

That's because in the first test, the screen in fact is refreshing every frame of the forever loop. The custom block does nothing, because the change x by block already runs without screen refresh. However, in the turbo mode test, it's refreshing at the “end” of the loop, which really doesn't exist.

Here is my test which proves they both go the same speed, if custom block doesn't go faster. Press a, then turn on turbo and press b, and then look inside.

You're absolutely correct! The way I had set it up the custom block wasn't used optimally. In your test it goes much faster, though I detected no noticeable difference between running it normally with no screen screen refresh and running in turbo mode with screen refresh. I guess they're probably just about equal, though I still suspect turbo mode to be a little faster

Thepuzzlegame wrote:

AonymousGuy wrote:

I don't think your test works.

That's because in the first test, the screen in fact is refreshing every frame of the forever loop. The custom block does nothing, because the change x by block already runs without screen refresh. However, in the turbo mode test, it's refreshing at the “end” of the loop, which really doesn't exist.

Here is my test which proves they both go the same speed, if custom block doesn't go faster. Press a, then turn on turbo and press b, and then look inside.

You're absolutely correct! The way I had set it up the custom block wasn't used optimally. In your test it goes much faster, though I detected no noticeable difference between running it normally with no screen screen refresh and running in turbo mode with screen refresh. I guess they're probably just about equal, though I still suspect turbo mode to be a little faster

It's not exactly “faster”, it provides a different functionality. As said before, it somehow got to the “end” of the forever loop without refreshing the screen, but so would the custom block if you were to put a forever loop in it. The problem with forever loops in custom blocks is they really lag.

So I guess semi-support.

AonymousGuy wrote:

Thepuzzlegame wrote:

AonymousGuy wrote:

I don't think your test works.

That's because in the first test, the screen in fact is refreshing every frame of the forever loop. The custom block does nothing, because the change x by block already runs without screen refresh. However, in the turbo mode test, it's refreshing at the “end” of the loop, which really doesn't exist.

Here is my test which proves they both go the same speed, if custom block doesn't go faster. Press a, then turn on turbo and press b, and then look inside.

You're absolutely correct! The way I had set it up the custom block wasn't used optimally. In your test it goes much faster, though I detected no noticeable difference between running it normally with no screen screen refresh and running in turbo mode with screen refresh. I guess they're probably just about equal, though I still suspect turbo mode to be a little faster

It's not exactly “faster”, it provides a different functionality. As said before, it somehow got to the “end” of the forever loop without refreshing the screen, but so would the custom block if you were to put a forever loop in it. The problem with forever loops in custom blocks is they really lag.

So I guess semi-support.

Thanks for your time

Did some more tests and the run without screen refresh works faster than turbo mode, therefore I am closing this topic

Hey guys! I recently played MoreBetter's Dodge game where he made a system that detects if someone if trying to turn turbo mode on to cheat but there was one flaw, you could turn turbo mode on before the green flag is clicked. There should be a new block that will detect if turbo mode is on

——————————————————————————————————

It will be in the “Sensing” tab and will look like this:

(turbo mode active :: sensing)

——————————————————————————————————

If you want to detect if turbo mode is not on, just do this:

<not (turbo mode active :: sensing)>

——————————————————————————————————

Here is an example use:

when green flag clicked
forever
    
if (turbo mode active :: sensing) then
say [You cannot use Turbo Mode!]
stop [all v]
    
end

end

——————————————————————————————————

Here is another block suggested by: Tramcrazy!

——————————————————————————————————

What it does: It turns turbo mode on/off automatically for you. If you always want turbo mode to be on, just use a forever block. It should be in the “Control” section.

What it looks like:

turn turbo mode [on v] :: control

turn turbo mode [off v] :: control

——————————————————————————————————

Hope you like this idea! If you do, make sure to give support!

Yes, this would be a really cool addition to Scratch.

Support.

I suggested this a while back, anyway, support!

Support.

Support. But I don't support this one:

turn turbo mode [on v] :: control

turn turbo mode [off v] :: control

V

Blueinkproductions wrote:

savaka wrote:

Support the first one, but not the second one. Turbo mode might crash really slow computers.

I don't think the computer would be crashed, only the Flash player.

Thanks for all the support guys!

Actually it would probably be blue for sensing.

<Turbo mode on? :: sensing>

Also, what about this:

Turn turbo mode [on v] :: control

Tramcrazy wrote:

Actually it would probably be blue for sensing.

<Turbo mode on? :: sensing>

Also, what about this:

Turn turbo mode [on v] :: control

I like that!

Tramcrazy wrote:

Actually it would probably be blue for sensing.

<Turbo mode on? :: sensing>

Also, what about this:

Turn turbo mode [on v] :: control

I know its blue but it just appeared orange

I agree! ^^ Also, because people don't always read instructions, and many projects like trig art require turbo mode or animations need it for better timing, it would really help. :3 Though you should have an option to manually turn it on/off so you can still have fun with turbo platformers/top downs ect.

It can be detected - although I can imagine that's annoying sometimes.

But it still isn't really needed. If someone wants to use turbo, let them use it. They can still go into the project and change the scripts to not block it out.

Unless you need it to prevent people from getting cloud highscores. But that's basically the only place you would ever need this.

Support the first one, but not the second one. Turbo mode might crash really slow computers.