Space Smilies - a technological demonstration in one lvl

In 1999 I was first introduced to Java. I quite liked it. It was the first language that I'd come across in which it was possible to write your own draw routines while simultaneously being comprehensible. Sure, I already knew C and to a lesser extent C++ but to me it had always seemed like doing anything in those languages was incredibly painful. In Java it was relatively easy. The best thing about Java, though, was its runtime and draw routines were fast enough to write a small video game in. That March break I decided to write a video game. I called it Space Smilies after the placeholder smiley face icons I was using at the time.

Ever since then I've occasionally revisited code to see if I can figure out, using my newly acquired X years of experience, why somethings never quite worked right. I also spent some time to try and take advantage of the new abilities of the latest Java virtual machine (not to mention the processor power of the newest machines). I've just completed my latest batch of fixes and enhancements and am ready to release them to the world. Let me give you a rundown of what's been enhanced recently.

First off, I've corrected all those dang threading bugs. While I understood what threads were I wrote the original application I didn't really understand all the different ways in which you can screw up using threads. Since then I've learned a great deal about threads and, in fact, have become quite familiar with them. As a result of this, the newest version of Space Smilies draws the back buffer to the component on the event thread. It used to draw back buffer to the component on the thread I was using for the game engine. This doesn't really work well because AWT and swing aren't thread safe.


I'm also using a sort of triple buffering. The game engine draws to a back buffer. This back buffer is then given to the event thread on a sort of back buffer queue. The event thread then takes the latest back buffer and draws it to the component. After drawing to the component the back buffer is put into a free pool. When the game engine needs a new back buffer for the next frame, it looks in the free pool to see if one is available. The upshot of all this is that the final blitting is done on a different thread than the game engine which is doing the compositing.

Additionally, I'm using volatile buffers wherever possible to let the video card do most of the blitting and compositing. For whatever reason I can't get bit masked volatile buffers to be accelerated. This means that the bulk of the compositing is done on the CPU although the star-field (which is the biggest blob of pixels by far) is composited all on the video card.

(This is all on windows, your millage may vary on other operating systems)

Finally, I got the resolution of the game up from postage stamp sized to 1000 x 700. The old game used to remain fixed at that resolution but the new game will scale itself to take up as much area on the screen as it can.

I'm quite interested to know whether it works for everyone. You'll need Java 6 though. With any luck you actually have that but don't know it. Try it out either way.

GO PLAY THE GAME NOW!