Jason’s babblings.

Today’s goal was to put some research into drawing graphics onto the screen. Basically, with the Android, there are three general methods to put stuff on the screen.

First, and simplest, is with the predefined Android view classes. This method allows us to put icons on the screen, and give the icons simple animations. This is good if we want to add some graphic flare to an otherwise boring app, but doesn’t allow much interaction.

In the second method, we override the onDraw() routine to fine-tune where things are placed on the screen, and call invalidate() method when we want to refresh the screen. This is good because you can tell the screen to refresh when WE want it to (like when you press a key to move a character) – it doesn’t take up much processing power, and we’re able to have more interaction with where things are on the screen. The downfall is the simple animations that are accessible in the predefined static screens aren’t available here. Since we’re updating the screen ourselves, we’ll need to control which image in a frame animation or which frame of a “tween” animation – translate, scale, pivot, etc – is shown. It’s a bit more work, but the trade off in interactivity is worth it.

The third method of screen drawing is the most processor intensive. It involves spawning a new processor thread that will handle screen drawing, while the original thread handles input and game logic. The “graphics thread” draws to a separate canvas based on data fed from the “logic thread” then it displays that canvas immediately when the drawing is finished, then starts drawing the next frame on a new canvas. This method produces a screen that is constantly being updated, so we can have very smooth animations for more graphically intensive games. The downfall with this is it is constantly drawing to the screen, so it’s more processor intensive and drains the battery faster. Also the same animation gotcha applies from above.

I played with all three of these before deciding that the second one would be best for my game.

Current demo: Using the third method above (though I ultimately decided to use the second after the demo was created), I defined my onDraw() routine to draw the image of a guy, we’ll call him Red, on a white screen at a specific location. The direction pad updated the location, which would be reflected when the screen redrew itself.

So basically a guy moves around a screen.