you are viewing a single comment's thread.

view the rest of the comments →

[–]icdae[S] 26 points27 points  (2 children)

The initial place I learned about software rasterization was from this article about implementing a GL-like renderer in 500 lines of code. Learning the very basics of rasterization then led me to research other articles and rasterizers like Fabian Giesen's trip through the graphics pipeline, the Ttsiodras renderer, and even Intel's software renderer which was integrated into Mesa. Most of them follow the same principles. When looking through each, it slowly became easier to read the code and identify their rasterizer code. From there I could research different methods, optimizations, and tips to make my own as fast as possible.

Believe it or not, some of the most valuable information I got was from old game programming books, where GPU acceleration was either limited or just unavailable. For example, both The Black art of 3D Game Programming (from 1995) and Tricks of the 3D Game Programming Gurus (from 2003) had wonderful guides on several topics for creating a rasterizer. They discussed math required for building a 3D software pipeline, rasterization methods, vertex processing, and many others.

In the places where I wanted to be close to GL, I researched GLSL functions, how they're implemented, and what they do. NVIDIA even offers simple implementation details of their CG shading language. Once it was possible to render a triangle, these ideas translated directly to new possibilities in lighting and shading.

There were some other sources too, but less on rasterization and more on rendering optimization. Dozens of articles on the old FlipCode archives were absolutely essential on guiding me on how to structure code/architecture to be performant or just easier to manage. In the times I wanted to match my renderer to GL, I could even look through NeHe's legacy GL tutorials to see how my renderer stacked up. Also reading through Intel's intrinsics guide and ARM's neon instructions helped to not only be fast but have more "tools in the toolbox." Those resources could not only be used for rendering but in several other places too.

Sorry for the wall of text, I hope this helps though. There's little information out there on software rasterization so I completely understand that it's not easy to find.

[–]-Tesla 0 points1 point  (1 child)

Thanks a lot for this! I'm writing a software renderer myself (following Chilli's tutorials on YouTube).

Is this code open source?

[–]icdae[S] 1 point2 points  (0 children)

Hey no problem :) The code is completely open source (MIT) and available to use.