This project implements a C port of the C++ software renderer/rasterizer with vertex and pixel shader support.
- Generic vertex arrays for arbitrary data in the vertex processing stage
- Internal vertex cache for better vertex processing.
- Affine and perspective correct per vertex parameter interpolation.
- Vertex and pixel shaders written in C
The original code used C++ templates to inline the shaders into the rasterizer. In C, what we could do is define shaders as a macro in a special header file that the renderer would include. This has drawbacks as it assumes renderer lib will be built from the source code every time and also has a single fixed shader.
Also Vector needs to be made as header-only with static inline methods. This should give some performance boost, maybe not significant though. I think VertexProcessor uses Vector extensively, but for simple geometry in sample projects it probably won't make any difference. With such geometry, pixel shader will always be a bottleneck (we have way more pixels compared to vertices).
The idea with C++ templates was to make a pixel shader as static function that could be inlined into rasterizer and that was only possible by exposing almost the entire library (made as a set of headers with template functions) to the sample code which included all those headers through the main library header. Currently, we have all the functions in C files, instead of headers as in C++ version. If we keep them in headers again, it should be possible to static-inline them using the C macros. I'm not sure if _Generic would be of any help in this case, it can be done with plain macros.
On the other hand I have some doubts that elimination the function call would give some significant performance boost. Author of the library never tested it, he only eliminated virtual function calls as they are indeed expensive. But regular functions calls should not be bad, I doubt stack management in functions (prologue and epilogue) have high cost in this case. It would be worth looking at the assembly listing of the triangle drawing function to see how much extra instructions are injected for calling a function. Although inlining might be providing other optimizations for variables like more extensive use of processor registers instead of a stack. Anyway, it is worth looking at things at an assembly level.
This code is licensed under the MIT License (see LICENSE).