像素困境：选择正确的图形 API答案

【问题标题】：Pixel dilemma: Choosing the right graphics API像素困境：选择正确的图形 API
【发布时间】：2011-04-12 18:33:40
【问题描述】：

我想制作一个带有可破坏地形的横向卷轴游戏。我的方法是将地形作为 BMP 并访问每个像素。

但是，我在为我的游戏选择正确的图形 API 时遇到了问题。

我已经考虑了几个选项：

我开始使用 SDL 编写游戏，我将地形作为表面，每帧都将其放到屏幕上。不幸的是，它非常慢，当更多的地形可见时它变得更慢。在屏幕上只绘制一个位图时，我有 30 FPS。

我看到了一款与我想要制作的游戏相似的游戏。它使用 GDI 并且可以逐个像素地操作。速度似乎还可以。但既然 SDL 在 Windows 上使用 GDI 作为后端，为什么我不能只使用 SDL？

速度非常好，虽然我遇到了技术问题 - 当纹理加载到 OpenGL 时，我无法再对其进行操作，这打破了我的整个计划

如前所述：我需要访问所绘制图像的每个像素，并且绘制本身应该足够快，以便平滑渲染 1280 * 500 像素的地形。

【问题讨论】：

我对 OpenGL 不是很有经验，但是使用 DirectX 3D 你可以锁定一个表面来编辑它，我希望在 OpenGL 中有一个等价物。
我对所有 API 了解得不够多，无法直接回答。请注意，如果您的位图比屏幕宽得多（正如我从您的描述中得到的印象），那么简单地将可见部分传送到屏幕涉及以非缓存友好的方式跳过内存。考虑将位图分成与屏幕一样宽的面板。然后，刷新将涉及（通常）两个相邻面板的 blitting。两倍的操作，但更好的局部性。
使用 SDL 时，您使用的是硬件表面吗？直接在硬件表面访问像素很慢，如果您需要大量像素操作，最好使用软件表面。

【解决方案1】：

我推荐 OpenGL，因为您可以将工作卸载到 GPU。但是，您所描述的内容听起来像是您想在客户端 (CPU) 上进行大量操作，因此您可能仍然会遇到 CPU 和 GPU 之间所有吞吐量的瓶颈。

使用 OpenGL 完成所需任务的最佳方式可能是使用 PBO（像素缓冲区对象）。 AFAIK 这是从客户端 (CPU) 访问/修改服务器端 (GPU) 上像素数据的最有效方式。

【讨论】：

【解决方案2】：

2014年，试试SDL2——据说是硬件加速的。

但是，我无法告诉您有关正确像素策略的任何信息。似乎recommended way 是在每一帧上将你的记忆surface 上传到视频texture。

【讨论】：