Best way to separate game logic from rendering for a fast-paced game for Android with OpenGL?

Question

I've been studying and making little games for a while, and I have decided lately that I would try to develop games for Android.

For me, jumping from native C++ code to Android Java wasn't that hard, but it gives me headaches to think about how could I maintain the logic separate from the rendering.

I've been reading around here and on other sites that:

It is better to not create another thread for it, just because Android will for sure have no problems for processing.

Meaning the code would be something like this:

public void onDrawFrame(GL10 gl) {
    doLogicCalculations();
    clearScreen();
    drawSprites();
}

But I'm not sure if that would be the best approach. Since I don't think I like how it will look like if I put my logic inside the GLRenderer::onDrawFrame method. As far as I know, this method is meant to just draw, and I may slow down the frames if I put logic there. Not to mention that it hurts the concepts of POO in my understanding.

I think that using threads might be the way, this is how I was planning:

Main Activity:

public void onCreate(Bundle savedInstanceState) {
    //set fullscreen, etc

    GLSurfaceView view = new GLSurfaceView(this);
    //Configure view

    GameManager game = new GameManager();
    game.start(context, view);

    setContentView(view);
}

GameManager:

OpenGLRenderer renderer;
Boolean running;
public void start(Context context, GLSurfaceView view) {
    this.renderer = new OpenGLRenderer(context);
    view.setRenderer(this.renderer);

    //create Texturelib, create sound system...

    running = true;
    //create a thread to run GameManager::update()
}

public void update(){
    while(running){
        //update game logic here
        //put, edit and remove sprites from renderer list
        //set running to false to quit game
    }
}

and finally, OpenGLRenderer:

ListOrMap toDraw;
public void onDrawFrame(GL10 gl) {
    for(sprite i : toDraw)
    {
        i.draw();
    }
}

This is a rough idea, not fully complete. This pattern would keep it all separated and would look a little better, but is it the best for performance?

As long as I researched, most examples of threaded games use canvas or surfaceview, those won't fit my case, because I'm using OpenGLES.

So here are my questions:

Which is the best way to separate my game logic from the rendering when using OpenGLES? Threading my application? Put the logic in a separate method and just call it from the draw method?

Answer 1

So I think there are two ways you can go here.

1. Do all updates from onDrawFrame(): This is similar to using GLUT, and Android will call this function as often as possible. (Turn that off with setRenderMode(RENDERMODE_WHEN_DIRTY).) This function gets called on it own thread (not the UI thread) and it means you call your logic update here. Your initial issue was that this seems a little messy, and I agree, but only because the function is named onDrawFrame(). If it was called onUpdateScene(), then updating the logic would fit this model well. But it's not the worse thing in the world, it was designed this way, and people do it.

2. Give logic its own thread: This is more complicated since now you're dealing with three threads: the UI thread for input, the render thread onDrawFrame() for drawing stuff, and the logic thread for continuously working with both input and rendering data. Use this if you need to have a really accurate model of what's happening even if your framerate is dropping (for example, precise collision response). This may be conceptually a little cleaner, but not practically cleaner.

I would recommend #1. You really don't need #2. If you do, you can add it later I guess, but most people are just using the first option because the hardware is fast enough so you don't have to design around it.

Answer 2

Keep your design as simple as possible :) The standard (and maybe the best) approach is following:

public void update(){
    while(running){
        updateAll();
        renderAll();
    }
}

I would pay attention on some moments:

• you need to call sequently update and render methods, avoid calling update twice a time
• if you prefer multithreading (I don't), design your methods so update writes data and render reads only
• keep in mind that OpenGL has it's own "thread", so when you call GL function it only sends some command to OpenGL (except glFlush() - it completes all commands)