内容摘要： Study on Improving Game Graphics in Java Platform ProgrammingRecently, the performance of Java platforms has been greatly improved to sa...
Study on Improving Game Graphics in Java Platform Programming
Recently, the performance of Java platforms has been greatly improved to satisfy the requirements for game development. However, the rendering performance of Java 1.1, which is still used by about one-third of current Web browser users, is not sufficient for high-profile games. Therefore, practically, Java game developers, especially those who use applets, have to take this into consideration in most environments. In order to solve the above problems, this paper proposes a portable window toolkit architecture called the CYC Window Toolkit (CWT) with the ability to: (1) reach high rendering performance particularly in Java 1.1 applications and applets when using DirectX to render widgets in CWT; (2) support AWT/Swing compatible widgets, so hence the CWT can be easily applied to existing Java games; (3) define a general architecture that supports multiple graphics libraries such as AWT, DirectX and OpenGL, multiple virtual machines such as Java VM and .NET CLR, and multiple operating systems (OSs) such as Microsoft Windows, Mac OS and UNIX-based OSs; (4) provide programmers with one-to-one mapping APIs to directly manipulate DirectX objects and other game-related properties. The CWT has also been applied to an online Java game system to demonstrate the proposed architecture. Copyright c 2006 John Wiley & Sons, Ltd.
INTRODUCTION
Since modern computer game development is becoming progressively more complex, many commercial games are made by large teams, typically ranging from 20 to 50 members
The productivity of programming teams plays a very important role of reducing the time to market, and this has influenced the mainstream languages of the game industry.
Before 1990, most games had been developed mainly in assembly languages to boost performance [2]. In the 1990s, the C language with relatively high productivity became popular in the game industry, since hardware and compiler technologies continuously improved the performance of the C language. For example, in 1993, ID Software Inc. [3] developed the game Doom in which most code was written in C. Furthermore, when compared with C, the C++ language increases the productivity with little loss of performance owing to the features of object orientation, such as maintainability and reusability.
Since Sun Microsystems (abbreviated as Sun) released the Java language [4] in 1995, Java has become increasingly popular owing to its higher productivity and portability than C/C++. A report [5] from IDC in 1998 showed that writing the code in pure Java instead of C++ increased the overall productivity by a factor of 30% and the coding phase alone by 65%. Since that study was made using Java Development Kit (JDK) 1.0.2, these figures could be greater today owing to the improved capabilities of the modernJava 2 Platforms StandardEdition (J2SE). Phipps [6] also presented a similar result, and concluded that Java was 30–200% more productive than C++. With the growth of the Internet, the Java applet together with its high portability—write once, run anywhere—has become popular on the Internet. These advantages have caused Java to become a candidate for one of the mainstream languages for game development. For example, Yahoo! Games [7], ArcadePod.com [8], CYC games [9–11] and RuneScape [12] use Java.
However, most of the above Java games are low profile games[], because Java programs normally have lower performance, especially in graphic user interface (GUI) components, also called widgets, which has made game developers hesitant to use it for high-profile games. In general, the performance of programs written in Java 1.0 is about 20 to 40 times slower than in C/C++ [13]. After several significant revisions in the Java Virtual Machine (JVM), the tweaked Java programs using J2SE 1.4 ran on average only about 20–50% slower than the tweaked C/C++ programs [13]. Unfortunately, the GUI part of early Java programs still performed slowly. Since most game programs, especially high-profile games, have intensive GUI operations, such as animation or complex scenes, it is critical to reach high rendering performance.
For high rendering performance,DirectDraw and Direct3D of Microsoft DirectX (or DirectGraphics in DirectX 7.0 and beyond)[14] or OpenGL (OpenGraphics Library)[15] are commonlyused to access specialized hardware features, such as direct access to the video memory in graphics cards, constructing 3D scenes and writing shader code. Thus, an important topic for high-profile game programs in Java is to incorporate DirectX or OpenGL into Java GUI design.
The earliest GUI mechanism in Java is Abstract Window Toolkit (AWT) [16]. In order to keep the cross-platform capability of Java, the AWT was designed to provide a common set of widgets which use the peer architecture [17] to maintain the look-and-feel in native operating systems (OSs), such as Win32 windows components [18] in Microsoft Windows and Motif [19] in UNIX-based OSs. Such widgets are called heavyweight components [20]. However, the GUI designed on one platform may look different on other platforms, and AWT widgets cannot satisfy the requirements of applications that require more complex widgets, such as trees and tables, and advanced graphics functionalities, such as pattern filling and color management.
In order to solve the above problems of AWT, Sun announcedJava FoundationClasses (JFC) [21] in 1998, which includes Swing and Java 2D. Swing provides more complex widgets based on lightweight support of Java AWT 1.1 that does not rely on the native widgets of the underlying OSs. Java 2D enables advanced 2D graphics functionalities, imaging, text and printing.
Although the functionalities of the JFC are generally good for applications requiring more complex widgets or advanced graphics, its implementation suffers from poor rendering performance when compared with heavyweight components. In order to improve rendering performance, Sun started to access specialized hardware features via DirectX in J2SE 1.4 [22] and OpenGL in J2SE 5.0 (or 1.5) [23]. However, the OpenGL-based Java 2D pipeline (abbreviated OpenGL pipeline) of J2SE
5.0 brings more bugs and is not usable in real applications. In order to resolve this problem, Java SE 6.0 introduces a newly designed OpenGL pipeline that provides much better stability and performance than that in J2SE 5.0 [24].
Although rendering performancein J2SE 1.4 and beyondhas been greatly improved,many hardware acceleration features, disabled by default, need to be configured carefully. Unless users explicitly configure proper properties in the Java control panel, the applet games will not fully benefit from hardware acceleration [25]. Thus, it is inconvenient for applet game users, especially for those without permission granted, to modify the system properties. Although signed Java applets can modify the system properties, the modifications also influence other Java programs running on the JRE.
Considering past work also related to the rendering performance issue, IBM’s Standard Widget Toolkit (SWT) [26] is an alternative to AWT/Swing which produces a more native-like appearance and a higher performance than the early Java versions, since all its widgets are designed as heavyweight ones. However, SWT does not completely take advantage of specialized hardware features for game applications, so it may perform inefficiently for high-profile games. In contrast to the native widget approach, other solutions incorporate DirectX or OpenGL into Java GUI design. Bellotti et al. [27] designed a set of APIs named DirectJ, which can directly access DirectX via the Java Native Interface (JNI), and thus achieved significant graphics performance improvement in J2SE. The OpenGL for Java (GL4Java) [28] wraps OpenGL APIs via JNI. However, the GL4Java has been outdated since the last release in 2001. Java binding for OpenGL API (JOGL) [29] is also a one-to-one mapping to the OpenGL APIs. The Lightweight Java Game Library (LWJGL) [30] is another library specifically tuned for writing games. Both JOGL and LWJGL are still in active development now. Java 3D [31] is a high-level API, which has OpenGL and DirectX implementations, for creating, rendering and manipulating 3D scene graphs. Using these libraries can greatly improve the rendering performance of Java. However, these solutions still suffer from the two problems discussed as follows.
First, although both DirectX and OpenGL have good rendering performance, they do not provide their own widget systems. Consequently, when mixing other widget systems, such as Win32 window components, with DirectX or OpenGL, the performance is still limited to that of the widget systems (or is even worse). In addition, the native widgets typically control their repainting timing and process, which may cause some undesired effects, such as flicking.
Second, many of the above solutions are supported on the Java 2 platforms only. Unfortunately, Microsoft Java Virtual Machine (MSVM) [32], which is in Java 1.1.4, is currently used by about
31.0% of browser users (calculated from the statistical data in [33] during the latest two months), while the percentages of JRE 1.4.x and JRE 1.5.0 are 24.5% and 41.8%, respectively. Thus, for game programmers, it is still important that applet games can be played in most environments.
Other reasons for using Java 1.1 are that:
•many applet games based on Java 1.1 were developed in the past when Microsoft Internet Explorer only supported Java 1.1.4 (for example, CYC games [9–11] still keep using the past MSVM for compatibility of their code);
•the J# language in .NET supports Java 1.1 only;
•most PDAs or mobile phones using Personal Java support Java 1.1 only.
In this paper, our approach is to enhance the graphics performance of Java 1.1 by using DirectX or OpenGL to render all widgets, figures, images and texts. We propose a window toolkit called the CYC Window Toolkit (CWT), a fast-rendering lightweight GUI toolkit that renders all its widgets via native graphics libraries. The CWT can automatically switch the hardware acceleration features in runtime, so users do not need to manually set the properties. In addition, the CWT also has the following features: • it supports AWT/Swing compatible widgets, and, hence, the CWT can be easily applied to existing Java games;
•it defines a general architecture that supports multiple graphics libraries (Java AWT, DirectX and OpenGL), multiple virtual machines (JVM and .NET CLR) and multiple platforms (Windows, Mac OS, UNIX-based OSs, etc.);
•it provides programmers with extra APIs to directly manipulate DirectX objects and other gamerelated properties, and, therefore, advanced programmers can control abilities of the DirectX without waiting for functionalities supported by Sun.
The rest of this paper is organized as follows. First, the architecture of the CWT is defined. Then, our implementation strategy and current status of the CWT are given, followed by experimental results and performance analysis, including a real application of the CWT. Finally, conclusions of our work are presented.
CONCLUSIONS
This paper designs a portable AWT/Swing architecture, called the CYC Window Toolkit (CWT), for high rendering performance for Java games development, especially for applet games written in Java 1.1.
The features of the CWT can be summarized as follows.
(1)High performance is reached in Java 1.1 applications and applets when using DirectX to render widgets. The CWT performs well in MSVM, which is currently used by about one-third of Web users. We have demonstrated the performance of the CWT by applying it to a real applet game, Mahjong [9]. In the benchmark we measured, the performance of the game running in MSVM was improved by a factor of 7.58, and was about 10% faster than the latest Java SE 6.0 (build 73) with full hardware acceleration enabled.
(2)AWT/Swing compatiblewidgets are supported.Hence, the CWT can be easily appliedto existing Java games.
(3)A general architecture that supports multiple graphics libraries such as AWT, DirectX and OpenGL, multiple virtual machines such as Java VM and .NET CLR, and multiple OSs such as Microsoft Windows, Mac OS and UNIX-based OSs is defined.
(4)Programmersare providedwith one-to-onemappingAPIs to directly manipulateDirectX objects and other game-related properties for advanced programmers.
The contributions of this paper include the following five points: (1) a general and portable widget architecture for Java game development has been defined; (2) CWT-AWT and CWT-DX3 have been implemented; (3) the high performance of the proposed design has been demonstrated experimentally; (4) the performance inconsistency in Java versions has been pointed out; (5) the usability of the CWT by applying it to a real applet game, Mahjong, has been demonstrated.
Future extension includes OpenGL implementation and DirectX 9.0 implementation. In the former, since OpenGL are available on many platforms, the OpenGL implementation is better than DirectX implementation for cross-platform consideration. In the latter, since the .NET J# can access DirectX 9.0 via built-in APIs and Microsoft provides tools to convert Java 1.1 code into J# code, using .NET J# is another alternative so as to access the latest DirectX.
