If you want to make games, use an existing engine. Unreal Engine, Unity, Godot, and Bevy are good choices. You'll learn the higher level issues of graphics, not how to push pixels around. The real problem is making it fun.

If you want to do 3D engine programming, be aware that there are too many bad game engines. In Rust land, where I am, there are three failed renderers, one unfinished one, and the one inside the Bevy engine. Those are the major projects. There are many other "I'm going to build a game engine" projects. Building a game engine takes about two years to get to the My First Renderer point. Getting to big, highly detailed, dynamic scenes is a much bigger job. Be aware of the scale difference between the first demo and a useful engine.

If you want a job, be aware that the game industry sucks. Pay is lousy, hours are lousy, jobs end when the project is completed, and, like Hollywood, there's an army of wannabees wanting in. Also, right now, because of the collapse of the Metaverse thing, there's a glut of experienced people.

Then there's mobile. Everything is a cram job. Not enough screen, not enough compute, not enough GPU, not enough battery.

This is why most indy games now are 2D. That's do-able. Often in HTML/JavaScript.

I started in 2001, when NVidias first Geforce 1 ("the Gigatexl shadercard") was first announced: The field developed since then with so much speed and innovations, it blows my mind of. Compared to what we could do 25years ago, the tech today is just fu*ing impressive.

Though, with this impressiveness comes a big "but": The space is developing at a speed which is really really scary. Nvidia came up with AI-based effects to influence scene & assets on their own - back then, we wouldnt have even thought about that this will be possible some day in realtime.

I do not know if its possible at all to be a "decent pro" in this field now - let me use other words: "Where is todays Jon Carmack?" - he was famous for squeezing everything out of the hardware, using ideas very hidden in the community etc. - today, there is not any competitive moat for people like him (he actually lives on his legacy), and that is because the field is so vast and evolving so fast that there is no chance to become the next one

I also have some notebooks with SymPy code examples here: https://github.com/minireference/noBSLAnotebooks

Graphics aren't my specialty, but as a musician, sound designer and producer, by far the most effective/influential audio DSP coders I'm aware of understand the basics of music, the physics/acoustics of sounds, and the gotchas at the interface between discrete digital processes and how we perceive and interpret stimuli.

Don't learn if you do it with a monetary end goal as it's fleeting, ephemeral and not guaranteed in this day and age.

If you just want to make a game, use a game engine like Unity, Godot or Unreal.

If you want to do graphics, like making engines, simulations, renderers then you should learn a low-level language and a graphics API. For the language I recommend C++, you can also use C or Rust but C might be a bit too difficult and you don't want to fight the language since graphics APIs are already hard. Rust might also be a good choice but I personally find the compile times very slow and the syntax to be ugly.

As for the API, go with OpenGL, it's cross-platform, old (which is good and bad at the same time) and is the easiest of them all.

learnopengl.com is by far the best tutorial on opengl, so I suggest following that.

After using opengl for a while you can branch out and use something like Vulkan or a graphics library that implements all of them, or even keep using opengl if its fine for you.

It's definetly not easy but it's one of the most fascinating parts of CS imo

Good article on color management in general, which has a great intersection with foundations needed for graphics programming: https://chrisbrejon.com/cg-cinematography/chapter-1-color-ma...

This guy has some good art: https://www.khanacademy.org/profile/kaid_1019042693170894950...

I come from reading about CRDTs from Evan Wallace and also having built a product used by >40M users.

It applies to software products too!

In their words…

If you want to build products, use React or even vibecode; you will learn higher-level issues of solutions to problems (i.e. people problems rather than machine problems), not how to push data/state/computation around. The problem is solving a need.

Neither is good nor bad; just be clear about your goals and then it’ll be easy to decide if you want to follow Zynga’s cofounder, Jonathan Blow, or Notch! And before you rush to answer… consider whether any of them are happy.

For people who recommend against learning these skills because “what Carmack did is not possible anymore.”… well, if what you look for is money then yeah! But, if you just want to learn for the love of the game, then that would be a very bad advice!

If you want to work with Windows, probably DirectX.

2. Make awesome shaders. Check this out: https://fragcoord.xyz

I would say being a long-time user of Photoshop and Blender helps a lot. It's not a main tool, but supplemental. Maybe AI will take over some of this though.

Hell, maybe that other stuff too, hahaha!

Once you have that intuition, the rest is all figuring out the stages of the graphics pipeline and the frameworks like opengl and their constituent data structures.

Perhaps I'll write such a book... after I finish my game (dry laughter).

[0]: https://thebookofshaders.com/

Make the bold choice. Be a game network programmer. Nobody wants to do it, it's really hard and it kinda sucks.

Play the accordion :)

I’m going to revisit raycasting with a browser based raycaster from scratch.

I’m just finishing up a webgl + canvas game engine and game for a 2D top down grid strategy game first

Linear Alegbra Done Right Calculus Better Explained Concrete Mathmetics.

Then you can move on to the low level APIs.

The most useful resources I've found for graphics are scratchapixel, UC Davis' graphics lectures, songho's articles, and Essential Math for Games and Interactive Applications. I highly recommend you read this last resource front to back. Seriously, its the best freaking math reference for graphics out there.

But knowing theory is not sufficient. You also need to get your hands dirty by writing code: learn how to build a software rasterizer (check out Tiny renderer) and a ray tracer (Ray Tracing in One Weekend series). Preferably in a language like C++. Then move onto APIs. I recommend you learn OpenGL, but if you're okay with being confused as all hell try Vulkan. Or WebGPU if you're a hipster (/s).

Finally, try to build some stuff. A simple engine. A non-trivial technique. A game. Whatever.

Unfortunately, you're unlikely to get hired working as a rendering engineer without having serious connections, or by having adjacent experience in the industry. Doubly so now that everyone is convinced junior engineers are unnecessary.