Update: IFrame & Mojo Debugger
There is an update to the IFrame. RAB and KAM (many thanks) have posted there update here. This will make it’s way into the main source update really soon I promise. It’s remiss of me to update this stuff but life has intervened.
As mentioned in the previous post I had a look at the WebOS SDK and was mightily dissapointed that Palm hadn’t bothered to hook the debugger into the Eclipse plugin. Well I though it might be an interesting project to try and write a debugger front-end.
I started off looking at the ports from the emulator and trying to capture the commands that go between the two using WireShark. No luck, not sure why but it seems that it can’t capture stuff between the virtual network link and the host PC. Fair enough. I then looked into their jar files that compose the Palm plugin and realised that I could call their API to do the same thing. So, I recreated their plugin. This wasn’t easy..
Writing an Eclipse plugin is a bit of a dark art. It’s one of those thing that most programmers don’t have to do. So far I have the following working:
- Launching an application.
- Terminating an application.
- Launching the debugger.
- Talking to the debugger to start and stop the application.
- State machine for processing debugger output.
- Capture break condition to extract method, line and column numbers.
- UI reflecting pause status correctly.
- Eclipse shutdown pulling down any application launched from Eclipse plugin.
Talking to the emulator requires the use of methods from the Palm JARs bundled with the SDK. The API lets me open a TTY terminal connection to the emulator. I am querying if there is an existing debug process and if not it will start one up. At that point we can control the debugger and get output back from it.
The response is processed depending on the current ’state’. The state is set by the operations from the user (break, run etc) and a state machine transitions around to capture the output and process it accordingly.
WebOS: No Debugger Under Eclipse
Palm Pre developers can spin this any way they want but it’s currently not possible to set breakpoints using Eclipse, break on a line, inspect the variables or anything else debug-wise from within the IDE. It seems you have to use a command-line debugger.
I know it’s not like it’s _impossible_ to use but are we really expected to enter the full path to a line in the code to set a break point e.g.
var/usr/palm/applications/com.yourdomain.test/app/assistants/stage-assistant.js:5
I’m not sure what to say about this? My expectations were somewhat higher.
WebOS: newsReader SDK Sample
I have been playing around with the Palm Pre WebOS SDK. Compared to my efforts to get J2ME stuff to work (ages ago) I have to commend both Android and now Palm in making these phone SDK’s so easy to get up and running. For both Android and Palm it’s a painless task from download to seeing applications running on the bundled emulator.
Although tempting it’s too early to make a comparison between WebOS and Android as I have yet to embark on writing anything for it.
Anyway, the SDK comes with a number of samples one which is a pretty full featured RSS reader. There is a problem though. The project can be imported into Eclipse (after installing the appropriate plugin) but does not appear as a Mojo project. The reason for this is that the ‘nature’ in the project file is set to what appears to be the old name for the SDK. In order to get this to work properly in Eclipse you will have to edit the project file.
< ?xml version="1.0" encoding="UTF-8"?> <projectdescription> <name>newsReader</name> <comment></comment> <projects> </projects> <buildspec> </buildspec> <natures> <nature>com.palm.pdt.nature</nature> </natures> </projectdescription>
The secret is to change the content of the ‘natures’ value to the one above. Now when you import the project into Eclipse it will appear as a proper Mojo app.
The news reader is a great demo as it has a little bit of everything you will be required to know to put together an app which talks to the internet. Interesting features:
- List which changes the font for unread/read items.
- Rendering RSS html snippets.
- About dialog.
- Preferences dialog.
- Help dialog.
- RSS icon with number of read items.
- AJAX download of RSS feed.
Plus lots of other stuff under the hood which I don’t understand yet.
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….
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.
Android: Getting the cupcake source
I am currently working on a few projects with Android. One of these is an OpenGL game. Looking at the most recent blog post on the Android blog there is mention of a GLSurfaceView class which I was immediately interested in. The problem is it is in the 1.5 Cupcake source branch. How to get the code?
I had previously installed Git but it’s been a while since I used it so I couldn’t remember the commands to pull a branch of the code down. Stumbling around the inter-tubes I came across this page which has a url which pulls the latest head of the current branch. Hmmm I thought, I wonder if it would be possible to modify this to get the ‘cupcake’ branch. Well the answer is yes. You just have to modify the ‘h’ parameter to point to the target head.
So if the head is referenced as h=refs/heads/cupcake then the full url is http://git.source.android.com/?p=platform/frameworks/base.git;a=snapshot;h=refs/heads/cupcake;sf=tgz.
My plan is to pull the GLSurfaceView code out and build it into my app. This a stopgap until the 1.5 SDK is published officially.
Flex: IFrame zoom in/out fix
Ariel Sommeria has made a nice fix for a buggette in the Flex IFrame.
Currently if you zoom in and out of the page the Frame resizes as well. Ariel has made a clever fix which forces the frame back to the size it was when rendered the first time (I hope I have understood this correctly).
There is a sample with source here. Nice to see a demo to show off the addition.
Android: gTraffic UK and BBC Data
I think it might be worth pointing out that the gTraffic Android application does not break the Terms and Conditions applied to the BBC Traffic data. The biggest singular reason for this being that it is free. It will always be free because (unless I strike a deal with the BBC, TrafficLink and the Highways Agency) that is the main condition of use. See for yourselves here. I did see an argument on the comments for the iPhone traffic app which tried to reason that anything using the data was basically an RSS reader but I understand perfectly well that this is not the case. It is the data which comes under the Terms and Conditions and no amount of pre-processing it changes that.