What the Java Platform Needs

The Java platform has made great strides for gaming, especially with version 1.4. However, there's still some technology and APIs that would make games written for the Java platform even better. In this section, we cover some. Luckily, almost everything mentioned here either has a Bug Parade ID or is known to be considered for a future release. So, it won't be long until you see some of these features.

Needed: More Options for Mouse and Keyboard Input

For full-screen games, the AWT event architecture is a bit of overkill, and it doesn't give the kind of mouse and key input a typical game needs. You don't need a separate event thread to create a MouseEvent and a KeyEvent every time the user presses a key or moves the mouse. Also, the event architecture can create a delay from the time the user presses a key to the point that the game actually receives it. Instead, it would be great to poll the keys pressed on the keyboard and the state of the mouse. That is, you would directly sniff out the state of the keyboard and mouse in the main game loop and react accordingly. This would also minimize the delay from the time the user presses a key to the time the game reacts to it. Also, in this tutorial we provided a way to implement mouselook-style movement because the current API gives only an absolute mouse location. Instead, it would be very useful to provide relative mouse movement to make mouselook-style movement more robust. Also, some mouse devices are employing force-feedback capabilities, which would be great to control from a Java game. Force feedback is the name given to vibrating joysticks, mouse devices, or other devices to give the player feedback on what is happening within a game. For example, the mouse could vibrate when the player gets attacked by a monster or falls to the ground. Also, some force feedback mouse devices and joysticks add resistance so that as the player throttles a plane in a flight simulator, for example, the joystick becomes harder to press forward. Finally, the mouse cursor can be made invisible by sending a custom mouse image, but it's not perfect on all platforms. For example, moving the mouse on some machines causes strange repaint behavior to occur, even when the mouse is invisible. It would be nice to switch off the cursor completely. 

Input polling Bug ID: 4083501
Mouse cursor invisibility Bug ID: 4526950

Needed: Joystick Input

The mouse and keyboard are fine for many gamers, but a lot of people like to use joysticks, game pads, and steering wheels with all the buttons. You need a way to poll the joystick for input similarly to how you want to poll the mouse and keyboard. And don't forget about force-feedback capabilities! 

Input polling Bug ID: 4083501

Needed: Hardware-Accelerated Translucent Images

Although having translucent graphics isn't that important in 2D games, anti-aliased graphics are almost expected, and you need fast translucency for anti-aliased graphics. Currently, drawing a translucent image requires a read-and-set for every pixel in the image, which, of course, is rather slow. Video cards can do this quickly in hardware, so Java should provide a way to draw translucent images in hardware. Most of this will happen without any programmer intervention, but you also need updated APIs to support translucency in a VolatileImage. Luckily, hardware-accelerated translucent image support is coming soon. Chances are, it will be available in J2SE 1.5.

Needed: Higher Resolution Timer

As mentioned before, the timer that Java uses doesn't have the best resolution. Calling System.currentTimeMillis() has a resolution of 55ms on Windows 95/98/Me and 10-15ms on NT/2000/XP, which isn't granular enough for many games. 55ms means that the timer changes only 18.2 times per second, but you're trying to create games that run at 30 frames per second or higher. However, Linux and Mac OS X have 1ms granularity. Either the System.currentTimeMillis() method needs to guarantee 1ms resolution on all platforms or there needs to be a high-resolution timer API with 1ms or even microsecond resolution. 

Bug ID: 4478186

Needed: Hardware-Accelerated Graphics and Full-Screen on Linux

Even though Linux isn't the most popular OS for the home market, you still need hardware-accelerated graphics on Linux, including the capability to change the display mode on the fly and make full-screen games. Without it, Java games on Linux are inferior to those on other operating systems. Also, hardware-acceleration will greatly speed up Swing performance on Linux. Rumor has it that this feature is coming in J2SE 1.5. 

Bug ID: 4498974

Needed: Hardware-Accelerated 3D Included with the Runtime

Java3D is currently not included with the Java runtime and isn't available on all platforms-most notably, Mac OS X. First, for game developers to create cross-platform Java games, Java3D should work on all platforms that Java runs on. Second, the Java3D API should be included with the runtime. If that is not possible, there could be a "lite" version of Java3D included with the runtime because the Java3D API provides some functionality that not all developers need. Or, instead of a "lite" Java3D, a simple OpenGL-binding (such as GL4Java) could be included with the runtime.

Needed: HotSpot SIMD Optimizations

SIMD, or Single Instruction Multiple Data, is a processor instruction set that performs the same task on a set of data at the same time. For example, in one instruction, instead of telling the processor to add two numbers, you can tell the processor to add one array of numbers to another array of numbers, as in .

A SIMD instruction can do the same amount of work with multiple data that a SISD instruction does for single data.
A SIMD instruction can do the same amount of work with multiple data that a SISD instruction does for single data.

SIMD is great for things such as MP3 decoding, sound processing, image processing, software texture mapping, and speech processing, to name a few apps. The good news is almost all processors sold today have some sort of SIMD instructions capability:

At first, developers had to write in Assembly language to take advantage of these hardware instructions. Now, this isn't the case. Some modern C/C++ compilers can automatically make SIMD optimizations without any input from the programmer. The downfall is that if you compile your C/C++ code for a certain platform, such as the Pentium 4, it'll only run on a Pentium 4 or better. For a Pentium 3 or an Athlon, you'll need a separate executable. But Java is meant to be portable. When Java byte-code is compiled to native code with HotSpot, HotSpot is really competing with C/C++ compilers. So, HotSpot should include automatic SIMD optimizations. Of course, if implemented, HotSpot would have a few advantages over automatic SIMD optimization in C/C++ compilers:

Desired: More Font-Smoothing Options

Even though the Java platform has the capability to draw anti-aliased fonts, there are a few problems:

Although Swing is usually used for apps, in , "Interactivity and User Interfaces," we showed how Swing can be used for the user interface in full-screen games. Unfortunately, text in Swing components does not have any font smoothing, even if the operating system has font smoothing on by default. So, Swing components don't look as nice as they could. As far as font-smoothing techniques go, another technique besides anti-aliasing is called sub-pixel rendering. This is also called ClearType by Microsoft. Sub-pixel rendering takes advantage of the pixel layout of LCD displays. LCDs actually show three tall, thin sub-pixels for each pixel onscreen: one each for red, green, and blue. An example of this is in (in glorious black and white!). This figure shows how a single white pixel is composed of a red, green, and blue sub-pixel. Your eyes blend the sub-pixels so that the pixel appears white.

A single pixel on an LCD display is actually composed of three vertically oriented pixels: one each for red, green, and blue.
A single pixel on an LCD display is actually composed of three vertically oriented pixels: one each for red, green, and blue.

So, a completely white display would have a sub-pixel layout like the one shown in .

A completely white display is composed of alternating red, green, and blue pixels.
A completely white display is composed of alternating red, green, and blue pixels.

In a typical text representation, fonts are drawn with black text on a white background. With no font smoothing, every pixel is either completely white or completely black. For anti-aliasing, pixels on the edge of the fonts can be various shades of gray to help smooth the edges of the text. Sub-pixel rendering takes font smoothing a step further by taking advantage of the sub-pixel layout. Instead of turning each pixel either completely on or off, it turns each sub-pixel completely on or off, like in .

The difference between a font rendered without any anti- aliasing and a font rendered with sub-pixel rendering.
The difference between a font rendered without any anti- aliasing and a font rendered with sub-pixel rendering.

If you wanted to draw only the red and green sub-pixels, for example, you would draw a yellow pixel (red+green=yellow). The eye still blends everything to see black text on a white background. This is just the basic theory of sub-pixel rendering. It can also be combined with anti-aliasing for even better results. Of course, sub-pixel rendering isn't perfect for all situations. It really works best for black and white images on LCD displays (even though it helps on many CRT displays as well). Also, it works well for fonts because there are lots of high slopes in the letter shapes, but it won't help as much for shapes with low slopes. 

Sub-pixel Bug ID: 4726365
Anti-aliasing for Swing components Bug ID: 4808567

Other Possibilities

Here are a few more ideas that could make the Java platform better for games: