Useful Stage Reached

I've now done all the Menu items as follows:
Quit : finishes the game
Music On/Off : tweaks the music flag, though no music is currently implemented
Inventory: enters the Inventory scene (which cannot be saved)
User Save/Restore : uses 4 possible local files to save/restore any position
 also:
Android Save/Restore :  to deal with situations where Android OS does something outside the game's control - e.g. Change orientation; Pull a different Activity into foreground; Destroy game for lack of resources.
In this case,  the game saves its current position with the Android's own memory of the game, and restores it when the game is restarted.

All tested on both the PC-based emulator and on a Xoom device.

Save and Restore

I think I've done all the necessary stuff for life-cycle save and restore. Tests so far are encouraging, but there are a number of life-cycle incidents I'm not able readily to reproduce on the emulator. It'll take a test on real hardware to make me comfortable.

Next task is doing the user save / restore options. Then I'll implement the QUIT function.

The GUI

Now implemented the skeleton of the "Settings" menu. The Pause/Restart works, as do the Inventory entry/exit and Music on/off.

Still to do in Settings - Save, Restore.

Scale, Flip and Mirror on Sprites

Wow! That was easy.

The following snatch of code takes image im and transforms it to scaledbitmap.
 scale (x and y values) are based on 100 as full size.
flip x and y values are either 1 or -1.
 1,1 means as original bitmap
-1, 1 means mirrored in the y axis
1, -1 means flipped on the x-axis
-1, -1 means mirrored on both axes - i.e. inverted
 
// scale image before return
Matrix matrix = new Matrix();
// scale and flip
matrix.postScale((float)flip.x*scale.x/100, (float)flip.y*scale.y/100);
// create a new bitmap from the original using the matrix to transform the result
Bitmap scaledbitmap = Bitmap.createBitmap(im , 0, 0,
           im.getWidth(), im.getHeight(), matrix, true);
return scaledbitmap;  

The GUI

Having further considered the matter of the GUI, I've decided to base it all on sprites, rather than a special screen. It is probably neater, and certainly more efficient. So another carefully designed backdrop hits the wastebin.



So, what's still to do?

• Scale, flip and mirror on sprites;
• Cursor;
• More detailed touch control;
• Pick-up and drop;
• The save / restore for Android OS operations. The game has to be revivable if it is re-oriented, de-focussed etc. by the user.  It's an Android preoccupation;
• Similarly, and, I hope, using the same compression technology, the user save / restore;
• Music,which I hope to implement by using the built-in MP3 player;
• The Jade game itself, for which I have a lot of scenery and virtually no plot;
• The various delivery activities to get it to Beta Test and Android Market.

In short, still a lot to do, but the worst is over, I think. Actually getting a limp-mode game on screen has been an achievement. This time, as opposed to the original applet-based software, I've compartmentalised the code so that it will be easy to expand the game, or even base another game on the same engine.

Progress to Date

Well, where am I?

•  Scaling for whatever size of playfield is available works perfectly.
• After pestering with invalidateRect() for weeks to deal with the "dirty" rectangles on the screen, and finding it doesn't work the way I expected, I now just repaint the whole playfield (the image part of the View) every tick. In tests, both on emulator and Xoom, it's fast enough, even with a couple of active sprites. My ticks are approximately 18/second;
• I can detect a touch in various aspects;
• I can click a sprite and change screen, I've dealt with the problem of re-entrant popscreens;
• I'm wrestling with the GUI concept. Basically, there's an icon on every screen, which, if clicked, takes you to an options screen where you can choose to select the inventory screen, quit, save, restore or switch the music on and off (the music is not yet incorporated);
• I can display moving sprites (the gulls in the illustration below) with multiple (24, in this case) images.