One other bit of advice - a lot of the tutorials out there start with matrix math and eventually get around to drawing a triangle.
I recommend reversing that - ignore the math and just get a triangle on screen using a trivial shader (takes a few dozen lines of code in WebGL), then learn about how shaders and matrices work by applying them to your triangle.
Absolutely this. I did it the other way because I didn't know better, and it was remarkably boring for the first several days of trying to decipher tutorials. It would've been much more fun if I had just thrown a triangle on the screen and started playing around.
What about 2D graphics? Sprites? Old school stuff? I keep meaning to fire up DOSBox-X and go through some old tutorials. I really just want to put pixels on the screen and work my way up from there - everything else just seems to get in the way.
I know some would say it's a bad language, but back in the day it was incredibly accessible and spawned a lot of shared code and tutorials. If you focus on the techniques and algorithms, treat the language as pseudocode rather than "the right way to do things", you can have a lot of fun and learn quickly things you can translate to whatever your language of choice is.
I think most of those will work on QB64, too. So you could end up end with fast, native executable files on Windows, MacOS, and Linux. That doesn't matter much for those tutorials, but QB64 might be ever so slightly quicker to get up and running than DosBox + QBasic.
Javascript + HTML5 Canvas is an easy start, and if you want to do even older-skool stuff you can treat the canvas as just a block of pixels and write your own 2D renderer on top of it.
Processing is amazing (and what I switched to after I started hitting Flash performance limitations). They have great documentation and tutorials on their website too, and I felt it's little IDE made it really easy for beginners to get started with it.
> I really just want to put pixels on the screen and work my way up from there
That really isn't how modern, accelerated graphics works - even 2D accelerated graphics! "Sprites" are slightly closer to the mark, but it goes far beyond that.
The entire framebuffer can be thought of as a huge sprite. Modern RAMDACs can scan multiple overlapping arbitrarily sized framebuffers (layers) simultaneously, while doing bilinear filtering, merging alpha, colorspace conversion, rotation, LUT, etc.
All that happens on the fly without intermediary frame buffer composition in between. The output goes directly to the display (over HDMI, eDP/displayport, DVI, etc.).
Yeah, and of course mouse cursor is a sprite in the traditional sense. Although on modern HW you could implement mouse cursor as a hardware layer.
You can do it with SDL or even just Canvas and JS. Later on you'll converge onto "3d as 2d" as you try to optimize and leverage shaders for high performance effects like color grading, blur, glow, etc.
I've been dabbling with 2D graphics recently and found PyGame to be well suited for experimentation. You'll need to hold your nose a bit (API is a bit clunky in places and far from Pythonic) but it's relatively trivial to get some pixels on screen.
Agreed. With SDL you can get a loop that copies a 2D array of pixels from main mem to the screen every frame about as fast as possible in a single page of code. If you want to explore software rendering, that's the way to go.
in my gameswithgo.org video series, when we start on graphics, that is how I do it. we implement putpixel, and do some basic 2d rendering by hand. bilinear filtering, alpha blending, etc.
IMO Shadertoy is not a good place to start. The techniques shown on shadertoy are fun to play with but they have almost nothing to do with the techniques used to make shipping products. Drawing an entire forest in a single shader is amazing but it runs at 0.2fps on a machine that can run GTA5 at 30-60fps
I would agree - Shadertoy is really cool, but it fits into the category of "they did it because they could, not because they should." There are techniques used in Shadertoys that are relevant elsewhere, though the learning curve is really steep in terms of comprehending what most Shadertoys are doing.
That really depends. If you know graphics concepts, but need to actually learn an API, there is nothing wrong with starting with Vulkan. It's a lot to figure out to make something practical with it, but it's expected.
I'd say, a good way to do it, is first learn theory, and apply it using simple tools that let you just draw on screen (like SDL). Then learn a GPU targeted API.
I second this heavily. I've implemented a 3d scene renderer for 3D CAM software in the past and have been wanting to get back into some 3D things to practice math as I've been feeling a bit behind where I used to be.
I spent a while getting an OpenGL environment setup in VisualStudio and got frustrated with the tooling as I've also been spending much of the last 3 years doing trivial web development. I ran across shadertoy and was able to whip up much of the core of the pathtracer there and very easily move it over to it's own project supper easily utilising REGL (https://github.com/regl-project/regl) in ~100 lines that included a camera, dynamic shader compilation based on a scene, etc...
No other tooling needed until you've got the basics of vertex buffers and shaders down.
(20 year graphics veteran here who's boostrapped some coworkers)