Nothing's gonna make you hate life more than low level graphics programming

pfft

least you get something out of it

@jestdotty Pain and misery mostly

@12bitfloat and seeing some pixels, eventually!

At least there's a valid intellectual challenge involved.

Try being "that guy who can fix your spreadsheet no matter how much of an abortion it is".

I do see the good devs moving to graphics programming quite frequently. tsoding is also into graphics.

But you're doing low level graphics programming for ages / for a living right?

@jestdotty Hopefully!

@retoor For 10 years now as a hobby (and potentially soon as my main income maybe hopefully) :D

You'd think it would get easier with time but somehow it only gets harder the more you know. Kind of like C++ now that I think about it...

How low level?

@Hazarth Deepest depths of vulkan programming. Compute shader based software rasterizers included

@12bitfloat yh, some things are like that. I had it with learning C a lot. You think you master it and dang - some magic. Ego broke many times. Still, often when I read C code back - omg. But all my stuff is memory checked I count of mallocs and the valgrind, so at least that goes OK.

@retoor Just wait till you do C++... Whole new universe of "what the actual fuck is this rule" :D

You know in Rust it's insta UB to create a temporary mutable reference from a raw pointer if any other reference could also exist at the same time. Fun! But that's just llvm being dumb :D

C is more relaxed but you maybe also have some UB in your code... It's pretty damn complex

@12bitfloat oh neat. I did some small stuff with Vulkan but didn't get too deep. Though I did make my own game engine with OpenGL in the past, also including shaders. Was fun for a while, but yeah, the overhead compared to just using SDL or Raylib gets a bit old eventually

I like programming

@Hazarth Once you go deep it gets really deep into the weeds

Choosing how to upload data, on non-rebar systems with a buffer in the max 256 MB sized BAR memory pool, vs persistently bound

Strategies to batch draw calls. Bindless rendering of all sorts. GPU driven rendering with a compute shader passes generating indirect draw commands. Even just saying fuck it and implementing a software rasterizer in a compute shader which writes pixels out using a 64-bit atomic max (like UE5 nanite)

Really the worst thing about it all is that it isn't hard to find a solution. But for rendering it's all about performance. So there's *always* a better solution to be found, and that's deeply frustrating. You can never relax and pat yourself on the back. Because your solution probably sucks

What is bad about it? I’ll be moving to that soon, just vulkan.

the joy of doing that is reserved for autistic people, unfortunately.

you misspelled "managers"

@ars1 Just vulkan alone is frustrating as shit to learn

And then you want to actually write an efficient renderer...