Android: Simple Weather UI
Another update to the UI for new version of Simple Weather a very early Android application I wrote back in 2008.
I went though all the layouts and changed the LinearLayout references to RelativeLayout instead.
I think I will move the date up the top. It looks kind of strange where it is.
Android: Simple Weather UI
This is a work in progress.
I have been trying to learn how to write slicker interfaces for Android as the stock styling is fairly boring.
Note the rounded edges to the list activity and the colours nicked from the iPhone weather app.
Android : Europa Game Library
Europa is a Android 2d game library which I have been working on for the past 5 months on and off.
It is heavily influenced by the design principles of Cocos2d a 2d game engine which exists in Python form and as an influential iPhone framework.
This was created originally out of some frustration with the existing engines that were available. They all seem to focus heavily on providing classes which abstract the graphics layers of the Android platform. What I really wanted was a proper framework which I could use to organise the game elements. This desire had come about from my previous attempt to write a simple shoot-em-up style game. I got so far with the sprites but got bogged down in how to ‘manage’ the scene elements. When I examined cocos2d I was struck how similar the idea of ‘actions’ was to my original design where I was associating command objects with what I now know as elements from the scene graph.
In cocos2d there are actions which run in sequence on each tick of the game loop and are attached to ‘nodes’ where a node is merely an abstraction and can be sub-classed to implement scenes, layers and sprites. The actions form the basis of all animation and what’s more is they can be composed together to form chains of operations e.g. move from a to b and rotate by an amount. Europa basically follows the same design with a Director, scenes, layers, nodes and an action pipeline which operates in the node elements.
So far I have implemented
- Texture cache which can load images from file or resource. It can also load simple sprite sheets.
- Animated sprites.
- Base Node class which is very much simpler that the cocos2d version where the base class is loaded with masses of cruft.
- Scenes.
- Layers.
- Actions for base animation, movement and scene transition.
- Control actions for sequence and parallel compositing of operations.
- Bitmap fonts build from the Android system fonts along with a font cache.
- Publish/subscribe sources for I/O events.
- Simple event pipeline to broadcast to subscribed handlers in nodes. This is not in the original cocos2d design.
- Ability to switch between Canvas and OpenGL.
- Touch areas which respond by broadcast events to subscribers.
- Touch labels.
- Simple buttons.
The framework has been designed with good practise in mind so there are lots of design patterns plus most importantly this has been written with Android in mind right from the start. When I say ‘android in mind’ I mean that there is nowhere where it creates objects with the game loop unless it is deliberate. This was a major design goal from the start.
I have also tried to keep the class hierarchy as flat as I can so it’s exceptionally lean and mean in terms of how it hangs together.
I am quite close to a version of the framework I am happy with and plan to publish it as a work in progress when I get a bit more into the shoot-em-up demo that I am using to iron out the parts needed.
Update #1
I am no where near releasing this in reality. I rewrote all the graphics subsystem to use matrices for the transformation between the coordinate systems which was a massive mind bender as that stuff is all new to me. Now am at a stalemate. The library is supposed to support Canvas and OpenGL but I have reached the point where I have to decide whether to ditch the Canvas support but I can’t let it go. The problem is that Canvas does not support lots of features like offloading the images onto the graphics memory and also the sprite drawing is so slow when there are lots of images. The caching of images is not efficient. Analysis paralysis has set in big stylee. I know I should just ditch the Canvas support but cannot bring myself to design it out. I’ll come back to it when I’m ready.
Update #2
I have scrapped this version and am now using LibGDX instead coupled with some of the same concepts.
Android: Noiz2 Source Code Available
The code for the vector shoot-em-up for Android is now available here.
This is a bit of an esoteric game to say the least but it is good fun once you get into it. I always thought that this was going to be a bit hit on the market but it kind of fizzled away without ever really taking off. I am somewhat confused as to why this happened since it was really the only decent shoot-em-up when it was first put on the market. Maybe just a bit too old-skool for the cool kids these days.
My hope is that maybe someone will attempt to pull the BulletML component out and make it into something that can actually be useful. The current implementation is baked into the game engine which makes it difficult to see where the joins are.
There are other possible improvements
- Better background graphics for the title screen.
- Better help.
- Different shapes for the enemies rather than the uniform cubes.
We’ll see how it goes.
Status: Android, WebOS, Bada
Current
I am so busy just now that I have not had a chance to get back into any current projects. I should hopefully have some more time soon and when I do I will be getting back into all the existing stuff with a vengeance.
Android
I am due to receive a phone from Google due to my existing applications maintaining a good star rating over 5000 downloads. I know there are issues with newer phones so this should sort that out. I got in early enough to get some headway on the Market but I wouldn’t have got very far if the apps were rubbish so it’s heartening to get some recognition. I can’t wait to see what Android 2.1 looks like. My intention is to release an update to my traffic application. What form this will take I am not sure yet. I suspect the next one will be like gTraffic but will use the HA RSS feed provided from the cloud for speed. I have a cloud based feed ready to go but nothing to talk to it.
Palm WebOS Eclipse Plugin
The WebOS debugger is a strange one. I spent ages trying to get the Chrome DevTool to talk to the emulator but with no luck. I have been watching other attempts to get a debugger integrated and there has been no progress so I see I am not alone (you know who you are). The existing code is not ready for release. I think this will be a bit like the SPARQL browser where I plug away and then just bring it out and no-one will know that they needed it until it appears. I have no opinion on Ares other than it is an amazing web application. Do we still need an Eclipse based solution? I no longer care. It will be finished when it’s finished which might be never. It has been incredibly satisfying to get this half-working but also incredibly annoying that I can’t get to some sort of milestone.
Bada Epic Fail
Bada oh Bada where shall I start? I signed up for the SDK only to find out that I needed a registered business account to receive the SDK. Let’s just think about this for a minute shall we. Take a minute and mull these points over:
- A new OS platform which must compete with both the iPhone and Android.
- Require a strong developer community to get the platform going.
There is a clear whiff of old-school control-freakery in the air around this platform which I think is a big big mistake for Samsung. I looked at the demo for this OS on Engadget and it looks great (it should do after nicking all the best bits of their competitors UI elements). Where is the access for developers like me or others who want to bring their own applications to the phone OS but don’t want to go through their boss? It’s the lure of the gold-rush which kick-started the Apple app store and (even more) the Android market. Samsung are late to the party and they are only talking to the hip kids.
Android: gTraffic UK Update
Well, it’s been a while since I worked on my UK Traffic application. With the release of the Android 1.6 SDK I thought it was time I made some updates. There are a couple of cosmetic changes most significantly I have ‘thickened’ the timebar marker. Also I applied a filter to the timebar colour to give a blur effect. Nice.
You can see this in the above screen-shot. The previous one didn’t stand out enough for my liking.
There are also a few changes under the hood. In particular the map API is slightly different so I had to refactor the code a little to bring it into line.
I’ve decided to go back to the traffic NY application as well and see if I can do something with it. There are still 200 active installs which is interesting. I occasionally boot the app up on my developer phone and the last time I looked all the NYSDOT data was out of date so I think I am going to have to look into what on earth is going on with their RSS feed. I did mail them before and got a reply when I was moaning about there roadworks feed so we’ll see.
Other news is that I emailed Palm developers about my development of the debugger plugin but so far I have had no reply. I was asking about using the Palm SDK jar files. Well it’s been a week and I thought I would at least have got a response (saying no way) but nothing. Oh well.
Development of this plug-in is (so far) for my own amusement. I was thinking that it might me something I could sell but I don’t think I will beat the Palm developers to it.
It looks to me that output of the debugger is in gdb format. This would make sense as the platform is Linux based. To this end I got thinking about Antlr and parsing the output. Searching for this stuff is hard! Not many references but I suspect I will have to write some Antlr grammar to extract the file references and methods from the debugger output.
Android: Noiz2 1.3.0
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.
Android: Noiz2 – 1.2.4
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!
Implemented
- 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.
Android: Noiz2
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….
Update:
The source code for this is now available here.
Android: BulletML
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.
Update #1
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.
Update #2
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.