170 likes | 287 Vues
Learn how AndroidGame extends Activity class, implements Game interface, and utilizes FastRenderView, Graphics, Audio, Input, FileIO for effective game development. This guide covers handling input, garbage collection, pools, and essential components like KeyboardHandler, AndroidFileIO, AndroidAudio, and more. Embrace the power of this framework for seamless game development.
E N D
Android Game Framework CGDD4203
The Overview • AndroidGame • Extends Activity class • Implements Game (abstract) interface • AndroidGame consists of • FastRenderView, Graphics • Audio, Input, FileIO • Screen
OnPause and OnResume 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
setScreen – Getting Things Going Stop previously active screen Commence new active screen (with time/update delta of 0)
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
The Thread’s Work Tell current screen toupdate/present itself Draw the frame bufferfullscreen (scaled)
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)
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
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)
Pool Fixed Size (! GC) No allocation(! GC) Pool<KeyEvent> keyEventPool (capacity = 100 in this case) List<KeyEvent> keyEventsBuffer 1. Key is pressed 2. Key info copied (obj moved from pool into buffer) List<KeyEvent> keyEvents 3.This (#1 & #2)continues… No allocation(! GC) 4. Periodically (don’t wait too long) we call getKeyEvents 5. KeyEvent objects are “freed” back into the pool & moved into keyEvents
Other Odds and Ends • AndroidFileIO • Audio • AndroidAudio • AndroidSound • AndroidMusic • Other Input • AccelerometerInput • AccelerometerHandler • CompassHandler All of this is ‘cake’ (no lie!) if you’ve followedeverything else.