This topic is pretty interesting. I also am off the school of "one
thread is enough". I have to admit that I don't fully understand the
benefits of a seperate logic thread. Am I right in thinking that the
only reason to have a seperate logic thread is being able to use the
cpu while it blocks on the GPU on a call to say eglswapbuffers? And
isn't that increased CPU usage downplayed by the needed lock for
synchronization? Did anyone do some benchmarking in that regard? I'd
really be interested in whether it's worth it (not all that complex if
you go the route of robert)
On 9 Apr., 20:01, shaun <shashepp...@gmail.com> wrote:
> I wonder how much true parallelism is happening when the game logic
> runs on a separate thread than the rendering (in addition to the
> Activity thread for a total of 3). I do not claim to be an expert in
> this arena, but what follows is what I think about the subject of
> threads in Android games.
>
> Since we are dealing with a single CPU device, there is only a
> possibility to gain speed when the game logic thread and the GPU are
> processing simultaneously. It could be easy to have the rendering
> thread spend a lot of time on the CPU instead of the GPU if there are
> many calls to GL being made. And in order to get the most bang for
> the true parallelism buck, you would need to make sure the rendering
> pipeline has as few calls to GL as possible (preferably 1 for
> glDrawArrays and 1 bind texture atlas for an entire scene and then 1
> to swap the buffers, of course there are a few others surrounding
> that, but hopefully you see my point). The basic point is, the more
> calls to GL, the more time CPU cycles are taken up in the rendering
> thread and since there is one CPU, the game logic thread is not
> simultaneously running.
>
> My overall take for most 2D games on Android is that you are better
> off with a single thread for both game logic and rendering UNLESS you
> have optimized your OpenGL rendering pipeline down to have a bare
> bones minimum of GL calls in a sort of "render the entire scene at
> once from vertexes and 1 texture". With 3D games, the rendering
> pipeline seems more conducive to the "render all at once"
> implementation.
>
> I tried going down the path of 3 total threads and found not nearly
> enough performance benefit for the threading overhead (programming and
> context switching). In my case, I would have had to re-write quite a
> bit of my rendering pipeline to minimize the GL calls made to render
> each frame, so I opted with 2 total threads - Activity and All Else
> (game logic and rendering).
>
> On Apr 9, 12:03 pm, Robert Green <rbgrn....@gmail.com> 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 <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.
