dunno... try to use the least amout of costumes, and try not to have to many or to long a script
Offline
Well forever loops take up alot of the cpu so put a small wait in. But scratch doesn't lag too much online.
Offline
Avoid graphics effects for large sprites or the stage---they are very inefficient in the java version. Avoid "busy waits" (loops that keep checking a condition). The "forever if" loop at least is implemented as if it was "forever wait until <condition>" which avoid some of the problem. All forever loops should have a wait in them---either for a condition that is not true when the loop is started or for some amount of time. Triggering things with broadcasts is generally more efficient than having lots of scripts testing conditions.
Offline
One big or many small? That's a hard thing to generalize about. If only one script is running at a time, it probably doesn't make much difference for efficiency, and many small scripts will be easier to read and debug. If many scripts are running at once, then reducing the number that are running will speed things up.
Reducing the number waiting for a boolean conditional will probably speed things up also, as the tests for that are somewhat slower than waiting for a broadcast (which is one reason some of us are advocating for "wait until I receive message" blocks.
Offline
Sorry, a "Boolean" is a variable or expression that has a true/false value. A "Boolean conditional" is a control structure (like a wait or an if) that evaluates a Boolean expression.
(Technically, Boolean should be capitalized, as is is based on the name George Boole, who invented what is now called Boolean algebra for manipulating logic expressions.)
Offline
to make my question less generalised, which would be faster of these two sets of scripts.
1) a big forever with 4 ifs (for the arrow controls)
2) 4 scripts like: when key pressed, perform.
Offline
When key pressed is more efficient than a forever loop with a bunch of ifs---the computer will waste a lot of time checking each if when nothing has changed. This is known as "busy waiting" and is a good way to make your programs slower than molasses in January.
Sorry, AlveKatt, your question doesn't have enough context to make sense to me. What does the sprite do? Changing costumes is pretty efficient.
Offline
It's the paint palette in this project.
I wanted to be able to paint over sprites, so I made paint out of sprites. http://scratch.mit.edu/projects/AlveKatt/29697
Didn't like the result much
Edit: First I had three costume sizes instead of just two and more angle variables. It looked alot better, but it got very, very slow...
Edit 2: It doesn't seem like the palette works in the On Line version though... It should work if you download it.
Last edited by AlveKatt (2007-08-17 02:12:18)
Offline
My Yar's Revenge project at
http://scratch.mit.edu/projects/clintp/24989
went through a couple of revisions to make it fast enough to be playable. In fact, its probably *too* fast now, but I wanted some speed left over to play with having the bunker move (stages 6 and higher), make the distinctive explosion (getting around to it), and to use better sound effects rather than just the built-ins from Scratch. I just got impatient and lazy.
The things I found that seemed to help on earlier revisions were:
* Fewer sprites = faster play
* Costume changes seem quicker than replacing sprites. (neutral zone's a good example in Yar's)
* Fewer "forever" loops running simultaneously the better. (Each sprite has one now)
* Sounds can make the Java version hiccup momentarily, especially if they haven't been played before.
* Inter-sprite signaling seems quick. Use this instead of waiting in loops for conditions. (Broadcast/When I Receive)
All of this is subjective, of course. The Sprite developers would know better.
Offline
All of clintp's advice looks good to me, except that I try to eliminate forever loops entirely if I can, having sprites react almost entirely to broadcast messages (or mouse and key events).
Offline