I am play-testing version 1.3.0 just now. This has fast OpenGL renderer which should sort of a lot of the lag for the busier levels of the game.
The fast renderering of multiple lines and colours is handled using line and color arrays. The code for this has been put into the BulletML demo. If you are interested drawing lots of lines fast or OpenGL in general on Android then I would recommend you download the code and have a look at it. The demo features a switchable mechanism for flipping between OpenGL and Canvas.
I really wrestled with implementing the GL layer but I have definitely learnt a great deal and gained some confidence in my abilities to go on to put something together myself.
Hi to everyone surfing in on their Android phones.
The good news is I have finally released Noiz2 to the Android Market.
Porting this application to Android has been a lot of work so I hope people like it. There is a complete explanation of the game here.
Leave me some feedback. Please be specific about ‘improvements’ to the graphics because I am not sure what that means. It’s a vector styled game!
- Original game mode.
- Trackball support with configurable velocity.
- More optimisations of the graphics. I went in and removed my experimental OpenGL layer. I also re-factored the design to stop passing around the Canvas object. Not sure now what more I can do other than find out why the hell the OpenGL drawing is slower than the graphics Canvas.
Some items on the TODO list:
- High score table
- Accelerometer support.
- OpenGL renderer.
Following on from my porting of Kenta Chos BulletML demo I decided to port Noiz2 to Android.
I’m not going to go into a great deal of detail as to what was required to get this to work on Android. In short, I had to rewrite the entire BulletML parser which was quite a bit of work. This was because the code used a pull parser which wasn’t available for Android. I converted it to use XmlPullParser. Then I had to seperate the update code from the draw code, implement a screen canvas drawing layer and pull the whole lot into use the Android class “CanvasSurfaceView”.
It just so happens that all the graft I put in with my previous Android applications _combined_ with the stuff I had picked up when trying to write my own shoot-em-up came together so that I thought what-the-hell and launched into trying to port it to the Android phone. So what do you think..
This was a great learning experience as my own game is far from finished and I had not at that point come against the pitfalls of trying to write something which uses the touch-screen to control the game.
It’s not quite ready for publishing yet but I did have to go back to the developers forum to check on why the touch screen slows down the rendering of the game.
If I have got this correctly: there are two threads to the game application. The UI thread (which handles the touch screen) and the game itself. Any game on Android is split into two theads of execution – the the update of the screen elements and the update of the UI. Using the touch screen to update the position of the ship slowed the game to a crawl. What to do?
The solution as stated here is to put a “Thread.wait” into the touch handler.
The reason this works is that the Thread scheduler divides time between the competing threads. If you touch the screen then the UI automatically gets a large chunk of that time. This slows down the game drawing thead. The solution is to sleep for a short amount of time to free up the game thread to draw the screen elements.
Well it seems to work up to a point. The later levels with lots of screen elements still go at a crawl but I see this is still the case on the rRootage port to the iPhone (which I now see has been published).
Here is a picture which does not do justice to my own shoot-em-up.
This is written using the OpenGL surface. All the screen elements are animated so the ships engines are working away and the missiles are spinning and changing colour as they move up the screen.
I have tried to write something which is an elegant as I can. No ugly shortcuts. The reasoning behind this is that I can optimise it later but for now the code should adopt nice Java6 structures and any design patterns that seem applicable. I keep getting sidelined into other stuff but as of now here’s the plan:
- Create an OpenGL rendering layer for the BulletML demo (I have started to write one as part of the Noiz2 application – see above – but it doesn’t handle textures yet).
- Pull in the BulletML code so far (from either program. whichever is faster) and let that define the enemies.
- Define the enemy waves and maybe build in a genetic algorithm which makes it different every time.
So that’s the plan. I rarely abandon ideas so I suspect I will see this through. Should be interesting to see what I come up with. I have some nice ideas which I think will mark my shooter out from the pack so lets see….
The source code for this is now available here.
In the process of putting together a shoot-em-up style game for the Android phone I remembered coming across BulletML from Kenta Cho. I am familiar with Kenta from rRootage which was/is the coolest shooter for the jail-broken iPhone. Somehow it has never appeared on the app store which is pretty bizarre. Anyway I knew that Kenta had defined a mark-up language for defining all the crazy bullet patterns from his games. I had a look at the Java Applet here. It was written in java how hard could it be?
In the end it wasn’t too bad but I still haven’t a clue about Kentas code which is as opaque as it gets.
I can visualise how I will marry this to my game although I will have to write an OpenGL rendering layer.
- Main list
- Typical bullet sweep
- Another sweep
Demo source code here. I haven’t decided whether to put it up on the market yet in the demos section.
I have rewritten graphics layer and implemented an OpenGL renderer for drawing the lines. Anyone interested in line graphics on Android might be interested in this. The line width feature under OpenGL does not work on the phone. It appears the width is fixed on the actual hardware to 1px.
I got the profiler working. It looks like the application was linking to the opengl class in the SDK on the phone. Well, that’s what it looked like because when I changes the package name for the opengl stuff I ‘lifted’ from the v1.5 source it started working. Go figure.
The subversion source is kindof broken in the sense that I havce come across a bug in the int buffer. To make it work on the emulator comment out the lines marked ‘workaround’. More on this in later posts.