A Few More Topics

Coding:

• Background transitions: It should be easy to slide one background over another, one doDraw() at a time.
• Sprite scale, flip and mirror: Must do some experiments with this, but it looks as if a single bitmapFactory call with a suitable matrix could do the whole modification on a Sprite  image.
• onPause and onResume: A save string could be attached to the Bundle, just to restore the current state. The deliberate saves (by User) would use the same save string format, but stored in a local file.

Game:

• Lighting the Rocket: A candle in a cave.

More Design

Showing the limp mode version to a friend yesterday alerted me to the fact that I ought to centralise the image in the view. No problem. Just a displacement in the x or y axis of the destination.

There will also be a need for cutting off a portion of any sprite that strays across the background boundary.

Both of these can be handled in the doDraw portion of the code.


--------------------------

Some scenes will be labelled "no popscene", eg Inventory, save, limbo.

---------------------------

Design suggestion: So that we don't need to use text to label the various saves, icons of jade Chinese horoscope characters  (eg dragon, tiger, ox, monkey) will be used.

Quick Design Points

Decision 1:

Sprite images will be collected full size. On scale change in the sprite, they will be re-scaled in the sprite's image list.

Decision 2:

View scaling will be done at doDraw time. After all, it's only one rescale per sprite.

Some Decisons

Wrestling with the Rect (x1, y1, x2, y2) versus Rectangle (x1, y1, width, height), I eventually decided there'd be less code wasted by going over to the Rect as standard, particularly appropriate for Zones, and making the position (x1, y1) and size (width, height) of the Sprite as Points.

Another decision is that Sprite position will be the position of the Sprite centre.

When to scale the Sprite image(s) for screen size? This should be done at scene change, not "just in time".

There is also a scale factor for Sprites which is independent of screen size, and can happen during a scene. This should be done "just in time".

The new Pause facility will act like an Inventory scene, with all the features previously supplied by Javascript buttons - music, save/restore, Inventory.

Optimism

Really making progress with Jade now. After a successful limp mode with background and moving partially transparent sprite, which readjusted and restarted on orientation, I was confident enough to bring in a lot of the Bridge code. A few matters giving me grief right now:

• The difference between Android Java's Rect class and the Java Rectangle class;
• The fact that the cursor is going to have to be a sprite;
• How to implement flip and mirror- will Android Java accept a back-to-front or upside-down Rect as a parameter in canvas.drawBitmap? To be tested.

Breakthrough

After remaining baffled for a while that I couldn't get my Android Jade app to display anything, I discovered:

• by a roundabout route, without ever finding out what had been wrong, how to display and change a background of a different size to the original image;
• how to move a sprite over it (with transparency);
• how to detect touches and flings on the touch screen;
• how to detect and compensate for changes in orientation;
• how to superimpose a diagnostic display.

I now, therefore, have a framework on which to build the various functions from Bridge. The apk (application package) even works on the Xoom.

Still Struggling

I am now seriously planning Jade, as the Android version of Bridge will be called, and here are a few of the considerations I've been working with.

Contrary to my previous assumption, I think quite a lot of Bridge code will transfer across to Jade.

It appears that most graphics Android apps consist of a kind of basic Activity, and a separate Class, a subclass of View, for the work and the display. I'm currently wondering whether I should do the same, and include all the Sprite / Scene / Data Management etc. classes within the View subclass. I'm revising scoping rules etc.

I was originally planning to put the initialise data in an xml file, but I now feel that my BridgeData class is actually more efficient, involving less iteration and parsing at startup and restart.

I found the Vector class very handy in Bridge, but I guess it's time to use these smart list classes.

I shall retain the off-screen buffer model from Bridge, do all the original artwork at full size, do vector movement etc. off-screen, then blit it into the View canvas when it's done. So at each screen size and each orientation, I'll calculate suitable View dimensions. Then I'll leave it to Java to scale the OSB to the actual screen. This is instead of doing the screen construction inside a Thread.

As for the GUI, there will be a "Jade" button (actually a Sprite) on every screen. Touching it will pause the game and allow the user to make various choices (it will actually be a virtual scene, like Inventory and Limbo). Choices include music, save, restore.

There will be differences in the cursor and carrying GUI, due to touch rather than mouse screens.

I think I can retain the cookie format of save data.