I ported Auriga3D (A Q3 class engine) to Android in just over 2 days for my presentation at CodeCon a week ago or so. I’ve ported Typhon to Android (http://typhon.egrsoftware.com) and 98% of the code for Auriga3D cross compiles with the desktop version. Typhon now supports JOGL, LWJGL, and Android OpenGL ES adn Auriga3D runs with all of those bindings with the majority of code shared between the binding and desktop vs Android. You’ll love this… It only takes 13 class files specific to Android to have things up and running…
Regarding Auriga3D on Android, how I handle curved surfaces is the largest performance handicap as there is no LOD and the bezier patches are large (fine for desktop / not Android). FPS is 8-45 FPS for the untuned port of the Q3 renderer to Android. Culling out curved surfaces gives roughly 15-45 FPS.
Here is a “sketchy” video I made right after getting things to work.
I’m starting an Android technology blog for the company I’m working with currently. I’ve proposed to base my contributions the blog (or my corner of it) on Android / OpenGL ES and porting a significant game (thinking Java port of Quake 1) to Android and doing detailed tutorials on how the 3D engine is constructed. So far I got a little push back on this, but if this is something you guys would like to see let me know. Everyone I’ve talked to has been positive on this, but I’ve just received a little push back so far…
But the performance seems REALLY unreliable in that video. It goes from “pretty good” to “ack, slideshow” pretty fast. Is that just texture limits + cpu worok on curves, or is there something else more sinister going on here like the phone not being able to handle more than 40 triangles on screen?
It’s the curved surfaces. If I turn them off I get 15-45 FPS on Q1DM1 for Q3. Of note is that this is the essentially the desktop path using vertex arrays (minus display lists for render / state change calls) and the engine is floating point oriented, so not fixed point which is supposedly better due to no FPU with the G1. Right now there is a ton of vertex data for the curved surfaces and it takes a long time on loading the level (can minimize this) and can kills frame rate while rendering. No LOD, no potential reduction of vertex data for Android (prob not as easy due to gaps in surfaces). The BSP system does a great job for culling reducing/drawing. And yes there are also the possibility of VBO, but I’ve not had the chance to enable/test this with the G1. I’m loading the same commercial Q1DM1 level file as the desktop, so the texture sizes can be reduced. Fill rate is a concern for sure. Getting up close to a wall and shooting with all the particle (billboard) effects can slow things down (but that happened on desktops too 6-7 years ago). Also I hacked together real quick the TGA loader and need a better fix. I was using DevIL for the desktop and Android only supports so many image formats.
The first level shown in the video is huge and 1 FPS. I took the video before I enabled the option to cull curved surfaces or any other potential performance enhancements; could be fill rate limited cause the textures are large and a lot is shown.
Overall I’m surprised that it works as well as it does essentially being a less efficient version of the desktop path which uses display lists. VBO should improve things and a lot of the above too.
There are only 4 class files specific to Auriga3D that need particular Java binding calls changed for speed (Level, CurvedSurface, MeshSurface, FlatSurface).
Of note I’m using OSGi for Typhon and Auriga3D to be able to interchange run time components. It’s quite possible to release a game that works on the desktop and Android with any of the major bindings (JOGL, LWJGL, Android OpenGL ES) from a large shared base of code rather than porting an entire engine over to a particular binding. This was a major design goal from the start of Typhon/Auriga3D 5 years ago (back then it was more an academic exercise to be able to use LWJGL or JOGL render paths). It paid off big for porting to Android. The port took just over 2 days, but really I was refactoring some parts of Auriga3D out to generic bundles/components that can be used in other 3D engines/games. The core OpenGL changes took 6 hours and a little testing and everything just worked.
Thanks… I’ll have to make another video when I can find a camera that can focus. There are minimal differences between the API for JOGL and Android OpenGL ES (of course some methods are not present for the GL ES binding). For the most part the method/API signatures are the same. I’ll post the Android blog when it goes live. I’m shooting for having it up for Google I/O… I’m still trying to convince the folks I’m working with to let me port and release open source a reasonable 3D engine to dissect. If this is of interest definitely let me know or PM me as I’ll try and forward on support for this idea. Everyone I talked to seems to agree with me that doing this would be the best way to keep the blog interesting and result in a playable open source 3D engine in the Android market for those to learn from.
Grr… I’m kicking myself for not submitting at least a BOF on this for J1 as it’s some cool new stuff. If anyone needs crash space I live 3 blocks from Moscone Center in SF.
Very nice work you done there. If we see cool things like this, I sure will get a android once it comes to NZ.
Do you think you able to make the maps at playable fps?
[quote]yes I would like to see you port quake1 on android.
[/quote]
Google already ported it. You can see videos on this on youtube. Though seems they didn’t release it.
I think it is quite possible to make maps at playable FPS especially if complex curved surfaces are minimized. Also if the maps has more enclosed spaces FPS will be very playable. It’s also possible to improve curved surface rendering with Android to minimize current limitations.
Regarding a Quake 1 port. I did just get approval from the the company (Tactel US) I’m working with to move forward with the Android / OpenGL ES tutorial web site. The Q1 port is more educational oriented and stage 1 will cover the level renderer and will be completed before the site goes live. At the least what I want to provide is a solid level renderer using up to date OpenGL techniques, so that if anything the rest of the game can be completed by other interested parties. Ideally though I’ll add some sort of networking / game play support as further tutorials progress, but that remains to be seen on the up take of the site.
I believe Qualcomm did the first Q1 demo before the G1 was released, but without source code or more information it was unclear if it was an actual Java source port. There is currently a “Quake preview” in the market by the same fellow that did one of the Doom ports, but the implementation while seemingly accurate is software rendered with no source release.
The goal of my effort is to educate and inform on Android / OpenGL ES and Q1 provides a nice benchmark to do so that is interesting for developers getting into OpenGL ES and Android. I’ll also be porting and offering various NeHe lessons that get folks started with OpenGL ES and any other background info that is useful. I’d like to see quality 3D games and other applications for Android!
This is just what I’m after! I’ve been looking at moving my Android game from 2d into 3d, and have just started the NeHe tutorials. However, if there were Android OpenGL ES tutorials, this would be much better! I look forward to any update on this.
EDIT: Forgot to mention, there currently some Android OpenGL ES tutorials which are ok, but they could be a lot better: http://code.google.com/p/android-gl/
