将带有OpenGL的Android快速游戏的游戏逻辑与渲染分开的最佳方法? [英] Best way to separate game logic from rendering for a fast-paced game for Android with OpenGL?

问题描述

我研究和制作小游戏已有一段时间了，最​​近我决定尝试开发适用于Android的游戏.

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.

对我来说，从本机C ++代码跳转到Android Java并不难，但是让我头疼的是如何考虑将逻辑与渲染保持分开.

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:

最好不要为此创建另一个线程， Android肯定不会有任何处理上的问题.

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

含义是这样的:

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

但是我不确定这是否是最好的方法.因为我不认为我喜欢将逻辑放入GLRenderer::onDrawFrame方法中的样子.据我所知，这种方法仅用于绘制，如果在其中放置逻辑，可能会减慢帧的速度.更不用说它伤害了我所理解的POO的概念.

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:

主要活动:

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:

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

最后是OpenGLRenderer:

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?

只要我研究过，大多数线程游戏的示例都使用画布或Surfaceview，因为我使用的是OpenGLES，所以这些都不适合我的情况.

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.

这是我的问题:

哪种是分隔我的最佳方法 使用OpenGLES时从渲染的游戏逻辑?线程我的 应用?将逻辑放在单独的方法中，然后从中进行调用 抽奖方法?

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?

推荐答案

因此，我认为您可以通过两种方式进入此处.

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

1. 从onDrawFrame()执行所有更新::这与使用GLUT相似，Android会尽可能频繁地调用此函数. (使用setRenderMode(RENDERMODE_WHEN_DIRTY)将其关闭.)此函数在其自己的线程(而不是UI线程)上调用，这意味着您在此处调用逻辑更新.您最初的问题是，这似乎有些混乱，我同意，但这仅是因为该函数名为onDrawFrame().如果将其称为onUpdateScene()，则更新逻辑将非常适合此模型.但这不是世界上最糟糕的事情，它是通过这种方式设计的，人们已经做到了.

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.

赋予逻辑自己的线程:这更加复杂，因为您现在要处理三个线程:用于输入的UI线程，用于绘制内容的渲染线程onDrawFrame()和用于连续处理输入和渲染数据的逻辑线程.如果您需要一个非常准确的事件模型(即使帧速率下降)，也可以使用此模型(例如，精确的碰撞响应).从概念上讲，这可能更清洁一些，但实际上却不干净.

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.

我会推荐#1.您真的不需要#2.如果您愿意的话，您可以稍后再添加它，但是大多数人只是使用第一个选项，因为硬件足够快，因此您不必围绕它进行设计.

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.

这篇关于将带有OpenGL的Android快速游戏的游戏逻辑与渲染分开的最佳方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！