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 <tob...@googlemail.com> 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 <ed...@eringle.net> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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.
