Z 缓冲区的高效实现
我目前正在使用 Z-Buffer 算法实现我自己的渲染器。完成必要的计算后（阅读：我的 Z 缓冲区填充了正确的值），我使用 SDL 为必要的像素着色。我为此使用了 HWSurface。
我的问题是，如何尽快渲染它？我的意思是绘图本身，我可以对我的结构、算法进行优化，我稍后会这样做，但我想确保绘图本身尽可能快。
因为我有自己的 ZBuffer 实现（稍后还会有其他算法），所以我无法使用 OpenGL，那么有其他选择吗？
现在我只是检查 z 缓冲区中的所有点，然后逐一绘制所有必须绘制的像素（因为它是 z 缓冲区，所以我必须这样做，对吧？），然后我调用绘制像素方法。关于SDL，我在遍历z缓冲区之前锁定我的表面，绘制所有像素并随后解锁它，据我所知，这不能更快。
有什么建议吗？
I am currently implementing my own renderer using the Z-Buffer algorithm. Once I have done the necessary calculations (read: My Z-Buffer is filled with the correct values) I use SDL to colour in the necessary pixels. I'm using an HWSurface for this.
My question is, how can I render this as fast as possible? With this I mean the drawing itself, I can do optimisations in my structure, my algorithm, I will do that later on, but I want to be sure that the drawing itself is as fast as possible.
Because I have my own implementation of a ZBuffer (and there will be other algorithms later on) I can not use OpenGL, so are there any alternatives?
Now I'm just going over all my points in the z-buffer and I draw all the pixels that have to be drawn, one by one (and because it's z-buffering I have to do this, right?) and I call a DrawPixel method. Concerning SDL I lock my surface before going over the z-buffer, draw all the pixels and unlock it afterwards, this can't go faster as far as I know.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
软件实现速度极其缓慢，也就是说，WARP 在 i7 六核处理器上渲染《孤岛危机》时的 FPS 仅为 8800GT 的十分之一。您不会在软件实现的 Z 缓冲区中找到任何有竞争力的性能。
Z 缓冲区并不是一种特别复杂的算法，您不太可能找到比另一种更高效的实现。 Z 缓冲不是您在光栅化期间执行的操作，而是您在像素渲染期间执行的操作。如果新像素的深度比当前写入的值更远，则不要进一步渲染该像素，例如，不要计算它的颜色等。您不会绘制 z 缓冲区或类似的东西。它不像一种可以为算法选择最有效的排序的排序 - 它更像是矩阵乘法，它们几乎都是相同的。
Software implementations are incredibly slow- that is, WARP renders Crysis on an i7 hexacore at a tenth the FPS that an 8800GT does. You won't find any competitive performance in a software-implemented Z-buffer.
A Z-buffer is not a particularly complex algorithm and it's pretty unlikely that you'll find one implementation that's more efficient than another. Z-buffering isn't something you do during rasterization- it's something that you do during pixel rendering. If the depth of the new pixel is further away than the currently written value, don't render the pixel any further, e.g., don't compute it's colour etc. You don't draw the z-buffer or anything like that. It's not like a sort where you might pick the most efficient sort for your algorithm- it's more like a matrix multiplication, they're pretty much all the same.