Efficient implementation of a Z-Buffer
I am currently implementing my own renderer usi开发者_JAVA百科ng 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?
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.
精彩评论