[articulatepang]

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 hilarious visual bugs along the way.

I learned a lot! My biggest lesson, other than the specifics of how rendering works, was that modern CPUs are really fast: a single-threaded CPU renderer can definitely run an interactive 3D game with some fancy special effects.

[0x1ceb00da]

Why does it pull in wgpu if it's a software renderer?

[grovesNL]

In this case wgpu is just providing the surface texture for the window that the software rendered pixels are drawn into.

[john01dav]

Softbuffer?

(I originally wrote this a few years ago but other people maintain it now)

[LoganDark]

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

[soxfox42]

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

[LoganDark]

Oh, you're right! My bad

[articulatepang]

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.

[LoganDark]

You do often need a graphics context to create the surface that displays the framebuffer.

[delta_p_delta_x]

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.

[Lerc]

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 killing performance.

I'm not sure what would serve a similar function today,

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.

The faster and more efficient, the better. More features than needed, worse.

[pjmlp]

Before those days, the solution would be to make use of WinG, the DirectX precursor, still introduced in Windows 3.0

https://www.gamedeveloper.com/programming/a-whirlwind-tour-o...

https://betawiki.net/wiki/WinG

[stevekemp]

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.

[pjmlp]

Ah, got me hooked readying the rest of the post with the "BGI and BASIC’s painting commands" reference. :)

Great overview of the whole approach you took there.

[lelanthran]

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

[mananaysiempre]

> Not sure about Linux, too many stacks involved.

Wayland: wl_shm and that’s it for the “stack”.

[nkrisc]

Handling platform-specific details like isn't really the fun part of writing a CPU renderer, IMO.

[LoganDark]

Cross-platform support can be more difficult in that case, but yes it is possible.