Axonometric Rendering Algorithms for Mobile Devices using J2ME

E R N I R E R L I N G S S O N

Master of Science Thesis Stockholm, Sweden 2008

Axonometric Rendering Algorithms for Mobile Devices using J2ME

E R N I R E R L I N G S S O N

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2008 Supervisor at CSC was Alexander Baltatzis Examiner was Stefan Arnborg TRITA-CSC-E 2008:093 ISRN-KTH/CSC/E--08/093--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

Abstract

This thesis examines rendering algorithms that use an axonometric projection to project a

three-dimensional environment that is described with images, onto a two-dimensional screen,

while ensuring that the displayed image gives the correct visual representation of the

projected environment. The algorithms use a mixture of sorting and Z-buffering techniques

that are adapted to use images, and not polygons.

All the algorithms are implemented with the Java Micro Edition (J2ME) development

platform, and their performance and memory-usage is compared in detail over a wide range of

mobile devices. The algorithms are compared in special test-environments, which include

moving objects, collisions, and some physical laws.

The results show that the sorting-algorithm performs extremely well, and requires very

little memory. However, it can’t guarantee a correct visual representation because of the

possibility of a circular dependency among the sorted elements. The other algorithms, which

are based on Z-buffering, have high memory requirements and only performed well on newer

devices, although they performed much better when using a back-buffer.

Svensk titel: Axonometriska renderingsalgoritmer för mobiler med J2ME

Referat

Den här rapporten undersöker renderingsalgoritmer som använder axonometrisk projektion

för att projicera en tre-dimensionell miljö som beskrivs av bilder på en två-dimensionell

skärm samtidigt som korrekt visuell representation är säkerställd. Algoritmerna använder en

blandning av sorterings- och Z-buffertekniker som är anpassade för bilder och inte polygoner.

Alla algoritmer är implementerade med utvecklingsverktyget Java Micro Edition (J2ME)

och deras prestanda- och minneskrav är jämförda över ett brett urval av mobiltelefoner.

Algoritmerna är jämförda i speciella testmiljöer som inkluderar rörliga objekt, kollisioner, och

vissa fysiska lagar.

Resultatet visar att sorterings-algoritmen presterar bra och behöver väldigt lite minne. Den

kan dock inte garantera rätt visuell representation på grund av att det finns möjlighet till

cirkulärt beroende mellan de sorterade elementen. De andra algoritmerna som är baserade på

Z-buffern har höga minnes- och prestandakrav och är därför bara användbara för nyare

mobiltelefoner, men gav dock bättre resultat med en back-buffer.

Table of Contents

Introduction………………………………………………………………………………… 3 Geometric Projections………………………………………………………………………5

Perspective Projections…………………………………………………………….…… 6 Axonometric Projections……………………………………………………………….. 7 Oblique Projections……………………………………………………………………... 8 Multi-view Orthographic Projection……………………………………………….…… 8

Axonometric Rendering……………………………………………………………………. 10 The Axonometric Environment……………………………………………………………. 11

J2ME implementation details…………………………………………………………… 12 Rendering Algorithms……………………………………………………………………… 14

Volume-overlap………………………………………………………………………… 14 Volume-sort…………………………………………………………………………….. 15 Depth-buffer algorithms………………………………………………………………… 16

Depth-buffer with volume-overlapping…………………………………………… 18 Depth-buffer with volume-overlapping and a heuristic…………………………… 18 Depth-buffer with volume-overlapping, a heuristic, and a back-buffer…………… 19 Depth-buffer with calculated depth-values………………………………….…….. 19 Depth-buffer with calculated depth-values and a back-buffer…………………….. 21

Test Programs……………………………………………………………………………… 22 The Testing Procedures…………………………………………………………………. 22 Test Program Definitions……………………………………………………………….. 23

First test program…………………………………………………………………... 23 Second test program………………………………………………………………... 24 Third test program…………………………………………………………………. 24

Test Results & Discussions………………………………………………………………… 25 With no rendering algorithm……………………………………………………………. 25 Volume-sorting algorithm………………………………………………………………. 26

The volume-sorting postulate is broken!…………………………………………... 26 Depth-buffer algorithm with volume overlapping……………………………………… 28

Depth-buffer with volume-overlapping and a heuristic……………………………. 29 Depth-buffer with volume-overlapping, a heuristic and a back-buffer……………. 30

Depth buffer with calculated depth-values……………………………………………... 31 Depth buffer with calculated depth-values and a back-buffer…………………….. 32

Memory Requirement Results…………………………………………………………... 33 Conclusions………………………………………………………………………………… 34 Further Research…………………………………………………………………………… 35 References…………………………………………………………………………………. 36 Appendix I: A short introduction to J2ME………………………………………………… 37 Appendix II: An overview of the test devices…………………………………………….. 39

3

Chapter 1

Introduction

With the growing power of mobile platforms, it is possible to do more computer science

research on these platforms. Because of the mobile device’s increasing screen size, the real-

time rendering of three-dimensional environments onto two-dimensional screens is a topic of

growing importance.

Conventionally, real-time three-dimensional geometry is represented with numerous

triangles, with triangle-occlusion based on the viewer’s position. There are, however, other

ways of representing three-dimensional geometry and one such way is to use a collection of

two-dimensional images coupled with a planar-geometric projection method such as

axonometric projection. With this projection method the viewer’s position is in the form of a

constant plane instead of a free point. The graphical representation of a three-dimensional

environment is more constrained with images rather than triangles because of the fixed

projection plane. However, it is probably a more practical method for mobile devices, as they

generally do not contain any special three-dimensional acceleration hardware. Environments

projected using an axonometric projection technique are referred to as axonometric

environments. A more detailed overview of these different planar-geometric projection

techniques will be given in chapter 2.

This thesis explores the practicability of several rendering algorithms for axonometric

environments. Some are based on well known graphical algorithms, such as Z-buffering1,

where occlusion is handled on a per-pixel basis. Others are based on a combination of new

and old techniques, such as Volume Sorting, which is a method of discovering the rendering

order of any set of objects within an axonometric environment.

All the algorithms are implemented and tested in Java Micro Edition (J2ME) that is

currently included in over 1500 devices2, which is the highest number for any mobile

development platform. In appendix I a short overview of J2ME can be found. Although the

conclusions are reached with the usage of J2ME, they hold relevance for other development

platforms as well.

The algorithms are compared on several levels such as, practicability, memory usage, and

performance in a specially constructed dimetric testing environment, which is a sub-field of

1 Edwin Catmull, A Subdivision Algorithm for Computer Display of Curved Surfaces, Utah University Salt Lake city department of Computer Science, 1974. 2 Data taken from http://www.jbenchmark.com, 2nd of.may, 2008

4

axonometric environments. Multiple tests are performed over a ubiquitous set of mobile

devices in a testing environment that also includes rudimentary physical laws such as gravity

and transfer of momentum.

The aim of this master thesis is to provide contemporary J2ME developers and other

mobile developers with scientific research data showing the practicality or impracticality of

axonometric-projection-based environments and their rendering algorithms. The goal is also

to inspire future research into this much neglected research area. It is difficult to find a good

existing reference on axonometric projection; most computer-science-textbooks mention the

topic only briefly and most research papers are old and do not consider the interesting

implications of applying the algorithms to mobile devices.

5

Chapter 2

Geometric Projections

In computer graphics one is often concerned with representing three-dimensional objects on a

two-dimensional display surface. Such two-dimensional representations are often obtained by

using planar geometric projections, which include perspective and parallel projections. These

projections are well known and have already been long established before the computer-age,

as can be seen in the figure below.

Figure 1: Leonardo Da Vinci´s masterpiece, “The Last Supper”3. This figure presents one of the first examples

of perspective drawing dating back to the 15th

century. The depth gives the viewer the illusion of actually being

in the room and watching the scene.

The choice of a projection to represent a three-dimensional environment on a two-

dimensional surface is determined by the intended purpose of the representation as well as by

the personal opinion of what is aesthetically pleasing and what is not. Choosing a projection

also usually includes a compromise between the conflicting goals of illustrating the general

appearance of an object, i.e. as it appears to the eye from a desired position, and that of clearly

indicating the shape and measurements of the object.

This thesis especially examines rendering algorithms that use the axonometric projection

technique, which is a sub-field of the planar-geometric projection techniques. A hierarchical

diagram of all the planar-geometrical projections existing can be seen in the diagram in figure

2 below. 3 The Last Supper, Santa Maria delle Grazie, Milan, c. 1495-1498, (The Bettmann Archive)

6

Figure 2: A diagram showing the hierarchy of all planar geometric projections.

As the figure above illustrates, there are several different sub-fields within the field of planar-

geometric projections. In this thesis I only consider algorithms that apply for the axonometric

projection, giving a short introduction of the other projections will give a clearer definition of

it.

2.1 Perspective Projections

A perspective projection represents an object, as an observer at a certain vantage point would

see it. An object appears smaller as its distance from the observer increases, and parallel lines

of an object converge in the drawing, as figure 3 demonstrates. Perspective projection divides

into three subcategories, one-point, two-point, and three-point projections depending on the

number of intersecting principal coordinate axes.

Of all the planar geometric projections, the perspective projection provides the most

realistic representation of an object for the observer, because it decreases with the distance

from the observer. It is, however, the most difficult to construct in a computer program as

different parts of the object are represented at different scales.

7

Figure 3: An example of a two-point perspective projection. Notice how the walls of the house each converge to

a distant point on the left and right side respectfully4.

2.2 Axonometric Projections

An axonometric projection usually represents an object so that three adjacent faces of it are

visible. Such projections are particularly well suited to illustrate objects composed mostly of

rectangular shapes. The axonometric projections are classified according to the orientation of

the projection plane, i.e. the angles between the projection plane and the coordinate axes.

As figure 4 illustrates, there are three types of axonometric projections:

• Isometric

• Dimetric

• Trimetric

4 The Mansard Roof, Edward Hooper, The Brooklyn Museum, New York

8

Figure 4: Illustrations of the different axonometric projections: isometric (left), dimetric (middle), and trimetric

(right).

In an isometric projection all the angles between the projected axes are equal, or 120 degrees.

This type of projection is used in numerous well-known computer game titles, such as Q*bert,

Marble Madness, and Civilization II. With a dimetric projection only two of the angles

between the projected axes are equal. This type of projection has been used in game titles

such as SimCity 2000 and Diablo, although it is often mislabelled as being isometric. A

trimetric projection has no equal angles between the projected axes. This type of projection

has been used in games such as Fallout and SimCity 4.

2.3 Oblique Projections

Oblique projections provide exact details of one face of an object facing the viewer. It has

almost the same range of applications as an axonometric projection, but is better suited to

represent cylindrical objects because receding parallel lines give the illusion of divergence.

Figure 5: Illustrating the different oblique projections, Cavalier (left) and Cabinet (right).

Oblique projections are classified into Cabinet and Cavalier projections depending on the

angle between the projectors and the projection plane, which can be 45 degrees or 64 degrees

respectively, as figure 5 illustrates.

2.4 Multi-view Orthographic Projection

Orthographic projection shows the exact shape of one face of an object and is generally

considered easier to draw on paper. Usually more than one view is required in order to get a

9

good representation of the whole object. Drawing more than one orthographic view is in fact

the definition of a multi-view orthographic projection, which is illustrated in figure 6. This

projection is practically used for engineering drawings of machines and for architectural

working drawings.

Figure 6: A multi-view orthographic projection describing the unique geometric shape.

The number of views required to adequately describe the dimensions of an object depends on

the complexity of its shape. A simple symmetrical object with rectangular faces can often be

described in only two views, while a more complicated object with inclined faces will need

more views.

10

Chapter 3

Axonometric Rendering

The figure below contains two equally sized rectangular boxes, where each box is rendered

completely, one after the other. There exist only two possible rendering schemes for this

scenario: A is rendered first and then followed by B, or the opposite: B is rendered first and

then A. As the figure illustrates, the two rendering schemes give the viewer a vastly different

perception of the boxes actual positions. Only one of these two possibilities correctly

represents the underlying dimetric environment and we want to devise an algorithm that

always picks the correct one.

Figure 7: The viewer’s perception depends on the rendering order of the boxes. If box A is rendered before box

B it seems that A is behind B and both lay on the same plane (left). In the opposite case it seems that box A is

laying above and before box B (right).

Note that although the figure above uses a dimetric projection, it does not necessarily imply

that the problem and the problem’s solution are bound to that projection. A dimetric

projection with the focus on the top-face was simply found to be the most aesthetically

pleasing and with good illustrational properties.

Figure 7 offers a simplified version of the bigger problem that any axonometric rendering

algorithm must solve, i.e. sorting the objects, or occluding them, so that they represent a

correct visual representation of the environment. A solution must be found that is applicable

to all three-dimensional environments, including complex ones with hundreds of moving

boxes with different sizes. It must preferably be efficient in terms of memory and

performance, while maintaining flexibility within the axonometric environment. This is

especially challenging since the algorithm is applied to mobile devices with limited resources.

11

Chapter 4

The Axonometric Environment

Since we are dealing with an environment projected with axonometric projection, all objects

within that environment can be described with a rectangular bounding. With the axonometric

projection it is only practical to describe objects with at least near-rectangular appearance5. If

every object has a rectangular bounding box, the problem of providing a correct visual

representation of the environment is simplified. This also simplifies other problems, such as

collision detection. Therefore the following important condition is defined:

Bounding box condition:

A rectangular bounding box, irrespective of the objects shape or size, must describe all

objects within the axonometric environment.

Note that objects that do not have a near-box like appearance can still be described with a

bounding box, but the boundaries of it might be far bigger than the actual boundaries of the

object enclosed by it. The shapes that produce the biggest difference between the boundaries

of a bounding box and the boundaries of the actual object are balls as illustrated in the figure

below. This difference sometimes results in the collision of two bounding boxes despite the

fact that the objects themselves are not colliding. One way of solving this is to perform two

collision checks, the first check determines if the boundary boxes collide and if that is true

then the second check determines if the objects themselves collide. But, unfortunately, any

further depth into this topic is beyond the scope of this thesis.

Figure 8: An example of a ball that is enclosed within a dimetric-bounding box.

5 Ingrid Carlbom and Joseph Paciorek, Planar Geometric Projections and Viewing Transformations, Computing surveys, vol. 10, No. 4, December 1978, page 474

12

4.1 J2ME implementation details

Unlike modern PC’s, contemporary mobile devices generally do not include any special

hardware that is specially designed to facilitate the rendering of polygons. That makes it very

probable that any implementation of an axonometric environment for mobile devices with

polygons is impractical. Therefore the J2ME implementation uses images that are divided up

into image tiles, as is illustrated in figure 9.

By reusing the same tiles over and over we greatly lower the memory requirements in

exchange for the performance overhead of repainting the same image multiple times on the

screen. This method is the norm among mobile developers because it is very important to

minimize the size of the mobile application as much as possible6. Mobile applications are

generally loaded into the mobile device over the Internet, which remains to this day a

relatively slow and expensive service. Therefore it is important to keep the size of a mobile

application as low as possible, and re-use images rather than create new ones.

Figure 9: All the boxes within the environment are constructed with image tiles. The leftmost part of the figure

shows the three tiles that are used to construct a box. The middle part shows a box with tile boundary lines after

the tiles have been placed onto it. The rightmost part is the box, as the viewer of it perceives it in the

environment. The tile sizes are selected as 16x15 pixels for the left and right faces and 16x16 for the top-face.

When constructed each box is cubic, or 16x16x16 pixels in volume.

The basic axonometric environment is defined as a hollow box of optional size with six

boundary walls (boxes), is illustrated in figure 10. By making it an enclosed environment, the

chance of any object exceeding the environment boundaries, and therefore possibly leading to

undefined behaviour within the environment, is prevented.

Objects within the environment are moved one at a time, and one axis at a time,

performing a collision detection check between the moved object and all the other objects

after every move. If a collision is detected, the moved object’s position is set at the boundaries

of the object that it collided with and the momentum transfer in the respective axis is

calculated between the objects. All collision are considered to be perfect elastic collisions, i.e.

6 Martin J. Wells, J2ME Game Programming, Boston (USA), Thomson Course Technology, 2004. Pages 297-301

13

the total kinetic energy of the colliding objects after the collision is equal to their total kinetic

energy before the collision. The environment is completely loss-less, i.e. there is no sort of

friction simulated within the environment and therefore the total kinetic energy of all objects

within the environment remains constant. Also, at the start of each rendering frame a constant

acceleration in the negative z-direction is applied to every object to simulate gravity within

the environment.

Momentum transfer formula for elastic collisions

m1 * v1,f + m2 * v2,f = m1 * v1,i + m2 * v2,i

Where m1 and m2 is the mass of each respective object. The velocities v1,i and v2,i are the

initial velocities of each object and v1,f and v2,f are their final respective velocities. This

formula can be applied for each axis separately.

Figure 10: The left image shows the dimetric environment with its six boundary boxes. Only the three boundary

boxes in the back are visible to the viewer, but the outlines of the invisible ones in the front are illustrated with

white lines. The right image shows a snapshot of the same environment as it appears to the viewer with 10

moving boxes of different sizes.

14

Chapter 5

Rendering Algorithms

This section gives a detailed explanation of the algorithms that are implemented with J2ME

on the mobile devices, they are intended to solve the problem presented in chapter three, i.e.

guaranteeing a correct visual representation of the three-dimensional environment. All the

algorithms are implemented in the environment that is defined in chapter four.

5.1 Volume-overlap

An object’s volume is defined as the extension of the objects rectangular bounding box

towards the environments origin. If another object’s bounding box is within this volume it is

said to be overlapping the original objects volume, or in the original objects volume.

Figure 11: Box A located on the floor within an environment projected with a dimetric projection (left). Box

A´s volume shown in red towards the origin, which is in the upper lower corner of the environment (middle).

Box B has been added into the environment and is located within box A´s volume but not vice versa.

Note that although the method is only illustrated on the floor plane in the figure above, it can

also include objects that might be located above it. In that case the volume expands in the

negative z-direction as well as the negative x and y directions illustrated in the figure. Also

observe that for any pair of objects it is not necessary that either objects includes the other in

its bounding box, as illustrated in figure 12.

15

Figure 12: An example of two objects (A and B) that do not include one another in their respective bounding

boxes.

Both the volume-sorting algorithm from 5.2, and the depth buffer algorithm from 5.3 use the

volume-overlapping algorithm.

5.2 Volume-sort

This is the simplest algorithm presented in this chapter, and is based on the following

postulate.

Volume-sort Postulate

We are given an array of n rectangular boxes within an axonometric environment. The array

is volume sorted and indexed from 1 to n. If we render each box in the array in the order of 1

to n that will always give a correct representation of the axonometric environment.

Initially, every box, x, is sorted into a box-array by iterating through the array until a box-

element is found that contains the current box, x, within its volume. The box, x, is then inserted

at that position, before the box-element. If no box-element is found that contains x within its

volume, the box, x, is inserted at the end of the array. After the initial sort, only the array-

position of moving boxes is updated. If a box has moved, it is removed from the box-array,

moved, and then re-sorted into the array by using the same type of insertion sort as in the

initial sort.

16

Formal Definition: Volume-sorting

We are given an array of n rectangular boxes, which is indexed from 1 to n. The array is said

to be volume sorted if the following invariant applies:

Every box i, such that i >= 1 and i <= n, is not within the volume of box j if j < i

In layman’s terms this invariant means that an object cannot include another object if that

object appears later in the array. When that is valid the assumption that was presented in the

postulate in this chapter is applicable. Unfortunately, under the duration of this thesis it has

become obvious that the invariant above can sometimes be broken because of a circular

rendering dependency of the boxes. You will find more detailed information about this in

section 7.2.1 in chapter 7.

The time complexity of this algorithm is ruled by the insertion sort since the volume

overlapping can be checked in O(1) time for each pair of objects. The worst-case time

complexity is thus O(n2), but the average time complexity of an insertion sort is n2/4.

This algorithm does not use any lookup tables or caches, and therefore does hardly require

any extra memory from the memory stack.

5.3 Depth-buffer algorithms

Figure 13: The final screen image is stored in a two-dimensional array storing the color value of every pixel

(´m´ pixels in width and ´n´ in height).

17

These algorithms are based upon the Z buffering algorithm, which is well known within the

field of computer graphics7. It handles object occlusion at a pixel-based level, through the

usage of tables, in the form of arrays that store the color- and depth-values for every pixel on

the screen. Whenever a new pixel is drawn to the screen, its depth value is calculated and

compared to the value already stored in the table. If the new pixels depth value is smaller than

the previous value the color table is updated, otherwise the pixel is discarded. The original

algorithm is usually implemented in an environment consisting of polygons, but for this thesis

the algorithm will be adapted to environments consisting of images. This is necessary because

the axonometric environment is made up from images, not polygons, as section 4.1 explained.

Every image-tile is stored in memory as an array of pixel color values, where all transparent

pixel values are ignored. When an image is drawn to the screen, the array with the color

values is fetched and then stored into the screen’s underlying color-value table pixel-by-pixel.

However, before storing the color-value of any pixel in the color-value table, a check is made

to ensure that it is closer to the viewer than any pixel previously stored at the same location. If

the pixel is determined to be closer it overwrites the previous pixel’s value, otherwise the new

pixel is discarded. When all images have been drawn into the buffer array it is flushed onto

the screen, and then initialised back to its original value.

This thesis mainly considers two different implementations of the depth-buffer algorithm.

The first implementation is introduced in section 5.3.1 and uses the volume-overlapping

algorithm to decide upon occlusion between overlapping pixels, not calculated depth-values.

Section 5.3.2 contains the second implementation, which is closer to the original Z-buffer,

because it uses calculated depth-values to handle occlusion.

Note that with these implementations, it is possible to support alpha blending of pixels

relatively easily by mixing the respective pixel color values, although this is beyond the scope

of this thesis. Because the depth-buffer algorithm is based on the Z-buffer algorithm, which

builds the color table pixel-by-pixel, we are assured that the final image on the screen will be

a correct visual representation of the axonometric environment.

If we assume that the pixel check can be done in O(1) time, then the theoretical time

complexity of this algorithm is O(k), where k is the number of processed pixels. Although the

two different depth-buffer implementations have the same theoretical time complexity, the

difference between the actual time measurements can still vary greatly. This is because of

practical factors, such as the different byte-code instruction length of the implementations, or

7 Edwin Catmull, A Subdivision Algorithm for Computer Display of Curved Surfaces, Utah University Salt Lake city department of Computer Science, 1974.

18

the different load on the memory bus and the CPU. By comparing execution time-

measurements between the two implementations, we will research the impact of these

practical differences.

Both the implementations are memory demanding, they require at least three arrays that are

each equal in length to the number of the pixels on the mobile’s display screen. The first

array, the color-buffer, contains the pixel color values that are flushed to the screen. The

second array, the check-buffer, contains the depth values that are compared to determine

occlusion. The third array, the reset-buffer, only contains null or zero values and is used to

optimise the time it takes to clear the check-buffer after each frame. If necessary, it is possible

to remove the third array and replace it with code that resets the check-buffer’s values in a

loop.

5.3.1 Depth-buffer with volume-overlapping

An important property of axonometric environments is that when two different bounding-

boxes both occupy the same pixel then one box must volume-overlap with the other. With this

property it is possible to implement the depth-buffer algorithm using the volume-overlap

algorithm from 5.1 to determine pixel occlusion.

In this algorithm, the check-buffer array consists of references to boundary boxes. Then,

for every drawn pixel, it is checked to see if it contains any value. If it does not, the pixel

color-value is added to the color-buffer and the box that contains the pixel is added to the

check-buffer. However, if the check-array does contain a value, it is used to discover if the

new pixel’s box volume-overlaps with it. If so, then the new pixel must occlude the previous

pixel, and therefore the new box overwrites the old box in the check-buffer, and the pixel’s

color value overwrites the old pixels value in the color-buffer. Otherwise, the old pixel

occludes the new pixel, and the new pixel is discarded.

5.3.2 Depth-buffer with volume-overlapping and a heuristic

Unmodified, the depth buffer algorithm from 5.3.1 is probably computationally expensive.

Checking if the volumes overlap for every pixel of each image-tile, will number in tens of

thousands to over a hundred thousand overlapping checks, depending on the screen size and

the number of overlapping boxes. If a cheap heuristic can be devised that lowers the number

of volume overlapping checks, it might yield a clear performance improvement. Such a

heuristic is devised based on the observation that for any image there is a high probability that

any overlapping check will involve the same pair of boxes as the previous check. Therefore

19

the heuristic always stores the last box used in an overlapping check and the check’s result.

Thereafter, before performing overlapping checks, a special check is made to discover if the

last overlapping result can be re-used for the current check. If successful, this heuristic should

remove a lot of redundancy, and perform better than the unmodified algorithm presented in

5.3.1.

5.3.3 Depth-buffer with volume-overlapping, a heuristic, and a back-buffer

Many computer games and graphical user interfaces use a background image buffer, or back-

buffer, which, if used correctly, can significantly improve the performance of any graphical

application. The idea is to render visible graphical objects into the back-buffer once, and

thereafter flush the back-buffer to the screen, instead of rendering them directly onto the

screen every frame. Better performance is gained, because only objects that move have to be

re-rendered into the back-buffer, which greatly reduces the number of necessary occlusion

checks between the rendering frames. Back-buffers also remove any image flickering, but that

is, however, not a problem in J2ME, because it already uses an internal back-buffer for that

purpose.

A simple back-buffer is added to the algorithm from 5.3.2 in order to discover the possible

performance improvements that are possible when it is coupled with an existing rendering

algorithm. During the first rendering frame of the algorithm all non-moveable objects are

rendered into the clear-buffer, continuing to use volume-overlapping to handle pixel

occlusion. With a back-buffer, the check-buffer is also cleared every frame, using an

additional clear-buffer that contains references to the boxes of the respective pixels. This

buffer is also filled in the first rendering frame, by storing the boxes from the respective pixels

from the clear-buffer. After both the clear-buffers have been initialised, only the movable

objects have to be re-rendered at every frame. This should give a significant performance

boost, because all axonometric environments contain at least the non-moveable boundary

walls.

5.3.4 Depth-buffer with calculated depth-values

This algorithm is the second implementation of the depth-buffer algorithm presented in this

thesis. Instead of using the volume overlapping method to discover which pixels are occluded

and which are not, direct pixel depth-values are calculated to handle occlusion. These depth-

values are then stored in the check-buffer, which always contains the depth-value of the

20

closest pixel at the respective screen location. This approach is closer to the original Z-buffer

algorithm, because it also uses calculated depth-values.

The depth values for each pixel are calculated using a depth function that is based on the

current axonometric projection of the environment. An obvious disadvantage with this

technique is that for every viewing angle, a new depth function must be devised, i.e. you

cannot use the same function for different axonometric projection angles. Consider the

difference between a classical isometric projection (chapter 2, figure 4), with all angles of

120°, and that of our dimetric projection, with the angles of 135°, 135° and 90°. With the

isometric projection the viewing plane is x + y + z = c, where c > 0, but with the dimetric

projection the viewing plane is x + y + 2z = c, with c > 0. This can be verified by comparing

the length of the vector from the farthest point to the closest point for each of the faces in

figure 14 below. Because we use a dimetric projection in our implementation, this function is

the basis of calculating the depth-values for every pixel.

Figure 14: Illustrating the depth values for each of the box’s faces. For this dimetric projection, the length

between the farthest point and the closest point for the top face is exactly double the length of the other faces.

The exact depth-value for any pixel is calculated by adding together the position of the box

that contains the pixel with the face offset of the respective image-tile, and the relative image-

tile offset. This is better illustrated in figure 15.

21

Figure 15: Adding together three values calculates a pixel’s depth value. The three values are: the box’s

position that is marked in red (left), the face offset to the image tile that the pixel resides in (middle), and finally

the local tile offset of the pixel.

5.3.5 Depth-buffer with calculated depth-values and a back-buffer

This algorithm is very similar to the one 5.3.4, except that here we use the algorithm from the

last section, 5.3.4, instead of the one from 5.3.3. Here, instead of storing an extra clear-array

in the form of a box-reference buffer, we store an extra depth-value buffer and fill the clear

buffer with values in a similar way as in 5.3.4, i.e. depth values from non-movable boxes.

22

Chapter 6

Test Programs

All J2ME SDK’s include an emulator that enables you to run your mobile applications on a

PC. The emulator includes a utility program that allows you to monitor the program’s

memory usage and see a detailed profiling of all the executed methods. It does not, however,

include a detailed emulation of the hardware on the different mobile devices; it merely gives a

generic emulation using the hardware from the PC that is running the emulator. All the tests

therefore have to be carried out on the mobile devices themselves in order to get a clear

performance measurement. The memory measurements, however, can be performed with the

utility program since they are independent of the used mobile device.

Six mobile devices were selected for testing purposes in this thesis: Nokia 6300, Sony

Ericsson k750i, Nokia 6111, Nokia N90, Sony Ericsson k610i, and HTC P3600. These

devices are ubiquitous, of varying age, and are good example devices of their respective

manufacturers, Nokia, Sony Ericsson and HTC. All the test programs are deployed onto the

mobile devices via Bluetooth. Please refer to Appendix II for further information

concerning the mobile devices used in this thesis.

6.1 The Testing Procedure

The testing consists of running a set of three specially constructed test programs for every

algorithm, and on each device. Each program runs for exactly 1200 frames, where every

frame updates the environment and then renders it. Subtracting timestamp values made at the

beginning and the end of each frame yields its execution time in milliseconds. At the end of

each test program, the frame execution time values are summed up and divided by the total

number of frames, to yield the average value. There is unfortunately some uncertainty

involved with these measurements because of the lack of control over the Java Garbage

Collector (JGC), and the vastly different Java Virtual Machine versions (JVM) on the mobile

devices. The unpredictability of the JGC means that some test-runs will have it running more

frequently and longer than others. The frequency and the efficiency of each JGC are

dependent on the JVM. Great care is taken under the construction period of the test programs

not to leave any memory-leaks. This minimizes the time that is lost due to memory de-

allocation, which can also vary between different mobile devices. Therefore only the JGC's

uncontrolled time overhead that is due to the mark and sweep method, which it uses to search

for un-referenced objects, is remaining. The total uncertainty introduced by the JGC is hard to

23

calculate, which is why an extra “algorithm” is performed on every test device that runs all

the programs without any algorithm at all. This provides us with much better data for each

mobile device, as algorithms (including the no-algorithm algorithm) are directly compared on

the same device with the same JGC and JVM, i.e. comparing results between devices is not as

accurate as comparing the results from the different algorithms on the same device.

6.2 Test Program Definitions

All the test programs are constructed in the dimetric environment that is defined in chapter 4.

Each room is 14x14x7 cubes in dimension that fits well to the common mobile screen

resolution of 240x320 pixels. All screenshot figures are taken using that resolution.

Figure 16: The empty frictionless environment with three walls transparent as explained in chapter 4 (leftmost

image). The First test program contains ten moving objects (middle image). The second test program contains

twenty moving objects (rightmost image).

6.2.1 First test program

The purpose of this program is to test planar collisions and movements with objects of

different sizes. Most current applications of axonometric environments involve mostly the

usage of moving objects within a plane, such as in the computer game Diablo.

Ten boxes are created with a random integer value for each dimension with the following

constraints, 1 <= x <= 2, 1 <= y <= 2, 1 <= z <= 3, where a value of one represents one cubic

length of a standard 16x16x16 pixel cube. Each box is then given a random x and y initial

acceleration value within the limits of –0,25 < = x <= 0.25 and –0,25 <= y <= 0.25. The

random dimensions and accelerations are then hard-coded into the program and reused on all

subsequent executions of it on all the mobile devices.

24

The number of objects remains the same throughout this test as no more objects are created

after the environment is initialised.

6.2.2 Second test program

This test is identical to the first test, except it adds the overhead of having twenty objects

instead of ten. The objects construction is performed in the same manner as in the first test

program and following the same constraints. The purpose of this program is to examine the

overhead of doubling the number of moving objects within the environment.

6.2.3 Third test program

Figure 17: These three screenshots attempt to illustrate the waterfall-like appearance of the third test program.

The boxes move from the top plateau in the positive y-direction towards the lowest plateau.

The third test is in a specially constructed environment containing a series of elevated

plateaus. Boxes of the dimensions x=1, y=1, z=2 are created on the top-plateau with an initial

acceleration of ay = 0,25. The boxes then travel across each plateau, with gravity pulling

them down, until they finally collide with the invisible front-left boundary wall. At that

moment they are removed from the environment and then re-created at their original position.

At any time there are approximately thirty moving objects in the environment, making this

the most computationally difficult test. This test also adds another dimension of

computational difficulty for the mobile devices: constant creation and destruction of objects,

which is in general a time-expensive operation.

25

Chapter 7

Test Results & Discussions

7.1 With no algorithm

Here are the measurement results of the execution times when using none of the algorithms

that are described in chapter 5, i.e. no attempt is made to ensure a correct visual

representation, and the objects within the environment are rendered in their original insertion

order. These numbers represents the best performance attainable without using a back-buffer,

i.e. the best execution times we can ever hope to achieve after adding a rendering algorithm to

an environment that uses no back buffering.

No sorting Algorithm Tests

0

100

200

300

400

avera

ge f

ram

e t

ime [

ms]

Test #1 37 66 177 194 17 27

Test #2 44 82 211 221 21 29

Test #3 69 122 339 339 37 36

Nokia 6300 SE k750i Nokia 6111 Nokia N90 SE k610i HTC P3600

Chart 1: Performance results from the tests performed with no rendering algorithm.

It is interesting to note the poor performance displayed by the Nokia 6111 and Nokia N90

especially, with only 2-6 frames per second measured. This puts a big question mark to the

possible practicability of an axonometric environment for older phone models. There are,

however, several other methods available to increase the performance, e.g. using a back-

buffer, which is explored in later algorithms. There also are several other methods possible to

increase the graphical performance, but those methods are beyond the scope of this thesis.

The best models in this test are obviously the SE k610 and the HTC P3600, with the

impressive measurements of 27-58 frames per second.

26

7.2 Volume-sorting algorithm

Object Sorting Algorithm Tests

0

100

200

300

400

avera

ge f

ram

e t

ime[m

s]

Test #1 37 65 192 190 17 27

Test #2 46 83 229 214 22 30

Test #3 64 123 345 332 32 36

Nokia 6300 SE k750i Nokia 6111 Nokia N90 SE k610i HTC P3600

Chart 2: Performance results from the tests performed with the volume-sorting rendering algorithm.

As we can see in the chart above, it is quite obvious that object sorting is an extremely

effective algorithm. In fact it is so effective that we get similar results in all tests as running

them without any rendering algorithm (chart 1). Unfortunately, it does not always give a

correct representation of the axonometric environment as the next section explains.

7.2.1 The volume-sorting postulate is broken!

Unfortunately, under the course of this thesis it has become obvious that axonometric

environments that put no restrictions on object movement or on object size break the volume-

sorting postulate from section 5.1. To demonstrate that it is truly broken consider the

following example with three objects.

27

Figure 18: An example of three objects and their correct representation, which is impossible to attain (left). The

scenario presented in the figure is as follows: Box C is resting atop box A and behind box B. The area of box C

that is occluded by box B is shown in red. The area of box B that is occluded by box A is shown in blue. The

area of box A that is occluded by box C is shown in green. The right figure shows the occlusion areas marked in

the corresponding colors.

The figure above contains an example with circular dependency that is impossible to solve

when rendering objects completely one at a time as the volume-sorting postulate assumes. To

prove that it is impossible to provide a correct visual representation with this set of objects,

we show that all six possible rendering orders of the three objects provide a false perspective.

1. A, B, C = the blue area and the red area are not occluded

2. A, C, B = the blue area is not occluded

3. B, A, C = the red area is not occluded

4. B, C, A = the red area and the green area are not occluded

5. C, A, B = the green area and the blue area are not occluded

6. C, B, A = the green area is not occluded

Therefore the conclusion is that it is impossible to guarantee a correct visual representation of

the axonometric environment using the volume-sort algorithm. Future research into this

algorithm, though, is justified as it performs so extremely well. Perhaps it is possible to

guarantee a correct axonometric representation with the following:

28

• Adding certain constraints to the environment

• Monitor the environment for circular dependencies and resolve them by splitting

objects up at the problem boundaries.

All in all this is a practical algorithm with problems that might or might not suffice to

discourage developers from using it, as users can often be quite forgiving of graphical errors,

and environments might be designed with a low possibility of circular dependency, e.g. with

only one moving object allowed.

7.3 Depth-buffer with volume overlapping

Depth Buffer Algorithm Tests

0

100

200

300

400

500

600

avera

ge f

ram

e t

ime [

ms]

Test #1 120 291 530 220 112 96

Test #2 152 389 0 290 140 122

Test #3 267 0 0 392 240 175

Nokia 6300 SE k750i Nokia 6111 Nokia N90 SE k610i HTC P3600

Chart 3: Performance results from the tests performed with the depth-buffer rendering algorithm. Observe that

the zeros are the results of tests that were never performed due to the slow results from previous tests and should

be considered to be extremely high numbers.

In its simplest form, this implementation of the depth-buffer, which uses volume-sorting to

handle pixel occlusion, is much poorer than the volume-sorting algorithm. Here we do,

however, have a guarantee of representing the visual environment correctly as we check each

pixel separately. However, with these poor measured results of only 5-11 frames per second

for the fastest mobile (HTC P3600) it is unlikely that the algorithm will be practically useable

in this form.

29

7.3.1 Depth-buffer with volume-overlapping and a heuristic

Depth Buffer Heuristic Tests

0

100

200

300

400

avera

ge f

ram

e t

ime [

ms]

Test #1 94 214 368 192 96 85

Test #2 108 255 0 213 111 95

Test #3 158 0 0 283 166 128

Nokia 6300 SE k750i Nokia 6111 Nokia N90 SE k610i HTC P3600

Chart 4: Performance results from the tests performed with the depth-buffer rendering algorithm with the

heuristic algorithm applied. Observe that the zeros are the results of tests that were never performed due to the

slow results from previous tests and should be considered to be extremely high numbers.

The heuristic algorithm was constructed to try to improve the average performance of the

depth buffer algorithm. When comparing the results above from chart 4 to the previous

results, which are without the heuristic, in chart 3 it seems that the attempt was successful.

The main problem, as always with heuristics, is that we can only confidently state that the

algorithm performs better in our axonometric test environments, but not in any other

axonometric environment. In the worst case, the heuristic might actually slow down the

average performance.

30

7.3.2 Depth-buffer with volume-overlapping, a heuristic and a back-buffer

Depth Buffer Tests with heuristic and backbuffer

0

50

100

150

Avera

ge f

ram

e t

ime [

ms]

Test #1 30 59 71 114 25 44

Test #2 44 99 140 127 41 53

Test #3 40 87 115 121 36 51

Nokia 6300 SE k750i Nokia 6111 Nokia N90 SE k610i HTC P3600

Chart 5: Performance results from the tests performed with the depth-buffer rendering algorithm with an

additional heuristic and a back buffer.

As the chart above illustrates, with a back-buffer, the performance results are much improved.

Comparing charts 5 and 4 we see that with a back-buffer the mobile devices perform

approximately four times faster than without one. However, this performance-boost can’t be

guaranteed for all environments because of the simple implementation of the back-buffer. In

the testing environment we use a “constant” viewing position, which means that the back

buffer never has to be refreshed because of screen panning. The extra computational load of a

back-buffer that supports panning is unfortunately not examined further in this thesis but is

left open for future research. It is interesting to note that both the Sony Ericsson k610i, and

the Nokia 6300 performed better with a back-buffer than the HTC P3600. The HTC mobile

has a more powerful CPU, as can be seen in appendix II, and has performed better in the

previous results. The current results imply that the memory access of the SE and Nokia

devices is faster than for the HTC device, at least when dealing with large amounts of data

buffers that back-buffer requires.

31

7.4 Depth buffer with calculated depth-values

Depth Buffer Tests with primitives

0

100

200

300

400

500

Avera

ge f

ram

e t

ime [

ms]

Test #1 96 219 361 222 98 66

Test #2 112 254 418 239 115 75

Test #3 166 382 0 328 169 98

Nokia 6300 SE k750i Nokia 6111 Nokia N90 SE k610i HTC P3600

Chart 6: Performance results from the tests performed with the Depth buffer-rendering algorithm that uses

primitives.

These results are from the second depth-buffer implementation that uses calculated depth-

values to handle occlusion. It is interesting to note how close these test results are to the test

results from 7.3.1, which were the results from the depth buffer algorithm that employs

volume-overlap and a heuristic. However, this algorithm is probably better since it does not

rely on any heuristics. Here the best results were attained from the HTC device, with 10-15

frames per second.

32

7.4.1 Depth buffer with calculated depth-values and a back-buffer

Depth Buffer Tests with primitives and back buffer

0

50

100

150

Avera

ge f

ram

e t

ime [

ms]

Test #1 32 54 64 122 25 42

Test #2 45 91 124 142 41 49

Test #3 41 82 104 133 38 47

Nokia 6300 SE k750i Nokia 6111 Nokia N90 SE k610i HTC P3600

Chart 7: Performance results from the tests performed with the Depth buffer-rendering algorithm that uses

primitives and a back buffer.

These results are very similar to the results attained in 7.3.2, but again, this algorithm is

probably better, since it does not rely on any heuristics. Just like in result 7.3.2, both the

Nokia 6300 and the SE k610i, are faster than the HTC device, which strengthens the

assumption that memory access is slower for the HTC device.

33

7.5 Memory Requirement Results

Memory usage in the first test room

0

500

1000

1500

Algorithms

[kb

]

Values 105 105 1048 1357

No Algorithm Object sorting Pixel depth Back buffered

Chart 8: The memory usage of the different algorithms in the first test room. These figures are calculated for

320x240 pixel screens.

As the chart above illustrates there is a tremendous difference in the memory requirements of

the different algorithms. The high memory requirements of the pixel-depth algorithms stem

from all the arrays that are equal in length to the number of pixels on the screen, e.g. for a

screen size of 320x240 you have 76,800 pixels, if the color values of each is saved in an

integer that equals 307,200 bytes for one array. Although mobiles generally have much

memory, the pixel-depth algorithm is a bit excessive. Fortunately, there are several methods

possible to decrease the memory requirements, but mostly at the expense of performance. One

such method is to remove the clear buffer and instead clear the table after each frame by

looping through the table values. That will decrease the memory requirements by 20-30%, but

with an unknown expense-factor to the performance.

34

Chapter 8

Conclusions

Building a practical axonometric environment is a complex task that involves several different

factors such as rendering, collision-detection, etc. In this thesis, we have concentrated on the

rendering aspect, i.e. producing algorithms that perform well and guarantee a correct visual

representation of the environment, while at the same time examining the general practicability

of an axonometric environment for mobile devices. With our goal we have been partially

successful. We have shown that axonometric environments are practical to implement on

contemporary mobile-devices. We have also examined several algorithm, some of which have

failed and some who are very promising. From our discoveries and the test results from

chapter 7, we have come to the following conclusions:

1. Using back-buffer technique yields an impressive performance boost that greatly

increases the practicality of creating practical axonometric applications for mobile

devices.

2. With the discovery of the possible circular dependencies in the volume-sorting

algorithm, only the depth buffer algorithms guarantee a correct representation of an

axonometric environment.

3. The best depth-buffer algorithm performance-wise is the one that uses calculated

depth-values instead of checking for volume-overlaps. In fact it is the equal or better

algorithm in nearly all comparisons, e.g. memory requirements, code-size, etc. The

only exception is that a new depth-value-function must be defined for each new

axonometric projection, while the other algorithm is directly usable for all.

4. The depth-buffer algorithm implementations in this thesis use too much memory for

older mobile devices. Therefore, if a practical version is to be devised, this problem

must be addressed in future versions of this algorithm.

Contemporary J2ME developers should try to use the volume-sorting algorithm on older

devices, and use the depth-buffer algorithm with calculated depth-values and a back-buffer for

newer devices. The back-buffer algorithm will probably need to be improved to support

panning. Although the volume-sorting algorithm is flawed, it is the only alternative proposed

by this thesis that is applicable to older devices.

35

Chapter 9

Further Research

This master-thesis has produced some promising algorithms and answered some questions

concerning the practicability of axonometric environments on mobile devices. There are,

however, many more questions and topics that this thesis is forced to leave unanswered for

now. Some possible venues of future research are:

• New algorithms. Given that only the depth buffer algorithms in this thesis guarantee a

correct representation of the environment, new algorithms should be considered.

Because of the similarities between polygon-based environments and that of our

axonometric environment, existing 3-D rendering algorithms and their adaptation

should be considered first.

• Combined algorithms. Often mixing several existing or new algorithms together,

where each algorithm is especially suited to a certain type of axonometric

environment, results in better average performance than using only a single algorithm.

• Pre-processing possibilities. In order to increase performance of an axonometric

environment, pre-processing techniques should be considered that are coupled with

existing or new projection algorithms. Perhaps it is possible to combine pre-processed

environment analysis with the object-sort method in order to reduce the possibility of

circular dependencies. The environment could be pre-analysed with possible problem

areas or objects identified with a prepared set of solutions, e.g. in the form of dividing

a larger box into smaller ones.

• Extended back buffer. The usability of a back buffer algorithm that supports panning

is immense but the performance expense of such an algorithm is unknown. A practical

back buffer supporting panning should be designed and implemented with new time

measurements results.

There are countless other research topics on axonometric environments, that look beyond the

rendering algorithms, available in this rich field of computer science.

36

References

[1] Edwin Catmull, A Subdivision Algorithm for Computer Display of Curved Surfaces,

Utah University Salt Lake city dept. of Computer Science, 1974

[2] Ingrid CarlBlom and Joseph Paciorek, Planar Geometric Projections and Viewing

Transformations, Computing surveys, vol. 10, No. 4, December 1978

[3] Martin J. Wells, J2ME Game Programming, Boston (USA), Thomson Course

Technology, 2004

[4] Eric Lengyel. Mathematics for 3D Game Programming and Computer Graphics,

Hingham, MA, USA: Charles River Media, 2003

[5] Ernest Pazera, Isometric Game Programming with DirectX 7.0, Muska and Lipman,

2001

Internet sources:

[5] http://www.jbenchmark.com/index.jsp (last checked may-2008)

[6] https://java.sun.com/javame/index.jsp (last checked may-2008)

37

Appendix I

A short introduction to J2ME

The current tool of choice for mobile software developers is J2ME (Java Micro Edition).

Java's popularity for handheld devices is mostly due to the strength of the platform

independence that java offers in a market where the number of devices and device

manufacturers is high. J2ME also does not require a developer’s license in order to use it or

develop commercial software with it. Sun and most mobile manufacturers offer an extensive

J2ME toolset, including method profiling and memory monitoring, to aid mobile developers.

Figure 19: High-level Architecture of J2ME CDLC/MIDP

8

The Java Micro technology is based on three elements:

• A configuration that provides the most basic set of libraries and virtual machine

capabilities for a broad range of devices, i.e. the CLDC configurations.

• A profile that is a set of APIs that support a narrower range of devices, i.e. the MIDP

profiles.

• An optional package that is a set of technology-specific APIs, such as Bluetooth.

A mobile device configuration if provided by the Connected Limited Device Configuration

(CLDC). There are currently two versions available, CLDC 1.0 and 1.1. The most obvious

difference being that version 1.1 supports floating-point numbers while version 1.0 does not.

The usual scheme is to combine the CLDC with the Mobile Information Device Profile

(MIDP). MIDP contains an extensive high-level API that is used by all mobile java

developers. MIDP 1.0 was released in 2003, while MIDP 2.0 was released 2005. Additionally

8 Image taken from http://java.sun.com/javame/technology/index.jsp

38

there exists a MIDP 2.1 version that was developed and especially supported by Nokia. All

MIDP versions are backwards compatible, which means that any programs developed with

version 1.0 will be supported on all java phones. The difference between versions 1.0 and 2.0

is that the latter version includes a basic 2D gaming API that offers mobile game developers

with several useful classes.

This thesis uses CLDC version 1.1 due to the floating-point calculations related to

movement of objects and the calculations of momentum transfers when objects collide. The

depth-buffer algorithms that are based upon the Z-buffering algorithm use the MIDP 2.0 API

because of the necessary API support of drawing an integer pixel color table onto the screen.

39

Appendix II

An overview of the test devices

The test devices are divided up into two batches of three devices each. The first batch contains

a standard set of mobile phones, where each mobile phone represents a certain time period.

• The Nokia 6300 was introduced in 2007 and heavily promoted in Europe for the

Christmas of that year. It is a cheap and powerful phone with appealing and classical

Nokia looks.

• The Sony Ericsson k750i got awards as a high-end phone, and was very popular in the

years of 2005/06.

• The Nokia 6111 is a budget phone from 2004 that includes many features such as

bluetooth.

Figure 20: First batch of test devices, Nokia 6300 (left), Sony Ericsson k750i (middle), and Nokia 6111 (right)9

The second batch of test devices contains feature richer and more powerful devices:

• The Nokia N90 is a smart-phone introduced in 2006, it includes powerful image and

video capabilities.

• The Sony Ericsson k610 was quite popular in 2006/7. It may not seem like much, but

the combination of a relatively small screen and top-notch CPU makes this one of the

top ten most powerful mobiles ever created that support java10.

• The HTC P3600 is a very powerful smart-phone and the only one of the test devices

that runs the windows mobile operating system, the other phones either run Symbian

or an operating system from the respective manufacturer.

9 Images at the courtesy of http://www.jbenchmark.com 10 Taken from http://www.jbenchmark.com

40

Figure 21: Second batch of test devices, Nokia N90, Sony Ericsson k610i, and HTC P360011

The table below shows a direct comparison between the mobile devices. It is interesting to

note that all the test devices have a processor from the same manufacturer, ARM. Most of the

market’s mobile devices contain ARM processors, including all Nokia and Sony Ericsson

mobile phones.

Processor JVM Hz Memory Screen Size (full size)

Nokia 6300 ARM 9 Jazelle 237 2097152 240x320

SE k750i ARM 9 Jazelle 110 1048572 172x220

Nokia 6111 ARM 7 Interpreter 47 2097152 128x160

Nokia N90 ARM 9 JIT 231 1250000 352x416

SE k610i ARM 9 AOT 213 3841888 176x220

HTC P3600 ARM 9 AOT 434 134217728 240x320

Table 1: Table of comparison between the test devices specifications

Performance-wise, the JVM can be just as an important factor as the CPU frequency, because

a good JVM greatly reduces the size of the java byte-code compared to a bad one.

11 Images at the courtesy of http://www.jbenchmark.com

TRITA-CSC-E 2008:093 ISRN-KTH/CSC/E--08/093--SE

ISSN-1653-5715

www.kth.se