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):
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.