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?

score 10 · Accepted Answer · answered Dec 15 '11 at 17:56

10

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

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.
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.

answered Dec 15 '11 at 17:56

Steve Blackwell

5,904
32
49

Great answer Steve, thank you! I think even that I dont like to mess up the design, I will follow the #1. My game is active, but there is no heavy calculation on it, like physics or a lot of collision checking. Just to have sure about my thoughts, my approach of threading in the question would be correct if i choose it (logic thread writing in a synchronized map and render thread reading it)? – Gustavo Maciel Dec 15 '11 at 18:37
Oh, one more thing. people said me to limit my logic updates to 30fps, this is the case to rendering too? Should i limit the entire function to wait 33ms for every update, or just update the logic if has been passed 33ms since last update? – Gustavo Maciel Dec 15 '11 at 18:42
I don't think you have to limit it, but maybe don't expect better than that on some phones. This is because the framerate of some of the first HDPI phones (I think around the time of the Droid 1) were fill limited, which means that they could not draw a screen full of pixels more than about 30 times per second. Maybe the GPU can crank out frames faster than that, but the CPU can't move them to the screen fast enough. This is not the case on newer phones I think. – Steve Blackwell Dec 15 '11 at 18:54
Don't pass 33ms to logic code. You can lock yourself to 30fps if you need more time to work on logic, but that's probably not an issue yet. – Steve Blackwell Dec 15 '11 at 18:59
Ah, so thanks for your answers! Just to mention, I have a Droid 1, and it will be my testing hardware (: – Gustavo Maciel Dec 15 '11 at 19:04

score 6 · Answer 2 · answered Dec 15 '11 at 16:00

6

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)

answered Dec 15 '11 at 16:00

brigadir

6,874
6
46
81

hmm, as your last topic sugests, the onDrawFrame from OpenGLrenderer is called on another thread? or just the gl.GLxxx() that are sent as requests to other thread that is pertinent to GL? – Gustavo Maciel Dec 15 '11 at 16:05
@Gtoknu When you get the call `onDrawFrame()`, you're on another thread. See here: http://developer.android.com/reference/android/opengl/GLSurfaceView.Renderer.html – Steve Blackwell Dec 15 '11 at 16:24
@SteveBlackwell Oh, thanks, i haven't realized that. But how could brigadir answer be true if i cannot call onDrawFrame() as it is automatically called by another thread? those are confusing. – Gustavo Maciel Dec 15 '11 at 16:36
@Gtoknu You're right. I'm not quite sure how brigadir's answer could work. You can't call a `renderAll()` because `onDrawFrame()` is called for you. I can't see a way around that unless you start using `Canvas` and `SurfaceView`. See my answer. – Steve Blackwell Dec 15 '11 at 18:00
Excuse me for confusion in code piece. The idea is to process update always before rendering. If we update our scene in separate thread, sometimes update can be called twice in a row - and we don't see result of first call because render was not called. Steve Blackwell has answered this in case #1. – brigadir Dec 16 '11 at 08:44

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

2 Answers2

Linked