Scratch

Support.

Wes64 wrote:

Theres an easy workaround.

Make a 1 pixel by 1 pixel sprite.

go to [mouse-pointer v]
if <touching color [#444444]?>
do stuff
end

That would make it not 1s1s though.

And yeah I know I could just not make it 1s1s but I like a challenge. :p

I support 

Wes64 wrote:

RedRocker227 wrote:

Wes64 wrote:

Theres an easy workaround.

Make a 1 pixel by 1 pixel sprite.

go to [mouse-pointer v]
if <touching color [#444444]?>
do stuff
end

That would make it not 1s1s though.

And yeah I know I could just not make it 1s1s but I like a challenge. :p

you can still have it be 1s1s and use that script.

Oh yeah. Don't know why I thought you couldn't. :L

That may not be fully reliable though, since it takes a few milliseconds for it to go to the mouse-pointer when there's loads of blocks, and those milliseconds may be important. Which is why it'd still be better to have this block.

RedRocker227 wrote:

Wes64 wrote:

RedRocker227 wrote:

That would make it not 1s1s though.

And yeah I know I could just not make it 1s1s but I like a challenge. :p

you can still have it be 1s1s and use that script.

Oh yeah. Don't know why I thought you couldn't. :L

That may not be fully reliable though, since it takes a few milliseconds for it to go to the mouse-pointer when there's loads of blocks, and those milliseconds may be important. Which is why it'd still be better to have this block.

Nope. The only blocks that produce lag are wait and loop blocks. Any other block is not affected, (i.e. there is no delay). Here.

RedRocker227 wrote:

That's not what I meant. It takes time to execute blocks, and when you have over a hundred blocks as I do, it takes a noticeable amount of time for the sprite to go to the cursor, even in presentation mode.

No it does not. I have personally constructed a script with well over 200 change X, change Y, and go-tos, and it still updates in one single frame.

go-to blocks do not create lag.

funelephant wrote:

Wes64 wrote:

RedRocker227 wrote:

That's not what I meant. It takes time to execute blocks, and when you have over a hundred blocks as I do, it takes a noticeable amount of time for the sprite to go to the cursor, even in presentation mode.

No it does not. I have personally constructed a script with well over 200 change X, change Y, and go-tos, and it still updates in one single frame.

go-to blocks do not create lag.

This block is just way more convenient.

thats true, but the scratch team usually does not accept ideas if there is an easy work-around.

Wes64 wrote:

RedRocker227 wrote:

Wes64 wrote:

Theres an easy workaround.

Make a 1 pixel by 1 pixel sprite.

go to [mouse-pointer v]
if <touching color [#444444]?>
do stuff
end

That would make it not 1s1s though.

And yeah I know I could just not make it 1s1s but I like a challenge. :p

you can still have it be 1s1s and use that script.

It wouldn't do much.

Wes64 wrote:

RedRocker227 wrote:

Wes64 wrote:

No it does not. I have personally constructed a script with well over 200 change X, change Y, and go-tos, and it still updates in one single frame.

go-to blocks do not create lag.

You're still misunderstanding me. It will take however long it takes for hundreds of blocks to be executed before it goes to the cursor, and those hundreds of blocks will take time to execute.

I feel like you are ignoring me. I wish you would test what I am saying, instead of saying im "misunderstanding you". Im trying to help you out with your game. 

Here. This has plenty of go-to's and there isn't any lag. This one has even more, and still, no lag. No matter how many blocks in the script, if there are no repeats or waits, it is instant.

If your project is producing lag, it is probably for other reasons. I know brightness effects are known to lag when stamped, as are large sprites which have been rotated.

The first of those seemed quite laggy to me, for example when pressing the left or right arrow key it wouldn't move instantly, unless for whatever reason you programmed it to be like that. It was only by a few milliseconds but still, it's noticeable.

Last edited by RedRocker227 (2012-08-13 15:06:14)

funelephant wrote:

RedRocker227 wrote:

Wes64 wrote:

I feel like you are ignoring me. I wish you would test what I am saying, instead of saying im "misunderstanding you". Im trying to help you out with your game. 

Here. This has plenty of go-to's and there isn't any lag. This one has even more, and still, no lag. No matter how many blocks in the script, if there are no repeats or waits, it is instant.

If your project is producing lag, it is probably for other reasons. I know brightness effects are known to lag when stamped, as are large sprites which have been rotated.

The first of those seemed quite laggy to me, for example when pressing the left or right arrow key it wouldn't move instantly, unless for whatever reason you programmed it to be like that. It was only by a few milliseconds but still, it's noticeable.

Yeah, I've noticed a tiny lag when I tested a go-to block.

I don't think it's to do with the go-to block itself, just the fact that in 1s1s's when you have hundreds of blocks it takes a while to get through them all.

Wes64 wrote:

RedRocker227 wrote:

The first of those seemed quite laggy to me, for example when pressing the left or right arrow key it wouldn't move instantly, unless for whatever reason you programmed it to be like that. It was only by a few milliseconds but still, it's noticeable.

Did you download them or play in flash? Perhaps there is something about my compter that makes it faster, or something about yours that is slower. I see no lag when I run either in the flash player. (They do lag somewhat in presentation mode however).

Flash player. My computer is quite slow, though.

Wes64 wrote:

RedRocker227 wrote:

Wes64 wrote:

Did you download them or play in flash? Perhaps there is something about my compter that makes it faster, or something about yours that is slower. I see no lag when I run either in the flash player. (They do lag somewhat in presentation mode however).

Flash player. My computer is quite slow, though.

Then that might be why 

Hm, but I don't experience much lag on non-1s1s projects though.