Scratch

Ok, I'll upload a REASONABLE example.

EDIT: here: http://scratch.mit.edu/projects/justtestingstickman/934109
If you put a repeat loop, it slows down though.

Last edited by juststickman (2010-03-16 16:11:12)

Lucario621 wrote:

RHY3756547 wrote:

nXIII wrote:

I'm not sure about that... one second -
Nope. Not true; test it out: make a new Scratch project, make two sprites with a variable 'x', give one this script:
[blocks]<when green flag clicked>
<forever>
<change{ x }by( 1
<end>
[/blocks]
And the other this one:
[blocks]<when green flag clicked>
<forever>
<change{ x }by( 1
<wait( 1 )secs>
<end>
[/blocks]
The variable in the first sprite changes a lot faster, meaning that loop isn't waiting for the other one to finish before it starts again. Apply this to the problem at hand, and the quicker loop repeats more, triggering a false alarm.

Like anybody is going to use a wait block in their robot.

That too.

Look at this: http://scratch.mit.edu/projects/justtestingstickman/934109

nXIII wrote:

Lucario621 wrote:

nXIII wrote:

I'm not sure about that... one second -
Nope. Not true; test it out: make a new Scratch project, make two sprites with a variable 'x', give one this script:
[blocks]<when green flag clicked>
<forever>
<change{ x }by( 1
<end>
[/blocks]
And the other this one:
[blocks]<when green flag clicked>
<forever>
<change{ x }by( 1
<wait( 1 )secs>
<end>
[/blocks]
The variable in the first sprite changes a lot faster, meaning the loop isn't waiting for the other one to finish before it starts again. Apply this to the problem at hand, and the quicker loop repeats more, triggering a false alarm.

OMG!!!

You're really making me angry, considering how you're making the stupidest statements.

OBVIOUSLY, it has slowed down, because there is a block that PURPOSELY slows it down, and allows the other scripts to run in the mean time. That is the worst example you can possibly give.

Wow. The fact that you think THAT argument is stupid is just... wow. The wait block is there as an example of, say, calculating pi to ten digits. I just didn't feel like making a long script. juststickman has the right idea.

All processes are calculated IN PARALLEL. There are NO exceptions.

Repeat blocks are still parallel. If long scripts didn't run parallel then Sea Urchin Launcher would make the player get lodged in the ground because of calculation offsets.

Last edited by RHY3756547 (2010-03-16 16:50:51)

Lucario621 wrote:

You can't exchange a bunch of blocks (that doesn't include any repeating loops or anything) for a wait block. It just doesn't work.

...

*cough* yea, you can. I just did.

BTW: WAY better example:

Ok, each BLOCK executes once per step. You've probably seen the method doOneStep hanging around in the squeak somewhere. I'm pretty sure one STEP does not execute multiple blocks inside loops (including more loops). That would be kind of ridiculous. This means that IT EXECUTES THE NEXT BLOCK, NOT THE NEXT LOOP. SERIOUSLY. I thought you guys knew that...

Last edited by nXIII (2010-03-16 17:49:51)

nXIII wrote:

RHY3756547 wrote:

All processes are calculated IN PARALLEL. There are NO exceptions.

Of course they are. That's the point. Take two 'forever' blocks: one won't wait until the other finishes (hehe) before it starts. It's called being multithreaded. That means multiple threads (or SCRIPTS, in the case of Scratch) are being executed at the same time. They do not wait for each other. There are no exceptions. It would be ridiculous to have one thread waiting for the other to complete nested loops of 100, 1000, and 599. When you consider what you're saying, it basically comes down to this: A loop put in different projects will execute at different speeds depending on how long other loops in the project are. DO YOU THINK THAT REALLY MAKES SENSE?!

What are you on about?

All scripts are ran ONCE in a frame after each other. The loops run in parallel, each one completes and then waits for all the others to complete before the frame is rendered and the process is started again. The repeat block shortens this loop into the script inside the repeat block, is does not make the loop go out of sync. It just changes it.

nXIII wrote:

RHY3756547 wrote:

nXIII wrote:

Of course they are. That's the point. Take two 'forever' blocks: one won't wait until the other finishes (hehe) before it starts. It's called being multithreaded. That means multiple threads (or SCRIPTS, in the case of Scratch) are being executed at the same time. They do not wait for each other. There are no exceptions. It would be ridiculous to have one thread waiting for the other to complete nested loops of 100, 1000, and 599. When you consider what you're saying, it basically comes down to this: A loop put in different projects will execute at different speeds depending on how long other loops in the project are. DO YOU THINK THAT REALLY MAKES SENSE?!

What are you on about?

All scripts are ran ONCE in a frame after each other. The loops run in parallel, each one completes and then waits for all the others to complete before the frame is rendered and the process is started again. The repeat block shortens this loop into the script inside the repeat block, is does not make the loop go out of sync. It just changes it.

What are YOU on about? put ten 'change x by' blocks (or 100) in one loop. They don't all run before the frame is painted!

Umm

Yes they do. (unless you use the repeat block)

The thing is that Scratch when outside presentation mode has no VSync. This means that frames are rendered before one complete run-through of the scripts sometimes which gives the illusion that things are happening Asynchronously. This is not the case.

Go into presentation mode. You will only see the state of the sprite when it's process ends. (not halfway through calculation).

This is how ALL programming languages work. Processes NEVER what you are saying.

Last edited by RHY3756547 (2010-03-16 18:59:05)

Lucario621 wrote:

nXIII wrote:

RHY3756547 wrote:

All processes are calculated IN PARALLEL. There are NO exceptions.

Of course they are. That's the point. Take two 'forever' blocks: one won't wait until the other finishes (hehe) before it starts. It's called being multithreaded. That means multiple threads (or SCRIPTS, in the case of Scratch) are being executed at the same time. They do not wait for each other. There are no exceptions. It would be ridiculous to have one thread waiting for the other to complete nested loops of 100, 1000, and 599. When you consider what you're saying, it basically comes down to this: A loop put in different projects will execute at different speeds depending on how long other loops in the project are. DO YOU THINK THAT REALLY MAKES SENSE?!

...That's not what RHY meant.

Look at my project to prove you wrong. According to your theory, there should be an even amount of red and blue (because of the scripts and stuff - in the red one, it's the same, but there's like hundreds of the same block). And that isn't true.

Nearly all of my projects use the fact that this is true to FUNCTION for god's sake. Everything with bullets? Dependant on said frame by frame stepping.

nXIII wrote:

Lucario621 wrote:

...That's not what RHY meant.

Look at my project to prove you wrong. According to your theory, there should be an even amount of red and blue (because of the scripts and stuff - in the red one, it's the same, but there's like hundreds of the same block). And that isn't true.

GAAAAAAAAAAAAAAAAAAAAAAAAAAAH FAILED COMMUNICATION!
First of all, the reason your example works is because repeat loops take a step.
Secondly, as I mentioned above, I don't think we're talking about the same thing, because that example PROVES what I'm saying, instead of disproving it.

That reminds me.

What exactly are you saying?

Because it seems to be the opposite of what is happening in this project to me.

OK, DO NOT try running that project in flash blocks... it crashed MY Scratch.

...

...

-won't...stop...scripts...must...stop...scripts...nooooooooooooooooooooooooooooooooo--

Last edited by nXIII (2010-03-16 19:34:48)

Lucario621 wrote:

...

My project proves that once one loop worth of a script finish, it waits for all of the scripts in the project, to have finished one loop too. Than, it will continue. That is what happens in this project. Although the sprite1 makes a blue line, it waits for the sprite2 to  finish it's loop, and create all of the red lines, because it is still a loop that has to finish. And you're saying that's incorrect, when I am correct.

I SAID NEVER MIND. GOSH. I didn't think you meant that... I got confused by juststickman's project and thought you meant the EXTERNAL loop repeated... it repeats the most internal loop every frame. There. It's settled. Please don't tell me I just wrote the wrong thing...

Last edited by nXIII (2010-03-16 19:39:28)

RHY3756547 wrote:

OK - here is my revised robot. This had better be "legal" or I will strangle someone.

http://i364.photobucket.com/albums/oo85 … Newbot.gif

Size is 63x78.

Robot Shape is convex.

Robot is filled.

Everything checks out.

Confirm this so I can make final changes.

Needs verification.

Demosthenes, tell me if this is OK.

RHY3756547 wrote:

Is it OK if I offset the robot sprite from the body but still do the bullet-has-hit calculations on the body? 

Why would you want to do that...?

RHY3756547 wrote:

nXIII wrote:

RHY3756547 wrote:

Is it OK if I offset the robot sprite from the body but still do the bullet-has-hit calculations on the body? 

Why would you want to do that...?

Part of my EVIL PLAN.

Oh... trick the sensors. LOL that should probably be illegal.