Not sure I agree with that. You are correct in saying that you can get away with no subdivision when the camera direction is normal to the surface. But in a FPS, it seems to me like viewing things edge-on is the rule, not the exception. If I am sitting in the center of a cubic room and looking directly at one of the faces, sure there's one face that requires no subdivision, but there's four faces that do. As soon as you look at some arbitrary angle, you need subdivision on all the faces again. Even in a doom or wolfenstein restricted world you still only have one affine direction, the other direction needs perspective correction. (So instead of approximating perspective correction by drawing little equilateral triangles, you can get exact perspective correction by drawing long strips of pixels).

There was one other thing that I wanted to try but never got around to. In a game like doom, the walls have constant z along the vertical axis and the floors have constant z along the horizontal axis, so affine rasterization can be done along those axes. But even on an arbitrarily oriented 3D surface, you can always find lines of pixels which share the same z-depth from the camera. The catch is that these lines can be arbitrarily oriented on the screen (they don't line up with a horz or vert scanline anymore). There was a trick called free-direction texture mapping which combined bresenhams line algorithm and this constant-z property to write arbitrary lines of pixels in a fast affine inner-loop. I've never implemented it, it sounds pretty tough.

But I think you could use a similar idea with the flash beginBitmapDraw routine. You only need to subdivide triangles deeply along the gradient of z (the direction orthogonal to the line of constant-z). Along the other direction, I think your triangles could have extremely long edges before you started noticing perspective error. Ultimately you could fill the screen with fewer long&skinny triangles instead of lots of equilaterial triangles (which is what this demo does).

I wanted to implement this for comparison but never got around to it. It wouldn't be a huge number of changes from the pvquake demo, but my gut feelings make me not want to do it, for two reasons. The first is that I have no idea how to integrate directional lighting into that approach. I think you could cajole the flash renderer into doing gouraud (sp?) shading over the screen triangles (by rendering black, partially transparent "mask" triangles over the texture layer, and filling them with beginGradientFill with a linearly varying alpha). The catch is that if you're drawing huge triangles, your lighting function is undersampled and then linearly interpolated. So any fine details in lighting, like a circular hotspot from a nearby directional light, are going to be ignored. Unless you subdivide based on lighting too... but then you're back to square 1 with lots of equilateral triangles.

The second reason is that fast rasterization is only half of the problem, the other half is handing occlusion efficiently. If your map volume is a union of convex cells, then all of your drawing regions are also convex even when they are occluded by other walls. It would be easy to program the long&skinny subdivision algorithm for this case. However, if you want to do CSG-style solids ("brushes" in the prior post), your drawing regions are now non-convex polygons, possibly with holes (yuck!). I think it would be really tricky to program subdivision for this case - the pvquake demo I gave does not even touch this problem. The easier to program alternative is to do just overdraw things, by drawing the cell and then painting the brushes back over top the cell walls. I think that would be slow. But when you're doing pixel by pixel rasterization, all this is a non-issue. You handle the funky polygon scanline by scanline in a 1D fashion, instead of trying to tesselate it into some union of triangles in 2D.

Ultimately, pixel by pixel rasterization (or scanline by scanline) seemed to gel so nicely with the map data structures (cells+brushes) that it made itself pretty appealing. The big reason you might want to pursue subdivision further is if you are unhappy with the low resolution of the pixel-drawer (which is currently 320x200 just like quake). Subdivision will scale nicely to high-res, pixel-by-pixel does not.