Scaling and Displacement

Scaling and displacement are tricky areas. The old browser-based Java engine could use absolute values for background and sprite size. Everything was based on a 640 x 480 playfield starting at position 0,0, with appropriately sized sprites, and sprite / zone positions locked to the 640 x 480 setup.

With the multi-platform Android version, any given game background size need not be based on 640 x 480, but may take any rectangular size. In addition, the eventual playfields can be many sizes and usually will not not start at position 0, 0. Sprites will be scaled and their position on the screen scaled appropriately. Touch positions will be similarly displaced.


All collisions, zone effects, sprite movements and other screen events will be computed in the program on a game model which is at the basic background dimensions.

So, for drawing and detection of user touch, all positions, including background, sprite positions, dirty rectangle positions and touch positions, we have to make a transformation.

Rule 1. All images are pre-transformed to the correct scale. (This to save processing time during animation)

Rule 2. All position calculations are initially made on the base dimensions of the background playfield and proportionate sprite positions, and are only resized and displaced at draw time.

Rule 3  All touch co-ordinates are similarly transformed to base positions (by rescaling in reverse and subtracting the displacement) before being applied to the base model.

For example, the background. In any given scene, the background image does not vary. It is efficient to scale the image at the outset of the scene. Once scaled, and its displacement from position 0,0 determined, it can be drawn, in whole or in part, without having to scale the bitmap every time.

Similarly, sprite images will be resized, but all dimensions and positions will be reported to the base game model on the (in this case) 640x480 basis.

The actual placement and size of the sprite will be deternined in the draw stage.

There is a slight complication. Sprites can be scaled, flipped and mirrored , and this is done prior to the general scaling transformation.

It's not really so complex. Is it?

A Little More Progress

I can't see very much more that needs to be saved - the current scene is the major factor.

Just mopping up some of the display manager functions, and checking out thread behaviour for the timer.

More Struggle

Google is keen to get to know me and help out. Perhaps they could improve their user interface on this Xoom.

Anyway, I've made a little progress with the game but I don't want to go too far without testing my changes on the emulator which I can't do right now.

re. Bundle management

For simplicity, it's best if the game restore string for orientation is the same structure as the optional game save file that's stored locally.

Therefore, I am not going to make use of the Key:value pair structure in the Bundle except to label the whole save string.

In addition, since the game may be updated/altered, the save string must always be forwards/backwards compatible.

Must watch out for possible duplicate keywords e.g. spritename/scenename both called "pause"; imagenames will often be the same as sprite/scene names. Partially identical names in the savestring could also be problem, as we search it for spritenames among other things. Perhaps all keywords in the string should be uppercase and preceded by a type letter. e.g. S for sprite, R for scene(room), G for general state markers.

re. Scene alteration

Mostly, changed or additional zones with new destinations. Occasionally, delete zone. Sometimes, different image(s) or music.

So, for any alteration - like an open door with a new exit, we just have a key in the save string that causes us, on restore, to call a method in JadeData which makes the alteration.

Unecessary Struggle

I found that all the menu items on this blog had been rendered into Greek, and simultaneously my bluetooth keyboard malfunctioned, so wasted some time, but the good news is that I made useful inroads into Save and Restore both for users and for Androidy purposes.