You will hardly find a website that tells you "how to make shaders". Rather you will find examples, sometimes with source code.

I have submitted one to NeHe Productions a while ago. It used a vertex program for the cel-shading tutorial. I think you still can find it in the downloads sections under the letter C at nehe.gamedev.net.

Since some of you seem to be interested in shaders, I think I'll submit another demo I've done around cel-shading, but this time with both vertex and fragment programs, and even vertex buffer objects. </off topic>

[edited by - vincoof on June 24, 2003 2:43:58 PM]

So, if I got that right: A Vertex Shader program is executed after every call to glVertex and it modifies the vertex''s properties like color and stuff. But what about Pixel Shaders? Do they go for every pixel you rendered and modifies the pixel''s properties, or what? There can be pretty much pixels on high resolutions - wouldn''t that be pretty slooooow (By the way, can I change a pixel''s color by using a pixel shader? For example to write a night vision for a game, so that my pixel shader turns everything into green or something?)

And what''s that thing with per-pixel lighting and per-vertex lighting? Is that done by shader programs or something completly different - any extension?

danielk : the program you wrote can be ported to an ARB program pretty easily. ARB vertex and fragment programs do have a syntax somewhat similar to vertex and pixel shaders.
About the "language of my example", it is an ARB fragment program, which can be guessed by the starting line "!!ARBfp1.0".

ZMaster : a vertex program does not really modify it rather bypasses certain computations that otherwise would be performed using a static scheme (known as the fixed function pipeline). Vertex programs do bypass the vertex processing part of the pipeline. This is responsible of transforming vertex coordinates from object-space to clip-space, this is also responsible of computing lighting, generating texture coordinate (when TEXTURE_GEN_S is enabled for instance), it also computes fog coordinate, and some other things like that. All of those computations being done per vertex.
Then, when three vertices are defined (in the case of rendering triangles) the rasterization takes place : the renderer scans lines that fill the triangle on screen, and for every pixel to fill, the fragment processing is performed. If you have defined a fragment program, this program is executed, otherwise the standard fragment processing in OpenGL is : texturing stage, then color sum stage, then fog stage (each stage can be ignored if disabled obviously). Fragment programs can be very slow for numerous computations on high resolutions, but executed in hardware it is done pretty fast. Unfortunately, when performed in software fragment programs are really too slow. On the other hand, vertex programs can be executed in software with very good performance. That''s why nVidia proposes a software implementation of the ARB_vertex_program extension for all GeForce that do no support vertex program in hardware : it''s still a bit slower than what it would be if executed in hardware, but that''s affordable. They also did the same for ARB_fragment_program but they only left that as an option (for testing purposes mainly) because the performance hit is unbearable.

Per-pixel lighting is done by the ARB_fragment_program associated to the ARB_vertex_program extension. But keep in mind that generally only one light is treated at a time. That is, for multiple lights, per-pixel lighting needs multi-pass (unless very special cases as usual).