Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it, follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.
Our rules have been updated and given their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!
Just for the mental exercise, I'm going to braindump the admittedly little I know about shaders. Delzhand will probably one-up me, but hopefully I'll make a worthy opening act.
With basically all modern graphics hardware, you as the programmer hand the graphics card a bunch of data that represents what you want it to draw. It's not always the same data, but typically you'll be giving it a set of vertices to produce polygons and a bitmap to draw on the polygon. A shader is another piece of data that the graphics card accepts, but it's actually code. In my experience, the shader runs once for every output pixel, but don't take that as gospel-- I'm sure there are some wacky optimization tricks done to make it super blazingly fast. But conceptually, a shader is a program that runs across each pixel and puts out a color value for that pixel.
Where shaders get interesting is that they have the ability to store their own variables locally. For instance, the amount of flash to apply to the object you're drawing. So, you can tell the graphics card "here, draw this sprite over here, using this as the shader code, and by the way, set the shader's flash value to .5". Or, if you want to get really fancy, you can provide a whole second bitmap to inform the change in picture color. The technique called "bump mapping" uses one bitmap to provide color (what you'd normally think of as the polygon's "texture"), and then a second bitmap to represent the normal to the surface at the corresponding position. This helps create the sort of fine-grained bumpiness inherent to things like bricks without using nine thousand times the polygons.
As programs, shaders are written in a dedicated programming language such as HLSL or GLSL. These are fairly well-known specifications, and pretty much any graphics hardware should be able to run a shader in one of the more standard languages.
So, to recap: on any given render: give graphics card your shader -> give graphics card vertex and texture info -> set shader variables -> pixel color in -> your shader function here -> pixel color out.
I enthusiastically joined the project early, wanting to get in on the whole indie development thing, and then immediately had second thoughts and wound up feeling like a total jackass for committing to something with basically no capacity to back it up. I feel gently vindicated that LaCabra has gone on to get a game on Steam while I've still basically got nothing presentable. So! Looking forward to seeing how it came out, LaCabra.