I've heard quite a bit about forever loops without a wait causing starvation for other threads.
BTW many other race conditions that result in different behavior should not be considered bugs. i.e. If I broadcast a message and several sprites handle that message, the order in which those sprites handle the message in not guaranteed even if it may seem fairly consistent in some circumstances.
Last edited by slobasso (2007-06-08 14:54:47)
Offline
There's the off-by (-1,1) pen bug in the squeak implementation that isn't in the java one.
There's the rounding of direction in squeak, but not in java (I see this also as a squeak bug).
There's the rounding of direction when manually tweaked above the sprite pane in squeak, but not java (this is a java bug).
Note: I'm not being inconsistent above---the direction should be allowed to be a floating point value and should be returned precisely, but the manual control with a mouse should round.
There seem to be some timing errors with wait for s seconds in the java implementation, but I have not got a good test case for this yet--the programs that had problems with timing had enough other stuff going on that there could be some other cause.
There was a reported difference in the anti-aliasing filters for rotated sprites.
Was the error in touching-edge for rotated sprites (using the bounding box instead of the sprite) consistent in squeak and java? I don't remember.
The sounds for the MIDI instruments are very different in the java and squeak implementations. This is mainly because java provides its own midi synthesizer, which does not match the system-provided one used in squeak. Resolving this discrepancy may require providing the java synth in squeak, which is too bad, because it isn't as good.
Offline
This project shows that the Java version allows sprites to go farther off screen.
In this case the Java behavior seems preferred (at least to me).
http://scratch.mit.edu/projects/slobasso/11950
Last edited by slobasso (2007-06-09 16:28:12)
Offline