I understand that this is pseudo-code, so it probably does not reflect your actual implementation, but I have two comments on this code:
* Depending on how the scheduler works, the GameLogicThread or the Renderer thread may receive the lock two or more times in succession. * The renderer and the game logic thread never execute in parallel, so any time spent blocking in either thread is not used by the other. If for instance the renderer thread would receive a list of things to render from the game logic thread once each frame (and the game logic thread takes care not to modify this data during its loop) this would be achieved. Best regards, Viktor Linder On 9 Apr, 18:03, Robert Green <[email protected]> wrote: > It's pretty easy to do this: > > I use a World to write to and read from for the two "sides." Makes > networking nice too. My World has a simple lock. Only one thing can > write to it or read from it at a time. > > in GameLogicThread: > > run() { > while (!done) { > // wait for renderer > world.getLock(); // blocks > update() > world.releaseLock(); > } > > } > > in Renderer: > > onDrawFrame() { > world.getLock(); // blocks > draw() > world.releaseLock(); > > } > > On Apr 9, 3: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.
