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. -- 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 To unsubscribe, reply using "remove me" as the subject.
