They claim it fixed a bug that required introducing "wait" statements in every loop for the java implementation.
I don't have any test cases to see if it really did that.
One test case I've been using, calculus's dancer:
http://scratch.mit.edu/projects/calculus/2351
still has timing problems in the java implementation, so it is triggering problems other than whatever they fixed.
Offline
Hi, JSimone and Kevin.
The bug that was fixed was a subtle scheduler issue that could cause a script that was repeatedly invoked by broadcasts to never run. The following two scripts illustrate the problem. With the v12 Java player, the sprite would spin in place, rather than moving in a circle as it should. The clever workaround that Kevin suggested--adding a wait to the the loop--gave the script triggered by the broadcast a chance to run--but it should no longer be necessary.
when green flag clicked
forever
turn 15 degrees
broadcast "forward"
end
when I receive "forward"
move 30 steps
end
The fix for this bug was literally a one-letter change! A tiny bug with large effects...
However, this fix does not solve all timing related problems. Although there are mechanisms to try to make Scratch run at about the same speed on all machines, unfortunately there factors that are difficult to control that impact the timing. A particularly bad problem in the Java player is that the Java garbage collector runs at unpredictable times and introduces noticable pauses.
One strategy for dealing with timing/synchronization issues is to keep animation sequences fairly short and use broadcasts to keep things in sync. Two of the sample projects that use broadcasts in this way are BreakDance and FunWithAnimation. (I've seen many nice examples in projects on this site, too.)
If it is the note and drum command that are getting out of sync, I found that on my Mac OS X (a G4 PowerBook) Java 1.4 has much much faster response times than newer versions of Java. For some reason, Java 1.5 introduces time-lags in the note and drum commands that can slowly increase to many seconds. I assume it's a bug in Java and, if course, it makes those commands virtually unusable. I think this problem may be limited to Mac OS (and perhaps only PPC Macs); I have never seen this note/drum time lag on a Windows computer, whatever version of Java. I found the problem so annoying that I reverted back to Java 1.4. Kevin, this could be what you are seeing with Calculus's dancer project. (On my computer, the sync is quite good.) If the music is still playing after the dancer leaves the screen on your computer then you may be experiencing the time lag problem. Let me know if this turns out to be the problem on your computer.
-- John
Last edited by johnm (2007-06-20 22:49:43)
Offline
Nope, I can't run Java 1.5, as I've still got OS 10.3, not 10.4, and java 1.5 only runs under 10.4 (a beef I have with the starlogo3d people---I'll not be able to try their stuff until I buy a new machine or OS---probably not for several years).
The problem I've seen is not with the sound and visuals getting out of sync (that would be really nasty), because calculus's dancer does use broadcasts extensively for sync. The problem is that time seems to pass at a variable rate, so the very regular rhythm speeds up and slows down. It could be java garabage collecting, I suppose---the way to reduce that problem might be to forcibly trigger garbage collection after loading the .sb file, before simulating the green flag, and again everytime the stop button is pressed. Being very careful in the java not to generate temporary objects that would need garbage collecting would also help a lot----this may mean using and reusing globals when the natural tendency would be to use locals. I forget whether java has the equivalent of the c++ static variables: ones that have a local lexical scope but are allocated permanently like globals---if so, those could be useful for reducing the memory allocation/garabage collection problem (and would probably speed the code up a lot, as memory allocation is one of the most expensive operations in most modern code).
Offline
Hi, Kevin.
Thanks for the clarification.
Looking more closely, I see that that the Dancer project uses a lot of image effects--whirl on the dancer and color for the stage. These operations are slower in the Java player than in Scratch because in Scratch the "heavy lifting" is being done by primitives written in C. (You could do the same using the Java native interface (JNI), but then it would not run as an simple, unsigned Applet since JNI is a security risk.)
Even in Scratch, image effects on large sprites or to the stage run faster on faster computers, causing timings to vary from machine to machine. We considered limiting the speed of Scratch to the worst case even on fast machines, but that would have made it impossilbe to do fun, fast-paced action games since the "worst case" is just a few frames per second on a slow computer.
There may be ways to optimize the image effect code in the Java player. For example, there could be some unecessary allocation of BufferedImages. I can look into that.
Meanwhile, to make projects to run more smoothly in Java, you can limit the use of image effects, rotation, and size changes for large sprites or the stage. Sometimes you can use costume-changing as a substitute for some of these things. That makes your project bigger, of course, but changing costumes is cheaper than image manipulation.
-- John
Last edited by johnm (2007-06-23 09:30:03)
Offline
Thanks, I'll pass on the advice about image effects being slow on the java implementation.
I assume that color effects are cheap (just an offset to the index in the color map), but whirl and fisheye are expensive.
What about ghost effect?
Offline
It would might be worth doing some experiments to get actual performance numbers. However, I think ghost may be relatively fast since it uses the alpha-blending mode built into Java's graphics rendering. The color effect is, unfortunately, an RGB transformation not a colormap hack. So it probably only slight faster than whirl or fisheye.
-- John
Offline
Java does have issues regarding time syncronization and unpredictable garbage collection. Java's 3D api introduced more reliable timer functionality, but I'm not sure if it was available before Java 5 (1.4.2).
When java waits/sleeps the time given is the minimun number of milliseconds that it will pause, but as mentioned, it could take longer (when the processor is busy with image manipulation or garbage collection). There are ways that Java can detect OpenGL and OS proprietary graphics acceleration (as for dealing with alpha), but again I think this might not have been available before Java 5.
There are tips and workarounds for these discussed in Andrew Davidson's Killer Game Programming (O'Reilly), but I don't know them well enough to elaborate. :\
Offline