I thought this would be something new but it’s just ssloy’s tinyrenderer. Article should have a date since it’s old as dirt
Just because you've seen something before doesn't mean it isn't new for some readers! This is my first time seeing it
Software rendering in 500 lines of bare C++
31–40 of 83 posts
Re: Software rendering in 500 lines of bare C++
#32Ok I'm following along but how do I view the tga files that this program produces? Windows can't open them.
Re: Software rendering in 500 lines of bare C++
#33Ok I'm following along but how do I view the tga files that this program produces? Windows can't open them.
Irfanview?
Re: Software rendering in 500 lines of bare C++
#34Earlier quoted context omitted.
Why does it pull in wgpu if it's a software renderer?
In this case wgpu is just providing the surface texture for the window that the software rendered pixels are drawn into.
Softbuffer?
(I originally wrote this a few years ago but other people maintain it now)
Re: Software rendering in 500 lines of bare C++
#35Earlier quoted context omitted.
In this case wgpu is just providing the surface texture for the window that the software rendered pixels are drawn into.
Softbuffer? (I originally wrote this a few years ago but other people maintain it now)
I like softbuffer, but it owns its window and doesn't support as many events / integrations as winit.
Re: Software rendering in 500 lines of bare C++
#36I wish we could have just one of these tutorials properly cover the concern of triangle clipping. This is the part that I struggle with the most in a software renderer. If you are going to be building a practical one, this is something you will eventually have to deal with, even for super basic scenes. Any time geometry intersects the view frustum you need to clip those triangles.
My renderer attempts always got stuck on the "should implement clipping" phase too, until I finally bit the bullet and managed to write a working one without much effort, independently "rediscovering" the Sutherland–Hodgman algorithm [1] as I found out later (googling it beforehand would've been cheating, of course). The algorithm itself is fairly straightforward and intuitive, I think the biggest mental block is the…
[deleted]
Re: Software rendering in 500 lines of bare C++
#37Earlier quoted context omitted.
Why does it pull in wgpu if it's a software renderer?
In this case wgpu is just providing the surface texture for the window that the software rendered pixels are drawn into.
Yes, exactly this -- it's a fast and convenient way for my code to just write the pixels into a spot in RAM (the CPU's RAM, not VRAM) and have those pixels end up on screen. On modern architectures this nearly always goes through a GPU, so even if you're not using the GPU to accelerate your 3D rendering/math, you gotta deal with it just to put pixels on a screen at the end of the day. So that's what wgpu does for me.
Re: Software rendering in 500 lines of bare C++
#38I went through this a few months ago in Rust. I wrote all the code by hand, no LLMs. Then I went ahead and added a small "game" on top, plus some special effects like pixelization shaders and chromatic aberration at the edge of a flashlight. https://github.com/kshitijl/tinyrenderer-rs if anyone is interested! The repo has lots and lots of in-progress screenshots so you can see the renderer come to life, plus all the…
[dead]
Re: Software rendering in 500 lines of bare C++
#39I wish we could have just one of these tutorials properly cover the concern of triangle clipping. This is the part that I struggle with the most in a software renderer. If you are going to be building a practical one, this is something you will eventually have to deal with, even for super basic scenes. Any time geometry intersects the view frustum you need to clip those triangles.
My renderer attempts always got stuck on the "should implement clipping" phase too, until I finally bit the bullet and managed to write a working one without much effort, independently "rediscovering" the Sutherland–Hodgman algorithm [1] as I found out later (googling it beforehand would've been cheating, of course). The algorithm itself is fairly straightforward and intuitive, I think the biggest mental block is the…
This is a great comment. As someone who is familiar with R^3 geometry but not projection or clipping, I feel like I could almost implement it from your comment alone.
Can you explain more about clipping before/after the divide by w operation? Is this about avoiding coordinates with w = 0? Otherwise all the geometric ideas seem to make sense in both the world/view-space frustum and the ±1 box.
Re: Software rendering in 500 lines of bare C++
#40Earlier quoted context omitted.
Why does it pull in wgpu if it's a software renderer?
You do often need a graphics context to create the surface that displays the framebuffer.
Not necessarily.
Most desktop OS compositors provide a void** buffer that can be blitted to. Sure, this buffer will probably end up going through the compositor which does GPU hardware acceleration anyway, but it is definitely possible to shrink the application-side stack without relying on D2D/GLUT/GLEW/GLFW/SDL/WGPU in this case.
On Windows: CreateDIBSection and BitBlt
On macOS: CALayer and CATransaction commit
Not sure about Linux, too many stacks involved.