Live data from Hacker News

Software rendering in 500 lines of bare C++

haqr.eu

51–60 of 83 posts

Re: Software rendering in 500 lines of bare C++

#51

Earlier quoted context omitted.

I like softbuffer, but it owns its window and doesn't support as many events / integrations as winit.

You might be confusing softbuffer for minifb here, as softbuffer doesn't do any window handling of its own. All window management and event handling happens through winit (or another crate providing a HasWindowHandle implementation).

Oh, you're right! My bad

Re: Software rendering in 500 lines of bare C++

#52

Ok I'm following along but how do I view the tga files that this program produces? Windows can't open them.

You can replace the tga with bmp which is natively supported by Windows and not difficult to implement (if you prefer to use a C library look for stb libs).

Re: Software rendering in 500 lines of bare C++

#53
In a fit of 90s nostalgia I’ve also been going back to software rendering, though I’m doing a hybrid of 2D style CLUT banks with a more modern binned triangle and barycentric technique. Since I’m sticking to a fixed pipeline look, I’ve been amazed at just how many triangles one can push even with a fairly naive draw function.

Re: Software rendering in 500 lines of bare C++

#54
post #45

on the topic of software rendering, im surprised how little gustavo pezzi's lectures get mentioned here on hacker news.

For anyone wondering, Gustavo runs https://pikuma.com/ which has a host of lectures on a variety of topics from PlayStation 1 programming to maths to triangle rasterisation.

Re: Software rendering in 500 lines of bare C++

#55
post #14

This resource, along with Mathematics for Computer Graphics by John Vince [1], was truly indispensable when I wrote my own software renderer [2]. This was long before LLMs, so the whole process took me at least a couple months - most of it trying to wrap my head around math behind computer graphics and tracking down C segmentation faults. Fun times. [1]: https://www.amazon.co.uk/Mathematics-Computer-Graphics-John-...…

Is the source of yours public anywhere? I'd like to take a look.

Re: Software rendering in 500 lines of bare C++

#56
post #18

Earlier quoted context omitted.

I'm clearly super old-school when it comes to rasterisation, and a lot of this has flown above my head. I have a ton of questions; I hope you can answer them. > (1) discard (fast but not a great user experience) What are we discarding here, and why is it fast but not a great user experience? > (2) primitive synthesis I assume this is retriangulating clipped triangles that are now no longer triangles? > reverse transf…

Sorry I was so terse! Let's ignore guard band, for now. Our rasterization surface is a rectangle. We don't need to "geometrically clip" a triangle to the rectangle's surface. Instead, we just walk the surface of the rectangle and ask two questions: (1) does the triangle capture this (sub)sample; and, (2) what's the interpolated value of the attributes at this (sub)sample. In practice, for software rasterizers, we're…

Not OP, but thanks for the very detailed response.

Re: Software rendering in 500 lines of bare C++

#57
post #4

I 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.

I have a whole chapter on that! https://gabrielgambetta.com/computer-graphics-from-scratch/1...

I bought and I am reading through your book as I build a sw rasterizer. On the chapter of clipping, it was not entirely clear to me how many planes you clip against and how many triangles result.

Presumably if you clip against all 6 planes, you get 3+6-2 = 7 triangles in the worst case, which is kind of annoying. However, if you're going to use the AAAB triangle raster method as described in this HN post, then it seems there's no need to clip against left/right/top/bottom planes of the frustum, since it is simpler to just clip the screen-space AABB of the triangle instead. So one just needs to clip against near/far. This is simpler and faster.

I was curious if you had given any thought on that, or if you plan on working on a second book with more details on these nuances.

Re: Software rendering in 500 lines of bare C++

#58
post #47

Earlier quoted context omitted.

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…

I have done this on a number of platforms over the years. Going back to before createDIBSection existed (In fact I had something break when Windows provided an easy path and took away the method I had been using). Linux has always been a weird kettle of fish, the thing that worked best for me was imlib2 which was originally part of enlightenment. It did what it was supposed to do, hid pixel format conversion without…

> If anyone knows of a library that takes a rectangle of memory, a pixel format and places it onscreen regardless of the display environment I'd like to hear about it.

I've used SDL for this in the past.

Re: Software rendering in 500 lines of bare C++

#59

I 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…

[flagged]

Re: Software rendering in 500 lines of bare C++

#60
post #47

Earlier quoted context omitted.

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…

I have done this on a number of platforms over the years. Going back to before createDIBSection existed (In fact I had something break when Windows provided an easy path and took away the method I had been using). Linux has always been a weird kettle of fish, the thing that worked best for me was imlib2 which was originally part of enlightenment. It did what it was supposed to do, hid pixel format conversion without…

https://zserge.com/posts/fenster/ is what I used when I wanted "basic graphics" in a cross-platform way.

But of course that's X11 and much simpler.

Post reply on HN