Comparing M3g and Jsr-239 for 3D Games Programming
Total Page：16
File Type：pdf, Size：1020Kb
COMPARING M3G AND JSR-239 FOR 3D GAMES PROGRAMMING Andrew Davison and Sophie Radenahmud Dept. of Computer Engineering Prince of Songkla University Hat Yai, Songkhla 90112, Thailand E-mail: [email protected] KEYWORDS The demands placed on a 3D graphics API are substantial: one major issue is abstraction M3G, JSR-239, OpenGL-ES, Java, 3D, games, versus control – how much of the growing comparison hardware and software complexity should be exposed to the programmer? Another question is how the API should deal with device ABSTRACT variety: should it attempt to fall back on (slow) We compare two graphics APIs for software emulation when necessary hardware programming 3D games in Java on mobile is absent, or should it simply refuse to work? devices: M3G (Mobile 3D Graphics API for Java ME is currently the most popular Java, JSR-184) and JSR-239 (a Java binding programming language for mobiles (it has for OpenGL ES 1.x). We have developed a been estimated that 1200 million phones were series of casual games (a puzzle game, a running Java in 2006 (Evans et al. 2006)), so simple FPS, a strategy game, and others) using how should a 3D API be integrated with Java, the versions of M3G and JSR-239 available in and with its myriad extensions, especially Sun's Wireless Toolkit 2.5.1, and use them to those related to graphics? compare the APIs in three areas: suitability for casual games programming, ease of We consider three broad API issues in this performance tweaking, and API and Java paper: suitability for casual games integration. programming, ease of performance tweaking, and how the API and Java are combined. We do this by referring to our experience in INTRODUCTION developing a range of casual games using M3G (Mobile 3D Graphics API for Java, JSR- Mobile gaming is in the midst of a minor 184) and JSR-239 (a Java binding for OpenGL revolution, driven by advances in graphics ES 1.x) in Sun's Wireless Toolkit 2.5.1. We processing (FPUs, GPUs), new interfaces also discuss what the future holds for M3G and (high definition video, touch, spatial sensors), JSR-239 (i.e. in M3G 2.0 and OpenGL ES and improved networking (GPS, faster 2.0). wireless). These improvements are encouraging new forms of gaming to appear, relying on persistent network connectivity, CASUAL GAMES mobility, parameters derived from the physical environment, and the episodic nature of Casual gaming is ideally suited to mobile communication. 3D graphics are closely linked devices: simple gameplay, action in short to these themes as a means of representing and bursts, no long-term time commitment or enhancing the user's interface to the 3D world. special skills required, and comparatively cheap game production. Casual gaming is also But there are problems: device fragmentation appealing to people outside the usual gamer is accelerating, with an ever widening range of demographic, a potentially massive audience. CPU speeds, memory sizes, screen resolutions, color depths, power consumption, non- Our examples include a puzzle game standard user interfaces, audio and video types, (CubeFinder), a simple FPS involving and variations in hardware support for floating penguins, a strategy game (Tic-Tac-Toe), point numbers and advanced graphic written in both M3G 1.1 and JSR-239. We processing (such as shaders). have also implemented a number of smaller MIDlets to test different aspects of the APIs: a model viewer, an animated scene, a particles demo, and examples using skinning and technique for grouping instructions for shape morphing. Figure 1 shows screenshots from creation. In OpenGL ES, the programmer some of the games and demos. defines arrays for a shape’s vertices, normals, colors, and texture coordinates (Astle and Durnil 2004). Another significant loss are the GLU and GLUT utility libraries. GLU includes convenience functions for such tasks as positioning the camera, setting up the viewing volume, generating basic shapes, and texture mipmapping. GLUT is mainly utilized in OpenGL applications for its I/O support; in JSR-239 that is handled by Java ME’s GameCanvas. OpenGL ES differs from OpenGL in its support for fixed-point numbers in addition to floats, to better match the limited hardware of smaller devices. Its 16.16 fixed-point data type utilizes the first 16 bits for a signed two’s compliment integer, and the other 16 bits for a fractional part. A shape defined using fixed- point vertices should render much more quickly than one employing floats. OpenGL ES only has primitives for creating shapes out of points, lines, or triangles; polygons and quadrilaterals (quads) primitives are missing. OpenGL ES is a ‘moving’ specification, with Figure 1. Casual Games and Demos three incarnations at the moment. OpenGL ES 1.0 is based upon OpenGL 1.3, OpenGL ES 1.1 is defined relative to OpenGL 1.5, and These M3G and JSR-239 examples can be OpenGL ES 2.0 is derived from the OpenGL found at the first author’s websites: 2.0 specification. http://fivedots.coe.psu.ac.th/~ad/jg/ and http://fivedots.coe.psu.ac.th/~ad/jg2/. OpenGL ES 1.1 includes support for multi- texturing, mipmap generation, and greater These applications were developed by a control over point rendering (useful for particle programmer new to M3G and JSR-239, and systems). OpenGL ES 2.0 is a more radical our comments here are based on his logbook departure, employing a programmable notes. Our intention was to gain the rendering model based around shaders, with perspective of a programmer new to these only floating point operations. The motivation APIs, albeit one with several semesters behind this design is the belief that mobile experience of Java and desktop OpenGL devices will very shortly have the rendering programming. power of today’s desktop and laptop machines (Munshi et al. 2008). AN OVERVIEW OF JSR-239 The GLBenchmark site (http://www.glbenchmark.com/result.jsp) JSR-239 is a Java binding around OpenGL ES includes a long list of OpenGL ES devices (OpenGL for Embedded Systems) which is (including Symbian devices, the PlayStation 3, itself a subset of OpenGL aimed at smaller Nintendo's GameBoy DS, and the iPhone), and devices such as mobile phones, PDAs, and their results against its benchmarking software. games consoles (see As of August 2008, only a few high-end Sony http://jcp.org/en/jsr/detail?id=239 and Ericsson phones support JSR-239 (Hellman http://www.khronos.org/opengles/). It is small 2008). (around 50 KB), and yet its capabilities are very similar to OpenGL’s. The most obvious loss of functionality is probably the OpenGL glBegin()/glEnd() AN OVERVIEW OF M3G SUITABILITY FOR CASUAL GAMES PROGRAMMING M3G (the Mobile 3D Graphics API) was developed as JSR 184 M3G’s scene graph makes programming much (http://www.jcp.org/en/jsr/detail?id=184), and easier for novices (and even for experienced is currently at version 1.1. Version 2.0 is in programmers) because it emphasizes scene development as JSR 297, with the aim of design rather than rendering, by hiding the adding programmable shaders and other underlying graphics pipeline. A scene graph advanced features naturally supports complex graphical elements (http://jcp.org/en/jsr/detail?id=297). such as 3D geometries, the camera, and lighting. M3G provides two ways for developers to draw 3D graphics: immediate mode and At the implementation level, the scene graph retained mode. In immediate mode, commands can be employed to group shapes with are issued directly into the graphics pipeline in common properties, carry out frustum culling, a similar way to OpenGL ES. However, it’s scene management, level of detail selection, most common for programmers to utilize execution culling, and batching of graphics retained mode which employs a scene graph to operations – all optimizations which must be link the geometric objects in the 3D world into coded directly by the programmer in OpenGL a tree structure, and specify the camera, lights, ES. However, it is unclear whether different and background (Höfele 2007). phone manufacturer’s M3G implementations actually support these optimizations (Pulli et At the lowest level, M3G deals with concepts al. 2005). similar to those in OpenGL ES, but the scene graph combines and hides these features inside A very common coding requirement in current higher-level graph nodes. For example, vertex 3D games is to mix-and-match 3D and 2D, and index buffers are combined into Mesh utilizing 2D images for overlays, backgrounds, objects; textures, materials, and other and game characters. The switching between rendering parameters form Appearance modes that this entails can slow down objects, and Group nodes hierarchically rendering by as much as three times (Pulli et combine transformations. al. 2007a), and so it’s necessary to structure code so that mode switching is minimized. In M3G offers keyframe animation that can be M3G, the Appearance node possesses a layers attached to almost any property of any object. mechanism for ordering rendering. For It also supports vertex deformation through instance, it’s easy to specify that overlays are morphing and skinning. There is a compact, drawn first, followed by objects further back in binary M3G file format that can store anything the scene. M3G’s 3D rendering is based on a from complete 3D animations and scene bind-render-release sequence, which makes it graphs down to individual objects or their clear when 3D rendering begins and ends, and components. so makes it much harder to inadvertently mix M3G can be implemented on top of OpenGL 2D and 3D processing. ES (although this is not a requirement), and the The M3G bind-render-release mechanism will resulting relationship between M3G, OpenGL also be useful for integrating 3D rendering ES, and Java ME is represented in Figure 2.