• entries
    316
  • comments
    485
  • views
    321615

Z-Buffer Installed...

Sign in to follow this  
Jason Z

115 views

Z-Buffer
I added the z-buffer 'processor' to the flexline over the last few days. It was actually pretty easy to implement, since it just reads in a fragment, makes the depth comparison, and either passes on the fragment (and update the z-buffer) or else simply discards the fragment by not passing it on to its output buffer.

In some respects, it is nice to be free of the constraints of the hardware rendering systems. For example, I implemented a floating point z-buffer (just because I could [grin]) which couldn't be done in hardware unless you have a brand new $400 video card. Of course, there is that small performance penalty that has to be paid for using software instead of hardware...

Anyways, I also added a back face culling processor to the pipeline as well. The next component will be a triangle clipper for triangles that intersect the viewing frustum. Once this is completed, the traditional pipeline will be complete (more or less - I could add alpha blending, but I have read/write access to the framebuffer in the pixel shader, so it isn't really necesary). Then it will be on to the bigger and better specialty processors.

More on that to come. In the meantime, here is a screenshot from the z-buffer doing its thing:

Sign in to follow this  


2 Comments


Recommended Comments

Quote:
small performance penalty


Try enormous. Software rasterizes are more for cool factor now, and they are awesome, but you aren't going to run a 'modern' game on one.

Also, that zig-zag pattern in your texture mapping is probably caused by sub-pixel inaccuracy. You should google up it.

Share this comment


Link to comment
Hello Deyja, thanks for posting. I know that the software rendering system is not going to be as fast as a hardware renderer - and I don't intend to use it to run games. It was more of a learning experience than anything else.

Also, the zig-zag pattern in the texture is due to a couple of factors:

1. The input texture is 32x32, so there is more than one pixel displaying each texel.
2. I have not implemented mip-mapping, so there is no LOD taken into account.
3. The texture coordinate pattern on that triangle is rotated 45 degrees from the other triangle - it was done as a test of this exact effect.

Even so, with a bilinear sample I think the image still looks alright for now. I will likely add some form of mip-mapping in the near future, and I'll post the results as they are ready!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now