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.
