Graphics Programming Resources(develop--gpvm-website.netlify.app)
develop--gpvm-website.netlify.app
Graphics Programming Resources
https://develop--gpvm-website.netlify.app/resources/
26 comments
It was me. I saw your post from over at lobste.rs "what are you doing this week" [0]. I've had the tab open for a couple days and I thought people over here at HN would like it (and I was right).
Anyway, thanks for the resource. I'm sure people would be interested in the parent page, "Graphics Programming Virtual Meetup" as well:
https://gpvm-website.netlify.app/
[0] https://lobste.rs/s/dppelv/what_are_you_doing_this_week
Anyway, thanks for the resource. I'm sure people would be interested in the parent page, "Graphics Programming Virtual Meetup" as well:
https://gpvm-website.netlify.app/
[0] https://lobste.rs/s/dppelv/what_are_you_doing_this_week
The link just below the title indicates it was submitted by 'abetusk (https://news.ycombinator.com/user?id=abetusk).
Great resources abound. However, learning graphics programming is hard and requires a deep understanding of both the algorithms and the APIs to do anything non-trivial.
Sadly, there are fewer people than ever on HN who care about deeply understanding either of these in the age of agents.
Sadly, there are fewer people than ever on HN who care about deeply understanding either of these in the age of agents.
As someone who's learned Vulkan to a fairly deep level over the last two years I've found learning with LLMs invaluable, especially for explaining concepts and the whys behind things.
That said debugging graphics bugs has to be some of the hardest things you can do as they generally manifest as driver crash followed by VK_DEVICE_LOST error. Vibe debugging these inside a 60k vibecoded rust renderer is... just not possible.
Agents can get you the initial boilerplate for setting up most of the resources, but are completely clueless about subtle issues with synchronization, transitions, formats and so on.
That said debugging graphics bugs has to be some of the hardest things you can do as they generally manifest as driver crash followed by VK_DEVICE_LOST error. Vibe debugging these inside a 60k vibecoded rust renderer is... just not possible.
Agents can get you the initial boilerplate for setting up most of the resources, but are completely clueless about subtle issues with synchronization, transitions, formats and so on.
I had hoped for some more basic stuff. I struggle for 2 months now to implement a fast line draw with width for a embeed cpu. It only has a framebuffer no gpu
The bible of graphics programming, everything with software rendering,
"Computer Graphics: Principles and Practice"
https://www.informit.com/store/computer-graphics-principles-...
Yeah, it is a steep price as many academia books, maybe you can find it on a library nearby, as its first edition was in 1982.
"Computer Graphics: Principles and Practice"
https://www.informit.com/store/computer-graphics-principles-...
Yeah, it is a steep price as many academia books, maybe you can find it on a library nearby, as its first edition was in 1982.
This book is quite old. I would argue that Realtime Rendering 4th edition is the better book. Bonus points if you pair it with some online resources to get a deeper understanding of the topics (but the textbook contains follow up material for all discussed topics).
Depends on the edition, the last one is from 2013 uses C# for most of its examples.
It might not be great for 3D rendering algorithms, then again that is the hardware time that WebGL 2.0 and WebGPU are stuck with.
It might not be great for 3D rendering algorithms, then again that is the hardware time that WebGL 2.0 and WebGPU are stuck with.
There's a Bresenham variant for thick lines. It's a bit hard to wrap your head around.
https://homepages.enterprise.net/murphy/thickline/index.html
http://kt8216.unixcab.org/murphy/index.html
https://homepages.enterprise.net/murphy/thickline/index.html
http://kt8216.unixcab.org/murphy/index.html
"Basic" is a relative term. Modern graphics GPUs do not work the same way memory mapped graphics do, and working with them is different at a fundamental level.
You are probably better off searching for old graphics programming books from the 90s. The code they have likely won't work, the the algorithms should be what you're looking for, and shouldn't be hard to adapt.
You are probably better off searching for old graphics programming books from the 90s. The code they have likely won't work, the the algorithms should be what you're looking for, and shouldn't be hard to adapt.
Fundamentally different? Don't GPUs just speed things up in hardware?
No. With the old style you had to draw every pixel, and you'd have to develop primitives for drawing a point, a line, or a triangle. With a GPU you essentially give the GPU a bunch of data and tell it to draw points, lines, or triangles for you. You then create "shaders" which are functions that the GPU calls to ask where to position a vertex, or what color to make a pixel, with some "magic" that passes data between the two. It's best understood by looking at the code for the almighty gradient triangle: https://webgpufundamentals.org/webgpu/lessons/webgpu-inter-s...
It's all those parts which, in the absense of GPU, would be done by CPU. No qualitative difference.
I've used this one:
https://gist.github.com/ArminJo/8dc4e61847a693e99bdde919cc70...
https://gist.github.com/ArminJo/8dc4e61847a693e99bdde919cc70...
Fast, thick lines, no gpu
Choose 2
Choose 2
It's non-trival though not that hard. Have you asked an LLM?
It depends on your needs
* You can compute a rectangle by expanding a line purpendicular to its direction
The problem with this is you'll get gaps between 2 lines if they are supposed to be connected. You can solve that by trying to connect the corners if the rectangles. Once you do this though you're no longer drawing rectangles. You might have to make a simple triangle rasterizer. Or a scanline rasterizer
* You can "drag a brush". You compute a single line, then at each pixel, draw a sprite/circle/rectangle around that pixel. That's slow because you'll draw every pixel more than once but it will work and might be fast enough
This has the issue with the ends will be different unless your brush is round. If that's ok then it works.
All of these are something you can ask Gemini, ChatGPT, Claude, and they'll spit out an exmaple in the language of your choice.
It depends on your needs
* You can compute a rectangle by expanding a line purpendicular to its direction
The problem with this is you'll get gaps between 2 lines if they are supposed to be connected. You can solve that by trying to connect the corners if the rectangles. Once you do this though you're no longer drawing rectangles. You might have to make a simple triangle rasterizer. Or a scanline rasterizer
* You can "drag a brush". You compute a single line, then at each pixel, draw a sprite/circle/rectangle around that pixel. That's slow because you'll draw every pixel more than once but it will work and might be fast enough
This has the issue with the ends will be different unless your brush is round. If that's ok then it works.
All of these are something you can ask Gemini, ChatGPT, Claude, and they'll spit out an exmaple in the language of your choice.
Those are bad answers. Really bad.
What part of them were bad? And where is your contribution?
Asking Gemini spit out this:
https://godbolt.org/z/fzfnY6r39 - using a brush
https://godbolt.org/z/hdKe1b71P - using triangles for miter support.
Asking Gemini spit out this:
https://godbolt.org/z/fzfnY6r39 - using a brush
https://godbolt.org/z/hdKe1b71P - using triangles for miter support.
It's not my responsibility to educate you. Especially if you won't take the time yourself to understand the problem.
I suggest you read through the sibling comments.
I suggest you read through the sibling comments.
Nothing on volumetrics.
Well, do I ever have a treat for ya!
https://voxel.wiki/wiki/references/
https://voxel.wiki/wiki/references/
Ok
Created an account just to say this