Android Game Framework CGDD 4203 The Overview Android

  • Slides: 17
Download presentation
Android Game Framework CGDD 4203

Android Game Framework CGDD 4203

The Overview • Android. Game – Extends Activity class – Implements Game (abstract) interface

The Overview • Android. Game – Extends Activity class – Implements Game (abstract) interface • Android. Game consists of – Fast. Render. View, Graphics – Audio, Input, File. IO – Screen

On. Create

On. Create

Linking Input Handling

Linking Input Handling

get. Start. Screen

get. Start. Screen

On. Pause and On. Resume OK to dim/turn-off screen Stop the render thread Active/current

On. Pause and On. Resume OK to dim/turn-off screen Stop the render thread Active/current screen should stop Don’t dim/turn-off screen hereafter Active/current screen should commence Begin the render thread

set. Screen – Getting Things Going Stop previously active screen Commence new active screen

set. Screen – Getting Things Going Stop previously active screen Commence new active screen (with time/update delta of 0)

RENDERING

RENDERING

Android. Fast. Render. View • Threaded (implements Runnable) • Maintains – Reference to Android.

Android. Fast. Render. View • Threaded (implements Runnable) • Maintains – Reference to Android. Game – Bitmap framebuffer (to draw) – Surface. Holder (to lock/unlock canvas) • Responsible for calling update/present on game’s current screen

The Thread’s Work Tell current screen to update/present itself Draw the frame buffer fullscreen

The Thread’s Work Tell current screen to update/present itself Draw the frame buffer fullscreen (scaled)

INPUT HANDLING

INPUT HANDLING

Android. Input • Provides ability to handle various inputs – Accelerometer – Keyboard –

Android. Input • Provides ability to handle various inputs – Accelerometer – Keyboard – Touch • Clean interface to low-level ‘guts’ – Also allows for multiple APIs and compatibility – SDK < 5 (Single. Touch. Hanlder) – SDK >= 5 (Multi. Touch. Handler)

Garbage Collection and Pools • In real-time systems, auto-memory handling (GC) can kill performance

Garbage Collection and Pools • In real-time systems, auto-memory handling (GC) can kill performance gcviz (on Net. Flix data) http: //techblog. netflix. com/2013/05/garbage-collection-visualization. html • Memory pools can avoid this problem – Allocate at the beginning and “self-manage” thereafter

Keyboard. Handler • Allocate pool (smart list) of Key. Event • Maintain input buffer

Keyboard. Handler • Allocate pool (smart list) of Key. Event • Maintain input buffer • Maintain events collection • Poll buffer periodically • Move from buffer to events collection • Shuffle memory from events collection to pool as needed • Don’t neglect to handle events or events collection will fill up (i. e. , pool will empty)

Fixed Size (! GC) Pool<Key. Event> key. Event. Pool (capacity = 100 in this

Fixed Size (! GC) Pool<Key. Event> key. Event. Pool (capacity = 100 in this case) 1. Key is pressed No allocation (! GC) List<Key. Event> key. Events. Buffer 2. Key info copied (obj moved from pool into buffer) List<Key. Event> key. Events No allocation (! GC) 3. This (#1 & #2) continues… 4. Periodically (don’t wait too long) we call get. Key. Events 5. Key. Event objects are “freed” back into the pool & moved into key. Events

Other Odds and Ends • Android. File. IO • Audio – Android. Sound –

Other Odds and Ends • Android. File. IO • Audio – Android. Sound – Android. Music • Other Input – Accelerometer. Handler – Compass. Handler All of this is ‘cake’ (no lie!) if you’ve followed everything else.

The Overall Picture

The Overall Picture