Implementing a Tiny CPU Rasterizer

Summary

Implementing a tiny CPU rasterizer Part 1: Clearing the screen 2024 Oct 30 The code for this part is available in this commit. In the OpenGL course I'm teaching at a university, my students learn that the GPU uses something called rasterization to draw stuff on the screen. Then, I explain how — in theory — rasterization works, e.g. how would one write the code to draw a fixed triangle on screen. Of course, the GPU does that for us, but it is nice to understand that what it does is not some dark magic, but actually some pretty simple algorithms. Well, for the most part. Then one day I had a very strong itch in my head: why don't I try actually doing this? Why don't I implement triangle rasterization, just for the fun of it? And I did, and it didn't take long to have the first triangle appearing on screen. I was happy and satisfied. But then I had another itch: what if I turn this thing into a full-blown rendering engine? What if I implemented most of the fixed-function pipeline of old-school graphics API's? And what if I document the process? So, that's what it is, my journey on creating a CPU-only 3D rasterization engine from scratch, documented in the form of a tutorial series. Contents But why? If the GPU and graphics APIs do all that for us, why bother with emulating that on a CPU? Well, it definitely doesn't make sense if your goal is to create a 3D game or something similar, making a CPU rasterizer is usually pretty much a waste of time in this case (unless your game is really light on rendering and you want to add some crazy rendering effects that are easier to do on CPU than on GPU; or maybe you're doing it just for the fun of it). However, there are still some legitimate reasons to do that: It is a good programming exercise. There's some low-level stuff, some algorithms, some maths, some graphics, all mixed into a single standalone project. It is a great way to learn what GPU does. Implementing a thing yourself from scratch is the best way to understand how ...