
The Shader card
Make something that looks (or sounds) nice! You can use ShaderToy for image shaders, or even ship a Minecraft shader-pack. Audio visualizers are also welcome!
Make an image or audio shader: a program that runs per pixel or per sample and computes what you see or hear, rather than drawing it from assets.
What a shader actually is
A shader is a small program the GPU runs once for every pixel, in parallel. It gets told which pixel it is and what time it is, and it returns a colour. That is the whole interface.
Everything follows from that. There are no shapes, no sprites and no draw calls: if you want a circle, you write the function that says “this pixel is inside a circle” and return one colour or the other. It is a genuinely different way to think about graphics, which is why it is worth a card.
The language is usually GLSL, which looks like C with vectors bolted on. You can be writing your first one in about ten minutes.
Start on Shadertoy
Shadertoy is the obvious starting point and the obvious place to ship to. You write GLSL in the browser, it compiles as you type, and the result is a URL anyone can open, which makes a demo link trivial.
Read other people’s entries. Almost everything in shader programming is a known trick, and Shadertoy is where they all live.
Where to learn:
- The Book of Shaders (thebookofshaders.com), the standard introduction. Work through it in order.
- Inigo Quilez’s articles (iquilezles.org), the reference for signed distance functions and raymarching. Dense, and worth it.
- Shadertoy’s own entries, read as source.
The two ideas that unlock most of it are signed distance functions (a function that returns how far this point is from a shape, which lets you combine shapes with arithmetic) and raymarching (stepping along a ray using those distances, which is how you get 3D out of a per-pixel function).
Minecraft shader packs
Writing a shader pack for Minecraft counts, and it is a good route if you want your work to land somewhere you already spend time. You are writing GLSL against a real renderer with real constraints rather than a blank canvas, which is harder in an instructive way.
Hack Club has a guide for exactly this: Lumen’s getting oriented.
Audio shaders
By audio shader we mean sound computed by code, with no recorded samples: a function of time that returns an amplitude.
- Bytebeat, where a single short expression on a time variable produces surprisingly musical noise. One line of C, genuinely.
- A track generated entirely in code: synthesis, sequencing and mixing, written out to a wav or played live.
- Shadertoy has a sound tab that does this natively, so you can ship an audio shader the same way as a visual one.
- A softsynth you play with the keyboard.
“A cool sound made by code” is the bar. It does not have to be a song.
Other things that count
- Visualisers. Audio in, geometry out. Well suited to this card because the shader reacts to something instead of looping.
- Post-processing effects: CRT emulation, bloom, chromatic aberration, edge detection, film grain.
- Generative and procedural images: noise, fractals, plasma, flow fields, reaction-diffusion.
- A demoscene intro, which combines most of the above and pairs nicely with the Lightweight card.
Shipping one
- Demo: a Shadertoy link is ideal. Otherwise host it as a page, or for a Minecraft pack, a video of it running plus the pack itself.
- Screenshot: a still frame. Easy for this card, and pick a good one.
- Repository: the source, plus a README saying what the effect is and how it works. “How it works” is the interesting part of a shader project and reviewers read it.
- Let people tweak something if you can. A parameter, a mouse interaction, a slider. Shaders are much more convincing when they respond.
A warning about hours
Shader work is easy to underestimate and easy to overestimate. Staring at a black screen because of one wrong sign is real debugging time and it counts. Leaving a tab open while you do something else does not. Hackatime is tracking your editor either way, so be honest about what was work.
