I suggest you take a look at the open source Android game Replica Island. Chris Pruett (a Google employee and Android advocate) programmed it and I understand he uses a Thread for rendering, a Thread for game logic and a Thread for the Activity (life cycle, input etc...). He has a synchronization mechanism executed each frame to sync up the renderer and game logic Threads.
Find it at http://code.google.com/p/replicaisland/ On Apr 9, 10:22 am, Eddie Ringle <[email protected]> wrote: > Another thought occurred to me. I'm more comfortable with the old- > fashioned game loop, and I noticed I can turn off auto-rendering. I'll > see if this works out instead. > > On Apr 9, 8:55 am, Eddie Ringle <[email protected]> wrote: > > > > > I'm a bit confused. What exactly is Game.sInstance? And can you > > explain what the update() and render() methods do? (Well, I know what > > they _do_, but I do not know how they are doing it (pseudocode would > > work here).) > > My gameplay is probably going to be a bit bigger than what you have, > > so I don't think I'll be able to keep it inside the renderer class. > > > On Apr 9, 4:27 am, Clankrieger <[email protected]> wrote: > > > > Hi, > > > > I had a lot of difficulties getting the threading and app lifecycle > > > issues done, too. For my part, this was much more confusing than > > > getting the actual game done. ;) > > > > The good thing is: you do not have to do too much for the render- and > > > logic-thread separation because most of the rendering time is getting > > > spent "outside" of your renderer's onDraw method. This is how I got > > > this done: The "Game" itself is owned by the glSurfaceView renderer > > > instance. the when the game starts (at onResume), I start an > > > updatethread that is very simple an does something like > > > > while(bKeeprunning) { > > > synchronized(Game.sInstance) { > > > Game.sInstance.update(); > > > } > > > Thread.sleep(50); > > > > } > > > > I have to add that my game logic is doing only this: logic. The world > > > gets simulated. This is done less than 10 times per second - this is > > > why I can have it sleep for 50 ms. sleeping is important here to give > > > the render thread time to do this (I don't remember the full method > > > signature, but I think you know what I mean): > > > > onDrawGlFrame() { > > > synchronized(Game.sInstance) { > > > Game.sInstance.render(); > > > } > > > Thread.sleep(5); > > > > } > > > > I defined the updatethread as class inside of the Renderer because it > > > is so small. This gave me a huge performance boost. Handling the app > > > lifecycle is less easy (at least for me). > > > > On Apr 9, 3:09 am, Eddie Ringle <[email protected]> wrote: > > > > > Surprisingly, I don't seem to have issues with the OpenGL side of > > > > things (which is very unusual), but my problems stem from getting a > > > > clear idea for app architecture and a few other problems. > > > > Right now, most tutorials on the net just describe the render portion. > > > > I know that when I create a GLSurfaceView and hook a Renderer into it, > > > > it uses it's own thread for rendering. > > > > > I want to do logic operations and other gameplay stuff (like moving > > > > characters and whatnot) in it's own thread as well. Can anyone explain > > > > a good approach to this? I'm guessing the two threads will have to be > > > > synchronized (do logic, render, repeat), and limited based on time so > > > > that it performs smoothly across different devices.- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
