1. Android Game Framework CGDD4203

2. The Overview AndroidGame – Extends Activity class – Implements Game (abstract) interface AndroidGame consists of – FastRenderView, Graphics – Audio, Input, FileIO – Screen

3. OnCreate

4. Linking Input Handling

5. getStartScreen

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

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

8. RENDERING

9. AndroidFastRenderView Threaded (implements Runnable) Maintains – Reference to AndroidGame – Bitmap framebuffer (to draw) – SurfaceHolder (to lock/unlock canvas) Responsible for calling update/present on game’s current screen

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

11. INPUT HANDLING

12. AndroidInput Provides ability to handle various inputs – Accelerometer – Keyboard – Touch Clean interface to low-level ‘guts’ – Also allows for multiple APIs and compatibility – SDK < 5 (SingleTouchHanlder) – SDK >= 5 (MultiTouchHandler)

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

14. KeyboardHandler Allocate pool (smart list) of KeyEvent 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)

15. Pool Pool keyEventPool (capacity = 100 in this case) Pool keyEventPool (capacity = 100 in this case) List keyEventsBuffer List keyEvents Fixed Size (! GC) No allocation (! GC) 1. Key is pressed2. Key info copied (obj moved from pool into buffer) 3.This (#1 & #2) continues… 4. Periodically (don’t wait too long) we call getKeyEvents 5. KeyEvent objects are “freed” back into the pool & moved into keyEvents

16. Other Odds and Ends AndroidFileIO Audio – AndroidAudio – AndroidSound – AndroidMusic Other Input – AccelerometerInput – AccelerometerHandler – CompassHandler All of this is ‘cake’ (no lie!) if you’ve followed everything else.

17. The Overall Picture