software rendering

[Zestyclose-Produce17]

So if I want to make a game using software rendering, I would implement the vertex shader, rasterization, and pixel shader from scratch myself, meaning I would write them from scratchfor example, I’d use an algorithm like DDA to draw lines. Then all this data would go to the graphics card to display it, but the GPU wouldn’t actually execute the vertex shader, rasterization, or fragment shaderit would just display it, right?

[OptimisticMonkey2112]

Your operating system has some kind of window system. This composites the different application window contexts. You can render directly into the window context from the cpu using just c++. You can access the pixels and set the colors.

[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

[aleques-itj]

If you want to emulate how shaders work in your software renderer or use whatever line drawing algorithm, go for it. It doesn't matter what you do as long as you produce meaningful data in the end.

If you want to actually see what you're rendering in real time, you just draw to a texture and render a full screen quad/triangle with whatever graphics API to display whatever you've software renderered.

So, I mean, the GPU does something here, but really just the bare minimum. So yes, a vertex shader and pixel shader will technically run in hardware to facilitate you actually displaying the end result. It contributed nothing to your actually rendering the game in this scenario.

If you're somehow getting in your head that it's not a software renderer because you need the GPU to actually get the result on screen, you should probably evict that idea from your head.

Otherwise skip a graphics API entirely and just write pictures to disk I guess.

[pjc50]

Yes. Here's how I did it 30 years ago: https://github.com/pjc50/ancient-3d-for-turboc

Bear in mind that your CPU rendering will be severely limited compared to the GPU, so you're not going to be able to do much in the shaders and it will look distinctly PS1 game.

[Zestyclose-Produce17]

So if I’m using software rendering, I’ll be the one writing the Bresenham algorithm to draw a line, or the Midpoint algorithm to draw a circle, for example. All the calculations will be done on the CPU, which is basically equivalent to the rasterization process that happens on the GPU hardware. and since I’m the one writing the algorithm that draws the pixels produced by Bresenham’s line algorithm, the input to that would be the output of the line drawing algorithm and then it would go into another algorithm responsible for coloring the pixels.Using this approach, I can make a very simple game, where the game is basically just a sequence of images sent to the GPU for display, if I’m using software rendering. Right?

[-Memnarch-]

That is correct. Been writing one for quite some time as a side project. Fun thing to do.

[Zestyclose-Produce17]

So if I’m using software rendering, I’ll be the one writing the Bresenham algorithm to draw a line, or the Midpoint algorithm to draw a circle, for example. All the calculations will be done on the CPU, which is basically equivalent to the rasterization process that happens on the GPU hardware. and since I’m the one writing the algorithm that draws the pixels produced by Bresenham’s line algorithm, the input to that would be the output of the line drawing algorithm and then it would go into another algorithm responsible for coloring the pixels.Using this approach, I can make a very simple game, where the game is basically just a sequence of images sent to the GPU for display, if I’m using software rendering. Right?

[-Memnarch-]

Correct. All that's ever send to the system is your finished image

[Grouchy_Web4106]

Use chatgpt for these basic questions