Pages: 1
Topic closed
Suppose you have a dodgeball game with a Hero and 10 balls, names Ball1 through Ball10. Here is a script in the hero (sorry, I haven't figured out the syntax for putting blocks into forum posts yet; please direct me to a thread on that if you can):
forever
set ( i ) to ( 1 )
repeat ( 10 )
if touching ( join ( "Ball" , i ) )
change ( hits ) by ( 1 )
change ( i ) by ( 1 )
The problem is, it takes almost a full second for the for-next loop to run, enough time for a ball to pass through completely. I discovered this my putting Hero go to mouse-pointer in this forever instead of it own. I'd wanted to avoid having each ball broadcast if it touches the Hero, since I had the impression that so many messages would slow things down, but apparently not as much as this does. In any case I was hoping to be able to do this sort of dynamic sprite naming with more arbitrary sets of sprites but perhaps it's not possible without sacrificing performance. Can Scratch do a fast For...Next style loop or is it always this slow?
Thanks for your help!
- Joe
Offline
Instead of looping it, simply repeat the blocks 10 times. You'll find it to be a lot faster.
Here's why - the loop adds a very large delay to the blocks. For instance,
change x by 10
change x by 10
actually executes a heck of a lot faster than
repeat 2
change x by 10
end repeat
So there you have it. Enjoy your readily sped-up script!
Unfortunately, with extremely longs scripts this becomes rather impractical - but it's the only way a the moment.
Offline
Do you mean this:
if touching Ball1
change hits by 1
if touching Ball2
change hits by 1
if touching Ball3
change hits by 1
if touching Ball4
change hits by 1
if touching Ball5
change hits by 1
if touching Ball6
change hits by 1
if touching Ball7
change hits by 1
if touching Ball8
change hits by 1
if touching Ball9
change hits by 1
if touching Ball10
change hits by 1
Well, that's unfortunately inelegant. I wish there was a better way, especially to have dynamically changed sprite names. But if that's what it is, that's what it is.
Thanks,
- Joe
Offline
Ok, but remember to put forever before that!
Offline
I tend to avoid color sensing because it restricts you in your backgrounds and causes rude surprises with random pixels tucked in sprites ripped off of sheets. I honestly don't see why it is so popular around here.
Offline
mainiacjoe wrote:
I tend to avoid color sensing because it restricts you in your backgrounds and causes rude surprises with random pixels tucked in sprites ripped off of sheets. I honestly don't see why it is so popular around here.
I agree with you 100% - I avoid colour sensing when possible.
Offline
Like all collision methods, color touching 'fits' into some situations better than others. The main reason people don't like it is because they do not make their own sprites so effectively they have no control over the color sensing in general. That explains all of the symptoms mentioned.
Don't get me wrong, I'm not saying it is great. I'm saying nothing is great. What is better, a wrench or a screwdriver? A hammer, a flat head screwdriver or a Phillips head? In my opinion, sprite movement - specifically movement, speed has the biggest impact on collision detection methodology. But then again, I love to use both found and hand drawn sprites.
Last edited by Locomule (2010-07-17 13:04:38)
Offline
Topic closed
Pages: 1