Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software rendering in 500 lines of bare C++

haqr.eu

Post reply on HN
Print view View original

41–50 of 83 posts

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

#41

Post by LoganDark »

delta_p_delta_x wrote: post #40
LoganDark wrote: post #28

Earlier quoted context omitted.

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…

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

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

#42

Post by mananaysiempre »

delta_p_delta_x wrote: post #40
LoganDark wrote: post #28

Earlier quoted context omitted.

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…

> Not sure about Linux, too many stacks involved.

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

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

#43

Post by Sharlin »

blt wrote: post #39
Sharlin wrote: post #21

Earlier quoted context omitted.

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.

Essentially, yes. The points of any edge that crosses the near plane escape to the infinity and if you naively just w-divide the endpoints, the image of the lineseg is not the points between the endpoints, but actually all the other points on the line that "wrap around" through infinity. The projective space not only contains all the points at infinity, it identifies each pair of infinity points "opposite" to each other (and then maps them to the w=0 plane), so lines are actually loops and between any two points there are two distinct line segments, an "internal" and "external" one. This is disconcerting to say the least.

Moreover, all geometry that is fully behind the camera will actually get projected in front of the camera into the distance by the w division because they have zthink clipping against the back plane would get rid of these, but it's still weird. And now my brain hurts.

Historically, of course, divisions were expensive and culling as much as possible before the perspective division was a performance question as well.

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

#44

Post by layla5alive »

fithisux wrote: post #23

This is a very good article.

Is something broken on mobile? It has code for writing a few pixels to a tga and then shows you how to clone their repo and then shows some photos... There is.. no real article..?

Edit: Ah: there's a quiet hamburger menubar. The page really should have forward/next/toc links.

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

#46

Post by CyberDildonics »

mootdentures wrote: post #31
uncivilized wrote: post #19

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

They just said it should have a date and it should.

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

#47

Post by Lerc »

delta_p_delta_x wrote: post #40
LoganDark wrote: post #28

Earlier quoted context omitted.

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…

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.

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

#48

Post by soxfox42 »

LoganDark wrote: post #35
john01dav wrote: post #34

Earlier quoted context omitted.

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.

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).
Post reply on HN