Roasteroids version history & notes

   When I wrote Roasteroids, I was a hobbyist programmer with a (lousy) day-job writing the news at CNN Headline News. I developed the game to prove to myself that I could, to write an applet with good object-oriented principles (the sprite classes that display and move objects in the game were developed independently of the game itself), and to write an applet to get me some exposure by being a sure bet for inclusion in the "Created With Roaster" folder on the next Roaster CD.
   So, now it's January 1998, I'm doing professional Java development for a cool Atlanta-area startup , Roaster has gone out of business , and the game still runs more reliably on Unix and Windoze than MacOS, which I developed it on. Things never turn out the way you expect, huh?

Version history
1.1
January 1998
  • Changed a method name to fix a problem with Microsoft's Internet Explorer 4.0 for Macintosh version of Java 1.1.
  • Added a Component.requestFocus() call when the game starts so most players will no longer have to worry about their key-presses going to the browser's address line instead of controlling the ship.
  • Added a "Roasteroids.jar" archive to improve performance. Removed it when I discovered it completely broke MS Internet Explorer 3.01 for Mac. (go figure)
1.0
July 1997
Initial release. Compatibility detailed below.

   The following chart was initially provided to put up red flags to warn readers that performance could range from wonderful to system-crashing. While it's been updated with the first Java 1.1 VMs from Apple and Microsoft, it really only applies to MacOS players. Unix and Windoze Java implementations seem to be much more stable -- I've never had a complaint, and seeing the speed at which it runs in Netscape 4 for Win95 makes me wonder how the Mac version of Netscape can lag so far behind. :-(


Roasteroids Compatibility chart
as of January 10, 1998
Tested on 200MHz Performa 6400 (PPC 603ev) with 32MB RAM
Java environment (in order of playability, best to worst) Playable? Comments
Apple "Macintosh Runtime for Java 1.5" Yes Runs beautifully, responds to all keyboard events
Apple "Macintosh Runtime for Java 2.0" Yes Runs fast and responds to all keyboard events. Some initial graphics weirdness -- it looks like nothing gets drawn correctly until the second time it's needed. So stuff flickers in your first game, but eventually straightens itself out.
Microsoft "Internet Explorer 4.0 Mac" Reportedly yes The developers of the Java runtime for the new IE e-mailed me, saying they couldn't run Roasteroids, and had traced it to an infinite loop in my "doLayout()" routine. It turns out that Javasoft renamed their "layout()" routine to "doLayout()" in Java 1.1, so I was unintentionally overriding their version. Changing the method to "doMyLayout()" apparently fixed things.
Roaster "Applet Runner" Yes Runs beautifully, responds to key events only after you click inside the applet window(!). The response is iffy because Roaster's VM generates both KEY_PRESS and KEY_RELEASE events when you press and hold a key. See my IEKeyTest applet to test it for yourself.
Netscape "Communicator 4.01 Mac" Barely Runs decently, responds (poorly) to all keyboard events
Microsoft "Internet Explorer 3.01 Mac" No Runs decently, responds to fire and warp but not rotate or thrust. This has been traced to an apparent bug in the Microsoft Java Virtual Machine, which generates erroneous KEY_RELEASE events when a key is pressed down. See my IEKeyTest applet to test it for yourself.
Microsoft "Internet Explorer 3.01 Mac with Apple JVM" No Runs very well, flickers initially if you have MRJ 2.0 instead of 1.0 or 1.5, spins ship uncontrollably once you press z or x. Doesn't respond to fire key. This may be related to the keypress issues described above, since Apple's Applet Runner, using the same Virtual Machine, works well. See my IEKeyTest applet to test it for yourself.
Microsoft "Internet Explorer 3.01 Mac with JIT" No Runs well, responds to fire and warp but not rotate or thrust, then freezes computer after 5-10 seconds. Keyboard problem has been traced to an apparent bug in the Microsoft Java Virtual Machine, which generates erroneous KEY_RELEASE events when a key is pressed down. See my IEKeyTest applet to test it for yourself.