Comment by and0 | Hacker News Reader

Comment by and0 | Hacker News Reader

Parent Full thread

I started a DirectX (so, HLSL, basically identical from my understanding) and C++ project about a year ago. I hadn't worked with either, but managed to get a little window up and running within a weekend. That was mostly thanks to some templates out on the web.

The reason I think it deserves to be called "arcane" is that, to even reach an RGB triangle (the shader equivalent of "Hello World"), you have to have dozen different things working all at once:

- Writing / compiling the shaders (vertex and pixel/fragment, at least) - Loading the shaders - Describing the vertex data - Creating vertex data - Describing constant buffers - Creating constant buffers for vertex + world/view/perspective - Filling all the buffers with data - Giving the right data for view / perspective matrices (the camera, basically) - Calling the rendering of a mesh - Getting the output to draw on the screen - + a ton of other drawing descriptions I don't even remember, like raster descriptions

For all of those tasks there is an insane amount of boilerplate that needs to be written. This is okay in itself, since it's all stuff that's worth tweaking for various use cases, but it creates a pretty insane barrier to entry. Not everyone needs to learn all the quirks of setting up vertex buffer descriptions right up front. I personally wasn't going to read a huge DirectX bible just to see how to get started.

It's a problem very much deserving of a copy+paste solution, with some clear instructions on how to tweak for individual needs, but most tutorials (MSDN or otherwise) concentrated on specific features or were in a series building on an already opinionated codebase / pipeline. And if any part of it doesn't work, and you'll be second guessing yourself and asking a ton of questions with every line of code, you have no real way of knowing what went wrong.

However, once I had a pipeline set up (and then started organizing it in a way that it managed itself and could host various shader types) I started having a lot of fun. I'm working on a 3D NES emulator [http://n3s.io] and felt super inventive when I found a way to get the models to render using the NES palette.

It's interesting: In most areas of software, progress over time means moving up in the abstractions. A framework or library starts out with the low level nuts and bolts, requires a lot of boilerplate, large learning curve, harder to get to "hello world", etc. Then, over time, people add convenience layers, simplify, abstract away hardware specific bits, etc. and you end up with fewer lines needed to achieve something that works well.

In the graphics world it's been the other way around. Earlier libraries were higher level, abstracted away a lot, letting you get to "hello world" very quickly. In ancient OpenGL 1.x immediate mode, "Hello triangle" is a handful of lines of code (minus the non-portable window management stuff). As we've moved to vertex buffers, moved away from the fixed function pipeline, less and less is abstracted for you and you have to deal with more and more granular constructs, more and more quirks, and more and more boilerplate. I haven't even started coding with Vulkan, but from what I know about it, any application I'd want to move over to it is probably going to quadruple in terms of line count, complexity, and "things to deal with".

OpenGL is not a general purpose graphics library, it's an API to control the actual graphics hardware, as such it follows the hardware, not the user experience. Older GPUs had been very primitive and did not require a lot of commands to do something. For example, the PS2's GPU, GS, was a kind of GPU the OpenGL 1.x targeted. It had hardware registers for vertex position, color and texture coordinate. After every three writes into the position register it would draw a triangle into the current frame buffer (setup through a couple of registers with address, dimensions and format). If you enable a texture (a couple registers), it will draw textured triangles, if not - no big deal. So the OpenGL's glVertex functions mapped nicely to that hardware.

On a more or less modern GPU you won't find those registers. The GPU reads a stream of commands instead of polling its registers. And the most primitive command is DRAW, which means "run the current vertex shader for the given index range, collect its output, rasterize the primitives made from the output and run the current pixel shader on the resulting pixels". So in order to draw anything it's required to have a command stream set up, two shaders set up and necessary data bound to both shaders. Naturally, there is no place for glVertex() in this setup.

There are high level libraries, which abstract the hardware but it's not the purpose of the OpenGL. It's only "abstracting" hardware in the sense that it works same on different models of GPU but it tries to expose as much of the hardware as possible in a model-independent manner.

That's because a middle layer emerged on top, the game engine.

You kind of have to do that stuff, though. There's no getting around understanding linear algebra and feeding vertices into the GPU. It's kind of like the bare minimum you need to swim. Yeah you gotta learn it and there's some funky techniques, but you gotta tread water somehow, yeah?

It is a lot to learn at once, but no more than web dev where you are learning html and databases and HTTP and god knows what else at once. And like you said once you grok it, it's pretty easy.

Graphics programming terrified me for the longest time because people acted like it was dark magic and hard. Figuring this stuff out slowly but surely it shocks me how little there is to it and I wish someone would have told me sooner.

I've gotten rendering a cube down to an art (gotta start somewhere). You're talking ~100 lines of JS and double that of C++ but no more than that in any decent language. And that's a cube (or multiple) and a basic camera.

A library like regl shows how simple this stuff can get without lots of boilerplate.

https://github.com/regl-project/regl/blob/gh-pages/example/b...

Boom a triangle in 40 lines, but the underlying process of vertices, buffers, shaders, etc is apparent. Cool stuff.

Those asking about Vulkan - Vulkan only increases the boilerplate by design.

The thing about Vulkan is it moves a lot of the boilerplate out of the driver and into your app. That way you can just tell the hardware what to do (and not to do) without the driver trying to read your mind via API calls and optimizing that way.

> Graphics programming terrified me for the longest time because people acted like it was dark magic and hard

Now that I am becoming old, I have started to realize that anyone who creates a feeling of dark magic around almost any programming subject probably doesn't understand the subject very well themselves and has some sort of self-confidence issue that makes them portray whatever it is that way to people who know less than they do.

I think "dark magic" in a lot of these cases is just a lot of domain specific knowledge to get a general understanding of the topic. I think the Internet has really helped. With a "dark magic" topic like graphics, you can get started with a little bit of domain knowledge and the right template code (which wasn't as easily available before the Internet). Without the right template code, you're doing a lot of yak shaving and having to learn a whole lot at once just to get a triangle on the screen.

Reply on news.ycombinator.com