For about a week now I am owner of an iPad and it is actually pretty nice. Air Video Server allows me to watch all my stuff on my couch or bed and some of the games during Christmas sale are pretty nice, especially Dungeon Defenders and Angry Birds of course.
So, as I am a Developer I just want to develop and test some stuff on my iPad, to get into the iOS environment and broaden my horizon. Just out of curiosity. But the thing with nearly all Apple products in general is: They work fine… in their controlled ANDclosed environment!
If you want to develop for iOS you actually have to own an Intel Mac (i.e. Mac Mini, Macbook etc.). At least this is the only official way. There are some other possibilities such as with the Dragonfire SDK that builds a whole SDK for iOS development on Windows based on “normal” C/C++ or to use engines such as Unity and Shiva3D that deploy onto iOS (actually Flash CS5 also provides an iOS publishing profile). But this is not what I want, I just want to try some things and get into the normal iOS development with XCode and Objective-C.
So as I decided to not follow some of the other ways I needed to get hold of a Mac Machine. But I am not willing to pay at least 600 for a Mac Mini just to “play around” with iOS. So I had to find a way to install Mac OS X Snow Leopard on my machine. As this is not supported by Apple and a little tricky I did not want to start installing it directly to my notebook but thought about trying it in a virtual machine. “Good thought” you might say… but tricky as I noticed!
I chose VirtualBox as the Virtual Environment to test an installation. I did some googling and actually found many MANY resources, tutorials and board messages explaining how to do it. I am pretty sure I read nearly all of them and experimented for about 3 days to get it running… day and night (got no sleep during that time as I wanted it to run). But all the time something went wrong. That one didn’t boot! The other one wouldn’t get my network card right. Audio is still a big problem… and so on and so forth. But all of a sudden, as I was already giving up (really!!!) I found two excellent WebSites and Tutorials that got it working for me.
The one that started the effort again was flyNflip. It was the first very clear and simple tutorial how to get started. That was the first easy tutorial that got me to a “just working” installation. The only thing you need is to get hold of a Snow Leopard DVD. I got an update Version, it’s not too expensive. But it wouldn’t boot! What did I do wrong? Going through the comments I found the second WebSite at Sysprobs. It showed nearly the same steps how to install MacOSX in a VirtualBox but went a little further. It explains the EFI problem. It gives examples and further tutorials for getting rid of issues and more.
So now I have a running MacOSX Snow Leopard running in my VirtualBox. It’s also up to date (10.6.5) and actually somehow smooth for a virtual machine. Currently I am installing XCode and the iOS SDK (as you can see on the picture) and I hope everything will work out. If so, maybe I will post some stuff about iPad development…
Nevertheless, I am still very curious about why Apple does try to prevent you to explore MacOSX on other Machines (actually I am pretty sure I know why ^^’). But at least for developers that want to develop iOS Apps on a Windows or Linux Machine they should give out a possibility to do so. I would never buy a Mac Machine just to do so but I am very curious to try it and maybe develop the next #1 App ^^. They nearly lost me during the process and what I did is actually neither supported nor endorsed by Apple. I hope I won’t get into trouble but as I am owning an iPad and want to give something back I hope not.
So, I will get back to my MacOSX installation (XCode and iOS SDK installation is nearly finished) and hope I provided two good resources for others that think like me.
*UPDATE* XCode and iOS SDK installed. Works fine! But I have trouble if I want to set a widescreen display resolution. 4:3 works fine (e.g. 1280×1024), widescreen has some problems (e.g. 1440×900). It still boots but the redrawing of the window is somehow messed up.
Greetings to all of you. Unfortunately long time no “port” see! I had a lot on my mind (something got posted beneath ^^) and a lot to do (many travels, many projects, new horizon). But now I am back in full glorious “in”sanity to enhance your (Android) imagination ^^#
So, first let’s recapture some things about my NeHe Android Ports: To my surprise they were accepted good and got some publicity. I am happy about that… not so much that I had too little time to continue the series like I hoped for. But now I am back and will continue to translate as many NeHe lessons as possible.
But first, I uploaded another port but no NeHe Lesson. The new port is based on code from Apron and his OpenGL tutorial codes and deals with Stencil Shadows. This is definitely something interesting and missing besides what is covered by the NeHe tutorials so far. Therefore, I decided to do this first and then continue with other ports. So, head over to the new section of general Android tutorials and ports under Projects and check out finest stencil shadows on your phone.
PS: I will continue with the NeHe lessons but I will also keep an eye open for other feature/functionality tutorials that could be interesting to know about and are relevant for 3D development on mobile phones.
As most people know I pretty much dig Android. I also have been a friend of OpenGL. As I come from the Java side (we have cookies ^^’) and there are two good wrapper implementations with JOGL and LWJGL, I found the perfect combination in OpenGL on Android, hence the tutorial ports.
Over the time I did some tests on Android. Not only with OpenGL but mainly overall to see what could work and how. Unfortunately Android is far from perfect (what ever is?) and has some issues also affecting OpenGL development on Android.
3D Games on Android… Games are probably the main market working with 3D on Mobile Phones nowadays. On the iPhone we have some great examples of cool and nice looking 3D games such as Ravensword and many others. They look good and also run very smoothly (especially on a 3GS, loading times are most of the times much better).
Now, for Android we also have some good Game examples with the just announced winner of the Android Developer Challenge 2 in the category of games: Speed Forge 3D. The really beautiful WipeOut clone gives you a nice 3D game example on Android. Another example is Mystique by Bendroid. The 3D Ego-Survival-Horror in the style of Silent Hill and The Ring is sure to give you some creeps if you play it in a dark room, at night, feeling lonely.
…and the issues!
Now if you compare Speed Forge 3D or Mystique with Ravensword or Gameloft’s upcoming N.O.V.A you probably will get jealous and drool all over the videos. No question: SF3D and Mystique are great, Kudos to the developers, but compared to the iPhone they are far behind.
The big question should be: Why? And the answer is neither simple nor a single one in my opinion.
1. Heterogeneous Phone Market
One big thing coming up with the release of new Android handhelds is the inconsistency throughout the phones. Android itself is a specification and a referential implementation. Now, most phone manufacturer alter some things or add their own implementations of something such as OpenGL. Therefore, it is already the case that with every new release of a mobile phone based on Android you see updates of many Apps popping up because of problems or even crashes on the new device.
Let’s have a look at Speed Forge 3D: I have a HTC Magic and it runs… OK. Not absolutely fluently but playable. Now, a friend of mine has a Samsung Galaxy (or i7500) and he can barely play it until it crashes. Now the Droid from Motorola entered the market with another graphics chip and a larger screen. Many new “properties” to test against and to deal with. The iPhone on the other side may have been updated over the time but the environment stayed nearly the same. And something that runs on the 3GS will also run on the 3G, just load a little longer. So, as time goes by more and more Android devices will come out and will further diverse the market.
2. The Dalvik VM
As always when it comes to Java you will hear people say:
It’s slow because it’s Java!
Java will always be slow!
Forget Java, use the NDK!
(just saw the same posts pop up on the newsgroups and forums again)
They will argue that a Virtual Machine can never give the speed you need (some also tend to forget that .net is a VM interpreted environment). They will argue that the Garbage Collector slows everything down. And if we look back about 10 years they really had a point, but nowadays that may not be total crap but is just not that easy to say.
First of all let’s have a look around at Java-based 3D games, based on the very popular, updated and fast libraries JOGL and/or LWJGL. There would be the experiment Jake2: A Quake2 clone made in Java based on JOGL and LWJGL to have a comparison. If you have a look at the benchmarks you will see it is hard to argue that Java is that slower over the native implementation. And engines such as jMonkeyEngine support the Java faction. The demos over there such as Spirits and other games like Trible Trouble and Poisonville on the other side show that there are very good possibilities to use this object-oriented programming language as your development base.
The thing is that not Java per sé is the problem but as with every programming language the code optimization and the execution environment, in this case the Virtual Machine. Even Tim Sweeney from Epic Gamessuggests that functional programming and Garbage Collection is the future. The newest Sun Java VM and other VM implementations show what is possible to do with optimization within a managed environment. A good Garbage Collector (GC) and a very good Just-in-Time (JIT) Compiler such as in Suns current Java implementation speed up not only the application but also development itself because of less time spending for the memory management. But why still the speed problems? As already said, even if Java is interpreted and helps with the memory management you still have to think about what is happening beneath. Most applications tend to just create one instance after the other and do not really care about memory management. This may work on a desktop system but will bring problems to you on Mobile Phones. Things like weak references, caches, volatile and transient are forgotten but highly important terms in Java development. Especially Mobile Applications still have to really care about memory even with all this technically highly fledged phones. Care about the memory more than about computation on modern smartphones.
Nevertheless, even with these more or less “simple” tricks Android still has some problems that you need to remember during development. Most of these result from the Dalvik VM. The current Dalvik implementation on Android phones does not support JIT nor is the Garbage Collector any good.
As no JIT is available all code is interpreted on time and not pre-compiled or anything. On a limited device such as a mobile phone this results in slowdowns. Therefore, it is important to pre-load everything you need and cache as much as you can to have a fluent gaming experience during e.g. a level.
Another thing is the current GC in Dalvik: Avoid it ^^’ Sure, you cannot really avoid the GC directly but try to not release too many objects during gameplay (or fire it by yourself) as the GC will slow your phone so down that even the OS will need time to react. This is also something that can be managed with caching and a good manual memory management. Currently, up to Android 1.6 an application may use up to 12MB of memory. With Android 2.0 this has been upped above 20MB, but as a game should support many platform versions (the issue why I am posting this), 12MB will probably be the limit for a while.
3. The Android OpenGL ES implementations
Another thing that bothers the development of OpenGL ES applications on Android is the again heterogeneous availability of specifications. Android itself by SDK supports OpenGL ES 1.0 and 1.1. The official current OpenGL ES version is already at 2.0. While 1.1 is backwards compatible to 1.0, 2.0 has no backwards compatibility. OK, its to note that 2.0 is somehow pretty fresh and you cannot ask for the newest technology in Mobile Phones. But most Android phones at the moment only support 1.0, for example the HTC Magic whereas the Motorola Droid should be able (hardware-based) to support 2.0.
The support/portability problem is one of the issues. But more relevant is the functionality available in 1.0 and 1.1. The iPhone is based on OpenGL ES 1.1 and by that it has a big advantage over most Android phones: Vertex Buffer Objects (VBO)! As posted before my tutorial ports, OpenGL ES does not support primitive rendering (glBegin/glEnd). This is good as it will nevertheless be dropped out of the OpenGL standard. In OpenGL ES you have to use Vertex Arrays and/or Vertex Buffer Objects, which are faster anyway. BUT 1.0 only supports Vertex Arrays and no VBOs. This is one big disadvantage not only in speed but in development. You can argue that it is possible to program an application that supports both with tagging the sections but as it comes to mobile development you always try to comprehend everything as much as possible without acting on too many specifics.
Two other important things when it comes to game development are that 1.0 does not support multi-texturing on its own (there are ways, but those are tricks) and it does not support the automatic mipmap generation. Both are necessities if you want to do such nice things like Ravensword or N.O.V.A.
Another thing are the phone specific OpenGL ES implementations. Not only versions but also manufacturers provide different implementations with their phones. For example the Samsung Galaxy has a known very weak OpenGL implementation. There are already several published articles on how to add the HTC implementation to a rooted Galaxy. And as more and more manufactures will enter the Android market in the coming month this will probably get worse.
So, what can be concluded from this? Actually not much but 1.0 <= 1.1 < 2.0! There are some tricks here and there to deal with some things under 1.0 but overall you just have to accept the fact and optimize around what is missing. Or you limit your development to 1.1 (at least for now). But by that you will loose many phones such as the Magic or G1, which probably are the most widespread Android phones at the moment.
4. General and Specific OpenGL (ES) Paradigms and Tactics
As with every programming language or library there are several Best Practices that should be remembered during development. The same thing applies to OpenGL. There are many posts in the net on how to optimize your OpenGL code and you should definitely use Google to keep you up-to-date. I just want to point out two important things (in my opinion) for mobile development.
The first thing is to reduce your draw calls! This is not limited to mobile devices but OpenGL in general. But because of the limited hardware versus a Desktop system, this is even more important. Each draw call is not necessarily bad but in sum are slow. Now, most people do enormous, cool architectures with self-drawing objects that are instanced over and over again. This is nice from an object-oriented point of view but is bad on a mobile device. If you want to do something good and fast for Android work with overall handlers. This relates to what I said about caching. To have super classes, handlers or factories that collect all changed elements or all objects that need to be drawn and only that Object fires the draw call is the way to go. This may look like a limitation but this is not only good for the speed of your application but also reduces the possibility of asynchronous errors when instances of deep objects are computed while the rest already handles another request.
The second thing correlates with what I said about memory handling and caching: Reduce your texture binding calls! To rebind your textures again and again and switch them back and forth is also bad for the overall performance. I know that it is tempting and Android with its nice resource loader somehow invites you to have hundreds of single texture files and load them again and again. But this will get you into trouble really fast. First of all, reduce the calls by utilizing again a super class, a texture handler with some kind of caching mechanism. Another possibility is to merge several textures into one large texture and offset the texture mapping coordinates accordingly. This is easy to do and just requires a small asset pipeline but the advantage is huge.
Both things suggest some very important points that have to be taken into account in the architecture and early development. Therefore, always tend to fulfil the mentioned points already while you are planing.
5. General Mobile Development Paradigms
As well as for OpenGL there are some rules regarding Mobile Development in general. There are also several posts on the net about this topic but just to sum up what I already coped in the above text: A Mobile Device is no Desktop!
Many people come from the Desktop development and are real geniuses there. They make the best applications, fast, functionality perfect and have wonderful graphical user interfaces. BUT what works on a Desktop does not necessarily work like that on a mobile device. JavaME made it necessary to go back to Java 1.3.1 programming style; To forget about Generics; To forget about Enumerations and just use the “old ways”. Now, with something like the Android SDK, which allows to use nearly the full Java5 specification people just copy their desktop applications into the Android projects and this will make problems. All the things I pointed out above result from that premise as the desktop is the more forgiving (because more powerful) platform.
Things like creating hundreds of instances, using hundreds of different files, not working with in-memory data but reloading everything over and over again are bad… bad… and even worse, really bad! Do not get fooled by all the technical specifications of the mobile devices. You cannot compare the CPU and the RAM with the desktop pendent. I recommend to have a look “back” at the JME development and the experience people made there. Do not copy it one-to-one but use it as a guideline and convert it into a comprehensible Android project. Most problems, most errors, most failures that are posted and reported result from the unused experience made in that mobile development area. Reuse that knowledge, reuse their principles, their ideas and you will avoid many problems. And as there are enough “new” problems do not trip into the old ones.
Please do not get me wrong: My opinion about Android is high, I have one on my own and I love it. Love developing on it, love the SDK updates. The only thing I want to point out is that development on Android phones and Android itself has to start to keep these five things in mind. The next three to six month mark an important state with Android where to go and with at least the noted points you should be good to go.
So, go out there and really work on it to do the best f***in’ 3D Android game of them all (and comment about it here ^^’)!
Two days ago, the USA version of The Chronicles of Spellborn, published by Acclaim went F2P. Today they made this step official. You can go to their website, register a free account and download the about 3GB, install and start playing. I recommend it, as TCOS features a new, active and live fighting system (which I like very much). It also has a very believable world, which does not follow any large license but cooks its own soup. Something I like, as it also encourages you to explore. Now, you can make up your mind yourself as it is free! For those that already played TCOS at the beginning, please note: It has changed nearly completely in my opinion! It is far more user friendly, the interface got better, the guidance, the environment more lively…
It was announced some weeks ago that the European Servers shutdown and The Chronicles of Spellborn will nevertheless continue as a F2P, beginning from next year. This is fantastic, as so many good but not great MMOs (like Tabula Rasa) just get lost in the Windows Trashcan because of shutdowns. The European servers have been shutdown already, but now Acclaim announced that the US Version is F2P from today on but will not feature any updates or patches until the official relaunch. In my opinion it is worth it. And as it is free now it has enough content to keep you playing for a while. And let’s see… maybe you like it!
The Chronicles of Spellborn
The Chronicles of Spellborn was a bold try to do something completely out of line from UO, Everquest or World of Warcraft. The studio from Netherlands licensed the Unreal 2.5 engine and created their own story, their own environment, their own world! Main focus was put on the fighting system, which features a complex looking but very special and good kind of active and live fighting, with skill-based tiers. Moving, jumping, attacking from behind gets more interactive and it encourages to test your skill-tiers, similar to Guild Wars, because of the alignment and limitations in the slots.
Unfortunately TCOS could not fully keep up to the (and my) expectations. It was polished but too little content was available. Some people also argued that the quest descriptions were missing concrete directions. I liked that, as it was no following arrows and points but really reading the quests, the logs, the text. As the quest and discussion system also features some kind of answer selection, sometimes you can change your stand and the mood of NPCs to you. Something I also like.
So, just head over to the official website and download the game. It is worth at least a quick look and maybe the community will bring Spellborn back to live, somehow like Ryzom.
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.