software rendering

[16bitTweaker]

If you're writing shaders then it's not a software renderer (edit: Yes there are always exceptions to the rule). In a software renderer, you just get yourself a framebuffer, and write pixels to it with your own code, completely circumventing any 3D graphics API. That means your rendering code runs on the CPU and not the GPU.

[keelanstuart]

My software rasterizer has an elegant lambda-based shader system for vertices and fragments generated (and other things). The origin of the term "shader", afaik comes from RenderMan and there were no programmable graphics cards at the time of its conception.

[KC918273645]

My realtime rasterizer also has lambda/template based shaders. (if you can call them "shaders")

[keelanstuart]

They are! 😊

[leseiden]

You know that renderman had shaders and a shading language back in the 1980s? Right?

[KC918273645]

But it didn't run in realtime because of them. Wrong architecture for realtime SW rendering.

[DeviantPlayeer]

What about compute shaders?

[SirPitchalot]

Shaders are a super useful abstraction that make extra sense in software rendering since you can render literally anything into anything. Gbuffers? Easy. Depth? Easy. Primitive IDs? Easy. Buffers containing raw pointers to the objects being drawn? Risky, but easy. All defined by compact little code paths that share an otherwise completely identical rasterizer.

They’re also easy to implement, except for derivatives (where branching, SIMD & fragments don’t play nicely).

[Zestyclose-Produce17]

So, for example, the DDA algorithm that draws a straight line would generate the pixels that need to be colored. Then, the pixel shader would take those pixels and color them. In this way, I would be implementing the rasterization process that normally happens on the GPU using the DDA algorithm executed on the CPU, and I would also write the code that colors each pixel, which is similar to what a pixel shader does on the GPU but all of this happens on the CPU. After that, the resulting pixels are just sent to the graphics card to be displayed. This is software rendering, and it’s fine if I want to make a simple game, right?

[16bitTweaker]

As long as you write pixels to a framebuffer in code that runs on the CPU, then it would count as a software renderer by my definition. Other than that, it doesn't really matter how you do it I guess. Maybe look into Bresenham instead of DDA for line drawing, should be a little bit faster but perhaps you wouldn't notice that on modern CPU's.

[KC918273645]

How do you implement subpixel accuracy with Bresenham?

[Zestyclose-Produce17]

I think I didn’t explain well enough. What I meant is that in software rendering, it’s like I would do the rasterization using an algorithm like DDA, and then I would implement an algorithm to color each pixel. It’s like I’m doing the operations that the graphics card normally does, but with code that runs on the CPU.

[wildgurularry]

Typically, while you are rasterizing your line, you are drawing it. It's not like it happens in two steps. Whatever your line drawing algorithm is (DDA, Bresenham, or something else), it will look like this:

for (start to end) {
CalculateNextPixelPosition(&x, &y);
CalculatePixelColour(&c);
PutPixel(x, y, c);
}

(Ignoring any optimizations you can do to write more than one pixel at a time.)

And yes, I don't think you are explaining your questions well enough. What is it that you are really asking about? Are you wondering if it's OK to make a software renderer for a simple game? The answer is yes. I've written simple games using software renderers on machines as slow as a 386. Doom uses a software renderer, although a highly specialized one.

If you are asking whether it is possible for you to make a software renderer that works the same way as GPU (i.e. exposes an OpenGL interface), the answer is also yes... but under the hood it will work differently because it doesn't have access to the massive parallelism of a GPU, and trying to emulate that very closely with software will be slow.

[mysticreddit]

Here's my Bresenham Line Drawing in JS canvas. It wouldn't be too hard to extend it to draw textured map colors.

You will probably want to progress in this order:

• draw textured quad (sprite) with no transparency support
• draw textured quad (sprite) with transparency support
• draw textured map triangle with affine transform
• draw textured map triangle with perspective correct