I made a game a little while ago called "Mr. Chinchillas Chinchilla Ball Adventure". I put it on the web and found more things wrong than usual.
No.1: When you download stuff onto the web it's usally is a bit slower than the scratch version, but i mean it was REAL SLOW! Like hardly moving(the character that you were was the one to was hardly moving).
No.2: The games purpose is to direct a chinchilla(a southern american animal)through multiple courses. You start at the top of the screen and are suppose to go to the bottom.
In the scratch version of this when you hit the bottom it immediateley goes to the next track. In the online version though,the only way to go to the next track is to hit the bottom THEN go halfway up.
There are some other minor things,but i think those are caused by the game being really slow.
Offline
I wike pie,
You might want to try adding a stop-script after broadcast "go to level 2,1" and
broadcast "final level". That would eliminate some of the overhead from forever loops that aren't doing anything.
You might also want to try having separate forever-if scripts for each of the tests, so that you are only testing one condition in each loop. I don't know if that would be faster or slower, but it might be worth trying. Each loop would look like
when I receive "goto level xx"
forever if color over color
report bad stuff
stop all
when I receive "goto level xx"
forever if touching exit color
broadcast "goto level x+1"
stop script
Try it out, and let me know if it helps any.
I don't have any explanation for why the "touching color" operator does not seem to be working properly in the java implementation----that looks like a genuine bug in the java implementation, and not just a timing problem.
Offline
I ran into a similar problem with speed differences in the Scratch application vs. the java applet. I ended up adding a speed calibration routine to my game. It basically runs through a loop and times how long it takes, then divides the time by the expected time (the time it takes in my design environment) and multiplies the number of steps each sprite moves at a time by the result.
I found that the java environment is about 1/2 as fast so everything gets multiplied by two. The game runs at about the same speed. This same method could account for different hardware as well.
You can take a look at the project to see how I did it. The speed calibration runs at the beginning of the mouse sprite's main script: http://scratch.mit.edu/projects/weissjd/5435
Offline
I don't think that there is a simple speed ratio between the java and squeak implementations (though the java one is ludicrously slow).
One program (not mine) that has weird timing behavior in the java applet is
http://scratch.mit.edu/projects/calculus/2351
which has a steady rhythm in the squeak version but changes tempo dramatically in the java version.
I looked over the code, but don't see any reason for the weird behavior.
Offline
Kevin,
You're probably right that there's not a simple ratio, that's why my project calculates an approximate ratio when it starts (see http://scratch.mit.edu/projects/weissjd/5435 to see how it does it). In my case I'm calculating a ratio between Scratch running on my machine (since that's what I've coded for) and whatever the project is executed under. This is still imperfect as speed can vary during a session.
I've also seen some jumpiness in the Java implementation. I'm not sure if this is something the Scratch team can improve or if it's just a reality of the platform.
Josh
Offline
I think the problem may come from java itself---I've heard that some versions of java do some compilation of the byte codes but not right away. This would have the effect of the java program suddenly speeding up as it switched from interpreting some routine to running a compiled version. I don't know whether this mechanism really exists, nor whether it is the cause of the sudden jumps in speed I see in scratch programs running under java.
Offline