I am trying to create a 3D game using openGL ES, but I'm not sure how to extract the game functionality from the rendering thread.

I've watched the video http://code.google.com/events/io/2009/sessions/WritingRealTimeGamesAndroid.html and around the 20th minute [14th slide] he talks about having three threads: a general UI thread, a game thread, and a rendering thread. I'm just not sure how to do this because he doesn't give sample code. He is also talking about a 2D game.

I tried to do the same so I have the following structure

GameActivity (My UI thread) , contains the following:
-GameView (My version of a GLSurfaceView) : contains a reference to the game thread so that it can call the draw function of all the objects in the game.
-GameThread (Contains all the game objects and functions)
--initiate function
--run function: the run function loops through all the objects and updates their state

Code: Select all

  while(cont){
   TimeHelper.setTime();
   if(TimeHelper.getElapsed() < 100){
      try{sleep(100);}
      catch(InterruptedException ex){}
   }

   cont = obj.move();
   for(Iterator i = objList.iterator(); i.hasNext();){
      GameObject m = i.next();
      cont = cont || m.move();
   }         
}

The issue: is this runs so fast that the renderer never kicks in to display the animation.
In the 2D examples including Lunar Lander there is some sort of SurfaceHolder. When I look at the example though they seem to extract a canvas, and that's why I don't think it's relevant to 3D.

Do I have to lay out my game differently? Any suggestions, thoughts, directly related articles would be appreciated. Thanks

Actually, Chris Pruett did put all the code up online. Its here http://code.google.com/p/replicaisland/.

The way he does it, is that theres the main game loop, which is obviously just a thread. The main game thread queues draw requests to a queue. BTW, a draw request in this context is "draw this texture at this position on the screen".

Once the main loop is done one iteration, it swaps the queue its been drawing to with the queue that the rendering thread has been reading from. If the rendering threads queue is empty, it just doesn't draw anything (and the screen remains whatever it was last)

At the start of the game loop, it calls a synchronized method on the rendering thread, to ensure that nothing else is queued up until the rendering thread has finished drawing its queue.

This is a very simplified version of what his code does. You should check start with GLSurfaceView and RenderSystem to get an idea of how he does it.

That seems to make a little sense. Thanks for the link! I'll have to take a look at it.