android - 在android上将openGL渲染与c++游戏循环同步

Question

我正在使用 android NDK 和 openGL ES 2.0 构建一个类似游戏的应用程序

到目前为止，我理解了顶点和着色器以及程序的概念。

主游戏循环将是单线程中的一个循环，如下所示

第一步，读取所有用户输入

第 2 步。根据输入更新游戏对象(如果需要)

步骤 3. 对所有对象进行绘制调用

第四步调用glSwapBuffers

然后循环回到步骤1

但我在同步和线程方面遇到了各种困惑，所以我将所有问题列在一起。

1.由于开放式 GL 绘制调用是异步的，因此绘制调用和 glSwapBuffers 可能会在 gpu 实际渲染来自上一次循环迭代的调用的单个帧之前被调用多次。这会有问题吗？缓冲区溢出或撕裂？

2.假设 VSYNC 已启用，那么第 1 点是否仍然会导致问题？

3.由于所有调用都是异步的，我该如何衡量渲染每一帧所花费的时间？ glSwapBuffers 会立即返回，所以我怎么知道框架何时真正完成？

4.加载纹理会占用 ram 中的空间是在加载纹理标准方式之前检查可用内存还是我应该继续加载纹理直到达到 OUT_OF_MEMORY_ERROR？

5.如果我切换到多线程方法，只以每秒固定 60 次的速度调用 glswapbuffers，而不考虑正在处理输入和发出绘制调用的线程，那么应该发生什么？

另外，我如何控制游戏循环中的 fps？我知道确切的 fps 取决于很多因素，但您如何接近它

Answer 1

1. SwapBuffers() 不会乱序执行。在框架的所有绘制命令之后发出它就可以了。驱动程序会处理它，你不需要同步任何东西。您只能通过使用多个线程或多个上下文来解决这个问题，但即使那样也需要付出很多努力。

2. 1没有问题，这里VSYNC不直接改变什么。

3. 调用可能是异步的，但驱动程序不会将无限量的工作排队。如果您尝试提前发出太多调用，迟早会阻塞。当 vsync 打开时，典型的行为是驱动程序最多排队几帧(或仅一帧，具体取决于驱动程序设置)，SwapBuffers() 将阻塞 当达到该限制时。因此，在前几帧之后，您获得的计时统计数据是准确的。请注意，这仍然比完全刷新队列要好得多，因为驱动程序会在第一次挂起的缓冲区交换完成后立即解除阻塞。

4. 这是一个全新的话题，可能属于另一个问题。但是:您不太可能获得任何当前桌面 GL 实现来生成 GL_OUT_OF_MEMORY。驱动程序将自动在 VRAM 和系统 RAM 之间分页纹理(和其他对象)(操作系统甚至可能将其分页到磁盘)。 GL 也不提供查询可用内存的方法。

5. 在那种情况下，您将需要手动同步。这种方法没有丝毫意义，似乎试图解决一个不存在的问题。如果你想让你的游戏使用多线程，仍然把所有的 gl 渲染(和 swapbuffers)放到同一个线程中。您可以使用不同的线程进行输入处理、声音、物理、场景更新、一般游戏逻辑等等。但是您应该只对 GL 使用单线程/单上下文方法。这样，当 SwapBuffers() 阻塞您的渲染线程时，它也不会伤害您，因为您的游戏逻辑和输入处理仍在完成，并且渲染线程将只渲染具有最新可用帧的新帧以显示器需要的频率(启用 vsync)或 CPU 和 GPU 可以工作的速度(如果禁用 vsync)的频率传输数据。