High frequency Verlet
integration physics on iPhone
Fredrik S¨
oderberg
June 9, 2010
Bachelor’s Thesis in Computing Science, 15 credits
Supervisor at CS-UmU: Thomas Johansson
Examiner: Jonny Pettersson
Ume˚
a University
Department of Computing Science
SE-901 87 UME˚
A
Abstract
When Apple first introduced the iPhone it was thought by many to be groundbraking. The main visible difference was that the phone had no keypad, just a touch screen. Another interesting feature in this phone was the addition of accelerometers. With this the device knows the forces applied to it and therefore knows how it is tilted. In april 2010 Steve Jobs announced 85 million iPhone OS devices sold. This makes it a very interesting OS from a developers point of view.
This project aims to explore those two new key features and the iPhone OS by im-plementing a simplified version of the game Mad Skills Motocross by Turborilla. This is a fast paced sideways scrolling motocross game with demanding physics simulation. The physics is modeled via high frequency (1000 Hz) Verlet integration. Important aspects of the project are therefore also if the iPhone can handle the game and if it still will be a fun game considering the changes going from desktop to iPhone.
Contents
1 Introduction 1 1.1 Chapter overview . . . 1 1.2 Background . . . 1 1.3 Technical specifications . . . 2 1.4 iPhone platform . . . 3 1.4.1 Objective-C . . . 3 1.4.2 Memory management . . . 3 1.4.3 Accelerometer . . . 4 1.4.4 Touch screen . . . 4 2 Problem Description 5 2.1 Problem Statement . . . 5 2.2 Goals . . . 5 3 Methods 7 3.1 Preparations . . . 7 3.1.1 Theoretical preparations . . . 7 3.1.2 Practical preparations . . . 7 3.2 Tools . . . 7 3.3 Development plan . . . 8 3.4 Related Work . . . 8 4 Accomplishment 9 4.1 How the work was done . . . 94.1.1 Information gathering . . . 9
4.1.2 Scrolling backgrounds . . . 9
4.1.3 Loading a track from file . . . 10
4.1.4 Physics engine . . . 10
4.1.5 Bike interaction with track . . . 11
4.1.6 Bike controls . . . 11
4.1.7 Combine and polish . . . 13
List of Figures
1.1 Dekstop version of Mad Skills Motocross . . . 2
4.1 Rope test case with 120 sticks. . . 10
4.2 First control . . . 11
4.3 Second control . . . 12
4.4 Third control . . . 12
4.5 Fourth control . . . 13
4.6 Shadow from bike and track shading. . . 13
Chapter 1
Introduction
The main goal of this project was to create a playable level of the game Mad Skills Motocross[1] for the iPhone OS. This was done on behalf of the company Turborilla[2]. This chapter will introduce the reader to the background related issues of the project and shortly describe an overview of the report.
1.1
Chapter overview
This thesis is divided into the following six chapters
Chapter 1: Introduction - Introduces the iPhone platform and background of the project. Chapter 2: Problem description - Describes the project goals and methods used to
achive them.
Chapter 3: Methods - Describes the methods used for accomplishing the goals, what preparations were made and what tools were used.
Chapter 4: Accomplishment - Describes how the work was done and has some screen-shots of the implemented controls.
Chapter 5: Results - The results of the project are here presented.
Chapter 6: Conclusions - The conclusions that could be made from the results of the project are presented.
1.2
Background
Turborilla is a small company in Umea which developed the game Mad Skills Motocross (see figure 1.1), released in late 2009. It is written in Java and is available for Windows, Linux and Mac OS X. Because iPhone OS has a big potential market they were interested in seeing if this was a viable option for their game.
Myself, I had a MacBook and an iPod Touch G21 and was somewhat familiar with developing for iPhone OS. This felt like a perfect opportunity to take a deep-dive into the OS and learn more. I also had a good understanding of Java and knew much of the code
1Second generation iPod Touch
2 Chapter 1. Introduction
could be ported, so it did seem like something that would be doable within the scope of this thesis.
The physics engine in the game is based on particle physics with Verlet integration[7] running at 1000 Hz. How Verlet integration works is a paper itself, but it is a relatively stable and fast integration often used in game physics. The physics part is the reason the game is so demanding.
Figure 1.1: Dekstop version of Mad Skills Motocross
1.3
Technical specifications
An iPod Touch is essentially an iPhone without the phone cabability. It also lacks the GPS module. There are a couple of different versions (generations) of the devices and the most important difference, the processing power, is listed here.
iPod Touch G1, iPhone (2G), iPhone 3G - ARM1176JZ(F)-S v1.0 620MHz downclocked to 412MHz.[9]
iPod Touch G2 - ARM1176 v4.0 running at 532MHz.[6]
1.4. iPhone platform 3
They all have a screen resolution of 480x320 (landscape mode) and 3-axis accelerometers. The only means to controlling an application are by using the touch screen or the accelerom-eters.
1.4
iPhone platform
To develop for iPhone OS the only official supported way is to do it on a Mac OS X computer with an Intel chip.
1.4.1
Objective-C
The only supported language is Objective-C. This can be cumbersome since it is used almost exclusively in Mac development. Developers coming from other languages will find it different.
The most notable difference is the use of message passing between classes instead of direct method calls. However for the sake of simplicity it can be viewed upon as a method call. The following example sends the message alloc to the class ClassA which allocates memory for that object. Similar listing for Java is included assuming alloc() is a static method.
ClassA ∗ a = [ ClassA a l l o c ] ; // O b j e c t i v e −C ClassA a = ClassA . a l l o c ( ) ; // Java
The normal way to allocate an object in Objective-C is to call alloc and init which equals allocating the object and calling the ”constructor”.
ClassA ∗ a = [ [ ClassA a l l o c ] i n i t ] ; // O b j e c t i v e −C
ClassA a = new ClassA ( ) ; // Java a u t o m a t i c a l l y c a l l s c o n s t r u c t o r The notation might look weird at first glance but is something you’ll get used to. The real problem with the message passing is that the target of the message is resolved at runtime and must then interpret it. This adds an overhead which was quite noticably big in this project (see section 4.1.4).
The good news are that Objective-C can also use C++. This means for most parts you can use C++ instead and even mix C++ and Objective-C. The only time it is required to use Objective-C is when accessing the iPhone OS API, since these are mostly written in Objective-C, though some are also written in plain C.
1.4.2
Memory management
Memory management in Objective-C on the iPhone is quite similar to Java. The only difference is that the developer needs to manually send a retain message when an object is assigned to some other object and a release message when that object no longer needs the reference. When a retain message is sent a counter is increased and when a release message is sent the counter is decreased. When this counter reaches 0 the memory is freed.
4 Chapter 1. Introduction
Since the iPhone only has a limited amount of memory, no swapping like on desktops, it is important not to have memory leaks. Such poorly written programs will be terminated after a while when the memory gets too low. This is not something the user appreciates.
So just like in Java the memory management, with retain counters, makes sure you do not need to know the global scope of the memory, unlike C++. Just make sure you manage it correctly locally and it will behave similar to Java. The desktop version of Objective-C even has garbage collection just like Java.
1.4.3
Accelerometer
All iPhone OS devices have 3-axis accelerometers. This means it detects the force applied in X, Y and Z space. These might have been included to weigh up the fact they have no buttons, but are also a new interesting way of controls. Using the accelerometers as controls in programs can be a good way interact with the user.
1.4.4
Touch screen
The touch screen is the only other way, besides using accelerometers, of interacting with an application. Often virtual buttons and joysticks are created in applications as a means of control. The iPhone OS supports multi-touch, which means it can detect several clicks at the same time. This is a feature used in the now popular pinch-zoom2 technique.
Chapter 2
Problem Description
There is a big difference between a desktop computer and a phone, mainly the processing power. While the game runs smoothly on a low-end computer it will require a high-end phone to be able to handle the physics simulations and 3D graphics.
2.1
Problem Statement
The only requirement was that the game should be able to load a game track on which the user could drive the bike and the physics (bike) should behave like the desktop game would. This meant porting and running the physics at 60 frames per second (fps).
– Would an iPhone be able to handle the game and still be fun to play regarding the differences in controls and screen size?
– How many fps will it be able to run in?
– Would there have to be any compromizes done?
– What available libraries are there to be used for this project?
2.2
Goals
The main goals from Turborillas point of view was to get a proof-of-concept iPhone version of the game, ideally running at 60 fps. The other goal was to try out different controls for the game and conclude what would be best suited for this type of game.
I also added a secondary goal which was to lay out the differences in coding in Java for a desktop application and coding in Objective-C for an iPhone application.
Chapter 3
Methods
The method used for the project was first of all making the necessary preparations needed. This includes theoretical and practical preparations before start and making sure all the tools needed was available. After that a development plan was going to have to be done, and of course taking a look at related work to see if anything could be learned from that.
Reaching the secondary goal only required careful observations on what differs between the languages and devices and note that down.
3.1
Preparations
When dealing with preparations for a project it is important to include both practical and theoretical preparations. Practical preparations can be making sure you have the neces-sary hardware and workplace. Theoretical preparations can be making sure you have the development tools needed and making sure you have all needed information beforehand.
3.1.1
Theoretical preparations
Since I had previous experience with iPhone development I did not have to spend time on setting up and learning how to use the development environment, however OpenGL ES1
was going to be used with which I had no experience. I had to read up on that with the help of a developer blog[8] focused on OpenGL for iPhone.
3.1.2
Practical preparations
The project was going to be done at the Turborilla office where a monitor and keyboard was available but no Mac computer or iPhone device. Therefore all work was going to be done on my personal MacBook and iPod Touch connected to the external screen and keyboard available there.
3.2
Tools
To develop for iPhone the iPhone SDK needs to be downloaded and installed. This is a 2.3GB big file and includes everything needed. The following tools from the SDK were used
1OpenGL for Embedded Systems
8 Chapter 3. Methods
extensively.
– Xcode - the IDE.
– An iPhone emulator - integrated in Xcode. – Instruments - a profiler also integrated in Xcode.
3.3
Development plan
Creating the game was broken down into the following steps.
Gathering information - First thing to do is check out what graphics engines exist, be-cause using an engine usually saves lots of time.
Scrolling backgrounds - Next thing to do is get the parallax-scrolling backgrounds to work.
Loading a track from file - A track in the game is saved as a heightmap. This needs to be loaded and then displayed via some 3D rendering.
Physics engine - A very important part of the game is the physics engine. This gives the game a nice feeling and so was going to have to be ported from the Java source. Bike interaction with track - The bike needs to be rendered and able to interact with
the track, which means its physics elements must be able to collide with the track and act accordingly.
Bike controls - This is also an important part of the project because the iPhone can only be controlled via the accelerometer or the touch screen. Usually virtual keys are created on the screen. Gettings this right is crucial for the gaming experience. Combine and polish - As always in a project some time should be set aside for fixing
bugs and making sure everything works.
3.4
Related Work
There are some similar games already out on the iPhone in regards to the user playing a motocross and has physics simulations. Therefore it seemed plausible that an iPhone would be able to handle this game. One game called MX Mayhem2 was specifically looked at.
Though the gameplay is different the controls would be similar and therefore gave some ideas for the GUI of the controls (see section 4.1.6).
Chapter 4
Accomplishment
The work process is here described and finishes with a reflection over the time spent on each step.
4.1
How the work was done
The workflow consisted of following the outlined plan of gathering information and imple-menting the different parts.
4.1.1
Information gathering
There are some graphics engines available for iPhone OS, however most are either immature or lacks documentation. This is somewhat to be expected as the platform is still young. An interesting 3D engine was the SIO2[3] engine. This was tried out a bit and almost used but in the end fell short on documentation. Fortunately Cocos2D[4] was found which is a 2D engine written in Objective-C. It had lots of documentation and great reviews from the community. It also had built-in support for parallax-scrolling which was one of the features needed for the game. The only thing worrying was the fact that Cocos2D was a 2D engine and the track needed to be rendered in 3D. Therefore the first thing to test was displaying a 2D image and rendering a 3D cube on top of it. This was not only a success but also easy to do because the render function could be easily overridden and then standard OpenGL ES calls could be used.
Cocos2D was decided to be used.
4.1.2
Scrolling backgrounds
Because Cocos2D was used, adding the six layers of backgrounds was a farily easy task. The only problem was it did not have an automatic function for horizonally repositioning the parts that was scrolled by to achive an endless scrolling effect. This functionality was added. Also since the screen size is much smaller the graphics files were converted to a smaller size.
10 Chapter 4. Accomplishment
4.1.3
Loading a track from file
The track data came from the desktop version which was created with Java. This created problems when reading the data. Java stores data as big-endian1 whereas iPhone does not.
Also the way negative numbers were stored differed. After this was taken into consideration and fixed the data was converted to planes. Vertices and normals for the planes were created for the 3D rendering which uses the built-in OpenGL ES functions.
After the track was successfully rendered some additional magic needed to be done to make the boring 2D track 3D. The edges of the track needed to be smoothed out, which was done via a spline formula.
4.1.4
Physics engine
A subset of the physics engine was ported to Objective-C. There existed a test case consisting of a rope falling from the ceiling. The rope consisted of 120 sticks bound together. Since time was of the essence only the subset needed for the rope case was ported among with the test case itself.
A problem with Objective-C is that it has no version of namespace as Java and C++ have. This is probably why Cocos2D in its newest version has prefixed almost all classes with CC. Unfortunately it still had a class named Particle which interfered with a class named Particle in the physics engine. Because of this the name was renamed to TParticle (T for Turborilla).
After a successful port (see figure 4.1), a dissapointing frame rate emerged. Something that should be running at 60 fps was running at 11 fps. After some extensive profiling and searching the internet, the problem was found. Objective-C itself! See section 1.4.1 for an explanation, but in short, Objective-C’s message handling was too cpu intensive.
The fps-meter in the screenshot says 60 fps, but that is because it is running in the emulator. There is a huge difference in running an application on the emulator and on the device itself.
Figure 4.1: Rope test case with 120 sticks.
Luckily Objective-C also supports C++ and so another session of porting began, this time to C++. The result was a staggering 7-8 times faster simulation. The 120 sticks test
4.1. How the work was done 11
case was running at 60 fps and a 240 sticks version was running at 40 fps. With this the project could continue. A goal was now set to have the game running at 30 fps.
4.1.5
Bike interaction with track
This part took most of the time and was clearly underrated. The bike is built from con-necting particles with restraints and this demanded lots more of the physics engine. The scope of how much physics was used in the game was not at the start of the project realised. Most of the engine now had to be ported. This is basically what the bike-track interaction is, physics engine in motion.
Unfortunately there was still some problems with the frame rate and so some optimiza-tions had to be done. Rendering the track with VBO (Vertex Buffer Object) could have sped things up. According to an iphone developer blog[5] VBO rendering could speed things up five times. When using static data as VBO the data is buffered in the graphics chip, which would be perfect for this type of game because the data is not changing. Unfortunately this did not have any impact in this game, because the track rendering was not the bottleneck. However some optimizations in the physics engine gave result. Some dampening effects, which took about 25
Lastly the bike needed some graphics which was rendered with OpenGL. Also respawning the bike after a crash was done in this step.
4.1.6
Bike controls
A total of four different sets of controls were created. The graphics for the controls were drawn using Cocos2D CCSprite class which is an easy way to display an image.
Figure 4.2: First control
12 Chapter 4. Accomplishment
Figure 4.3: Second control
Second control (see figure 4.3). Left and right lean as virtual digital buttons in the left and right bottom corners. This means when a lean button is touched the rider will lean maximum to that way. This is the way leaning works in the desktop version of the game. Throttle/break is controlled by tilting the device forwards or backwards.
Figure 4.4: Third control
4.1. How the work was done 13
Figure 4.5: Fourth control
Fourth control (see figure 4.5). All virtual buttons just like in the first control scheme but with leaning as digital on/off buttons. There is also a fifth button available on all four controls which makes the bike jump. This was positioned on a button in the bottom center, or activated by shaking the device.
4.1.7
Combine and polish
The last coding week some small bugs were removed and a shadow following the bike on the track was added. A menu was also added for the different bike controls.
In figure 4.6 you can see the shadow from the bike on the track, and also some shading on the track itself.
14 Chapter 4. Accomplishment
4.2
Time spent
Statistics of how long every step took are here available thanks to daily logging. Information gathering: 2 days
Scrolling backgrounds: 2 days Loading a track from file: 6 days Physics Engine: 10 days
Bike interaction with track: 11 days Bike controls: 2 days
Polishing: 5 days Misc: 7 days
Chapter 5
Results
The results are divided up in primary goal result, the game, and secondary goal result, the differences in coding.
5.1
The Game
At the end of the project a successful proof-of-concept game was ready. An iPod Touch (second generation) was able to handle the game at 30 fps. Features included are:
– Draw the six layers of background using Cocos2D parallax feature. – Draw the controls as Cocos2D sprites.
– Draw the track using OpenGL. – Draw the bike using OpenGL.
– Draw the shadow of the bike on the track using OpenGL. – Update the physics and logic at 60 fps.
– Four different control possibilities.
5.2
Differences in coding
There are clearly some differences one has to think about when coding for iPhone. The language difference is one part and taking considerations of the iPhone device is another.
5.2.1
Languages
Since the iPhone OS only supports Objective-C developers has to be prepared to use it and handle it correctly, especially with regards to memory management.
The Objective-C language has some important shortcomings.
– No namespaces. If building something that could be reused like a kind of library, make sure the classes are prefixed to avoid name collisions.
16 Chapter 5. Results
– Message passing takes too much processing power in critical applications: When cre-ating a class whose purpose is to do demanding calculations, implement it as a C++ class to avoid processing power wasted on messages.
– When porting from Java to C++ it is important to remember to use the keyword virtual infront of methods when using polymorphism. I personally had some bugs because of this.
5.2.2
Desktop vs iPhone
Chapter 6
Conclusions
It would seem the iPhone is quite a capable device able to handle even demanding games such as this. I am quite happy with the results even though the journey there was filled with bugs and annoying Objective-C problems. As suspected it was not possible to get the game running at 60 fps, but a decent 30 fps was still considered a success.
After trying out different controls we came to the conclusion that using the accelerometer as a means to control a game should be used sparsely. Only use it when it fits the game type and not just because it is possible. Turning and tilting the device while playing a game can lessen the user experience. The fourth control scheme (see section 4.5) was the one all four people who tried it liked the best and this was the one using no accelerometers.
Because of the previously mentioned Objective-C shortcomings (see section 5.2.1) I would recommend using C++ classes as often as possible and only use Objective-C when necces-sary, which is when using iPhoneOS API’s. However, since Objective-C++ is quite good at mixing both languages a C++ class can still call Objective-C classes, so the need for creating own Objective-C classes should be minimal.
Although, since the memory management is more like Java, Objective-C could be easier than C++ to use when porting Java source code.
6.1
Limitations
The finished application has fulfilled the goals set up. However no error checking is done at the end of the game, which means the user can drive outside the track and crash the game. A not as important part was music and sound effects. These had to be skipped because of time constraint.
6.2
Future work
The basis for the game has been created but lots of work still needs to be done to create a full-blown game. Turborilla is quite happy with the results and will most likely continue this project and create a full port of their game.
Chapter 7
Acknowledgements
I would like to thank my supervisor Tobias Andersson and Peter Sundqvist at Turborilla who have been very helpful when problems arrived and for letting me be a part of this project.
Also a thank you to Thomas Johansson and Jonny Petterson at CS-UmU for making it possible for me do this as my thesis. It has been most rewarding.
References
[1] http://madskillsmotocross.com/. [2] http://turborilla.com/.
[3] http://sio2interactive.com/ (visited 2010-02-15). [4] http://www.cocos2d-iphone.org/ (visited 2010-02-15).
[5] Sunset Lake Software Blog. Lessons from Molecules: OpenGL ES. http://www.sunsetlakesoftware.com/2008/08/05/lessons-molecules-opengl-es (vis-ited 2010-02-15).
[6] John Gruber. The Faster CPU in the New iPod Touch.
http://daringfireball.net/linked/2008/11/25/new-touch-cpu/ (visited 2010-02-15).
[7] Thomas Jakobsen. Advanced Character Physics.
http://www.teknikus.dk/tj/gdc2001.htm (visited 2010-02-15).
[8] Jeff LaMarche. OpenGL ES from the Ground Up.
http://iphonedevelopment.blogspot.com/2009/05/opengl-es-from-ground-up-table-of.html (visited 2010-02-15).
[9] Blake Patterson. Under the Hood. http://toucharcade.com/2008/07/07/under-the-hood-the-iphones-gaming-mettle/ (visited 2010-02-15).
[10] Anand Lal Shimpi. The iPhone 3GS Hardware Exposed.
http://www.anandtech.com/show/2782/2 (visited 2010-02-15).
