As I’ve previously mentioned, I’m working on overhauling NRender to make it ready for my next game. This includes cleaning things up and streamlining APIs, but also implementing techniques and algorithms that have been missing so far, but are also really nice to have.

One of these techniques is the ability to render 4-vertex faces, also called quads. Up until now, every face you see was actually a triangle. If a face had more vertices than 3, it would’ve been split into triangles. There were no other shapes from the view of the renderer.

Now, OpenGL, Glide and Software renderers can make use of faces with 4 instead of 3 vertices. This provides a pretty big performance gain. But why?

Tris are easy, but intense

To understand this, consider this:

What you see is the model for the small asteroid you see in-game (right in the first stage, for example). It consists of 11 4-vertex faces. One of them is higlighted for the sake of this discussion. There are also 3 3-vertex faces on top (a bit hard to see, admittedly). This makes 14 total faces.

Now, remember: The renderer wasn’t able to render 4-vertex faces up until now. So each face had to be divided into 3-vertex ones, which looks like this:

This turns a total of 14 faces into 25 3-vertex faces. One part of why this is slow is immediately apparent: There’s more faces! Instead of walking through 14 face definitions, the renderer has to consider 25 of them - each frame!

There is an additional source, however. When doing this conversion (“triangulating”), each 4-vertex face is turned into two 3-vertex faces. You can see this easily with the highlighted one(s). Two things result from this: There is now more vertices in total (6 vertices, instead of just 4) AND two of these vertices are always the same for each 3-vertex face. That’s a huge waste of CPU.

The bottleneck

When drawing, one of the first steps the renderer has to do is to transform each vertex according to the geometry and vertex matrices. I won’t go into details on how these two matrices are set up and used in NRender in this post. What I will tell you, however, is that these transformations are really slow. They are especially slow on x86 platforms, as DOS and Windows are, as the renderer has to implement matrix transformations entirely in software.

Not only are there more vertices to process when triangulating quads(6 instead of 4), but two of them are entirely redundant. The duplicate ones go through transformation (slow!) like normal, wasting precious CPU cycles big time.

This turned out to be a major bottleneck when I profiled the runtime characteristics of NRender and Apus. I was able to optimize things with Apus 1.2.0, but there is only so much you can do without some kind of vector/SIMD hardware operations (which are not available on a 486).

Quads to the rescue

So, when you’re not able to optimize a routine any more, you just try to run it less often. And that’s exactly what quad rendering does!

Instead of triangulating quads to triangles as described above, I just… don’t! Instead, I’ve equipped the renderers with the means to draw 4-vertex faces themselves. This means there are less faces in total, less vertices to transform and less shared vertices that waste CPU time.

The results are most staggering with the Glide renderer: Apus goes from an average of about 12.68 FPS (486DX4-100, Voodoo 1) to 16.22 FPS on the same hardware! That’s about a 28% performance gain from just one change - a huge win.

Other renderers don’t benefit from this change quite as much for various reasons. But every one of them will be quite a lot faster.

Version 1.2.1

These changes will roll out with Apus 1.2.1, which I will release shortly. There are a lot of other behind-the-scene changes, this is just one I wanted to single out and present to you. Stay tuned!