Warp: Technical stuff

Although each level is more than ten screens long (and can be made any size) the graphics area that stores the background is in fact just a little over two screens. Think of the current view as a window that moves upward along the graphics area. New ground is continuously being drawn above the window. At the same time an exact replica is drawn below it, so that when the window reaches the top of the graphics area it can jump down to the bottom and continue seamlessly from there. The cost of this on-the-fly graphics updating is (at most) one Graphics.drawImage operation per animation cycle and it saves a tremendous amount of memory.

Another memory-saving strategy I've used in Warp is to load the graphics of each new level separately and throw them away when they are no longer needed. This dramatically cuts down on the number of Image objects the applet needs to allocate and of course reduces the download time for netsurfers who weren't going to play all nine levels anyway. (I was actually forced to do this because otherwise the game would have been too big to run on the humble Macintosh Performa 6200 I was using at the time.)

To make the scrolling as smooth as possible, I don't update the score display and the blasted stationary objects immediately, but wait until the graphics updating has a spare cycle. I'm not sure exactly how much effect this has, but on slow machines I suppose every little bit helps.