Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Adventures in software rasterizing

Sign in to follow this  


Well, I've been working mainly on the software rasterizer that I'll need for this project, and that's going well so far. It's the first time I've ever done one, and was going in with about zero experience in that area. However, it's going very well right now. jpetrie has been a marvelous help, as he has basically taught me how software rasterizing works, methods of doing it, some optimizations, and so on. I've also been able to apply a surprising amount of hardware 3D experience to this as well, as I'm using things like index buffers along with the vertex buffer. Sadly, I don't know how fast it's running right now because of the way I'm viewing the image (which is to render it, then create a D3D surface with that data, and then save that data to a file using D3DX functions) and I think fairly soon I'll implement a timer or something so that I can measure its speed.

Right now I've got it so that it'll render the depth of arbitrary triangles (i.e. VBs with associated IBs) to the image. It uses the halfspace method of rasterizing, which jpetrie convinced me to use, becuase you can do things like skip entire blocks of an image. For awhile I felt that the scan line method would be better, since you don't have to do any checking: using a simple formula you can say exactly where a triangle will start and end on a scan line. However, I required some more convincing, some of which occured on jpetrie's end, and some on mine. Jpetrie's biggest reason was that things like depth/texcoord derivatives don't have to be calculated as often for a block method. With a scanline renderer, the derivatives have to be recalced on each line, and quite often inside that line, while a halfspace method would let you calculate derivatives less often, on 8x8 sized blocks. The reasons on my end were two-fold. First, with a block method, I could take advantage of early z-cull, similar to what most hardware does nowadays, by storing the greatest depth per 32^2/16^2/8^2 block and culling 1024/256/64 occluded pixels at a time. Secondly, and this is something I realized after finalizing the halfspace vs. scanline decision, I could achieve greater memory coherency with a halfspace system. Instead of storing the array in a scanline fashion (i.e. an array of length 480, each element being an array of length 640) I believe it may be better to store it in a block fashion (i.e. for 640x480, have an array of length 300, each element being an array of length 1024, which internally is treated as a 32x32 block). If I'm working in an 8x8 tile, I'll quite often be going to new scanlines, forcing a lot of data movement to go up and down levels often, possibly causing a significant amount of memory thrashing. Instead, a 32x32 block is moved up in one shot, which can then be used for up to 16 8x8 tiles.

So, my todo list right now is as follows (not necessarily in the order described):
  • Perblock iteration (I've already got the block storage set up, but I still iterate through pixel by pixel)
  • Depth checking and early z-cull
  • Edge caching system (inspired by Quake's softrast, which I glanced over awhile ago. I still have yet to decide how this will be stored though. For those who don't know what I'm referring to, basically it's so that calculations between verts are calculated once)
  • Timer so that I can figure out how fast/slow my softrast is.
  • Perspective correct texture coordinates and texcoord derivatives (which will lead into texture page identification)

    Oh, and my next entry I think I might do a little rant on procedural textures, and why texture virtualization could benefit enormously from them.
  • Sign in to follow this  


    Recommended Comments

    There are no comments to display.

    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
    • Advertisement

    Important Information

    By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

    Sign me up!