多线程 Android 游戏上的图像不稳定
我决定将我的基于 sprites 的 2d 游戏转换为 Android 版，以使用 opengl-es 来帮助解决一些与渲染相关的帧速率问题。目前的设置如下：
渲染将放在自己的线程中，渲染模式设置为连续。游戏逻辑更新发生在单独的线程中。两个线程都与同步的drawlock类交互，这确保它们永远不会同时接触游戏信息。
因此基本上，渲染线程在绘制之前等待任何当前更新完成，更新线程在开始更新之前等待当前渲染结束。一切看起来都很棒，除了我在屏幕上移动时在图片中注意到的一些不稳定性。
我相信这可能是由于每次渲染之间发生的更新数量缺乏一致性，平均发生的更新数量是两倍，因为截至目前更新中还没有发生太多事情。但这缺乏一致性，因此有时 1 个通过，有时 2 个、3 个等，因此所绘制的项目位置的增量也不一致，从而造成不稳定。
有人知道我该如何纠正这个问题吗？更新线程被调节为每秒 60 次并带有睡眠...也许渲染下需要发生类似的事情？我现在还不确定。
I decided to convert my spritesbased 2d game for android to use opengl-es to help with some render-related framerate issues. Currently the setup is as follows:
Rendering tkaes place in its own thread, with rendermode set to continuous. Game logic updating takes place in a seperate threaad. Both threads interact with a synchronized drawlock class which ensures that they are never touching the game information simultaneously.
So basically, the render thread waits for any current update to finish before drawing and the update thread waits for the current render to end before starting an update. Everything looks great except or some choppiness I've noticed in the picture when moving around the screen.
I believe this is likely due to a lack of consistency in the number of updates that happen in between each render, on average twice as many updates happen because as of right now not a whole lot is happening in the update. But this lacks consistency so sometimes 1 gets through, sometimes 2, 3 etc so the delta in positions of items being drawn is also not consistent thus creating the choppiness.
Anyone have an idea how I might rectify this? The update thread is regulated to 60 times per second with sleeps...maybe something similar needs to happen under render? I'm just not sure at this point.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据您的游戏数据量，您可以尝试复制它。当游戏引擎更新一个副本时，渲染引擎正在处理另一个副本。更新完成后，渲染引擎切换到读取更新的副本，而游戏引擎则等待更新传输到较旧的副本（引擎将在下一个周期更新旧副本）。这是一种双缓冲方法，但应用于游戏数据而不是显示缓冲区。
Depending on how voluminous your game data is, you might try replicating it. While the game engine is updating one copy, the rendering engine is working off the other. When an update is finished, the rendering engine switches to reading the updated copy while the game engine waits until the updates are transferred to the older copy (which the engine will then update on the next cycle). It's kind of a double-buffering approach, but applied to the game data instead of to the display buffer.