Hey im fairly new to programming in general. I understand most of C. I understand how the whole language works as you write code, and then you compile it to make it into machine code, but I dont understand how the hardware can interperet the 0''s and 1''s and make images on the monitor. Put it another way...how would the directx and opengl libraries communicate to the video hardware? Im sorry if this question is a little to general or nubish, but I cant really find the answer in any of my many programming books. Id apreciate a response...thanks alot. GG gamedev.net!

This is a rough approximation of how it probably really works. I don''t know all the exact nitty gritty details but this should give you an idea. It might also help you understand how in general software and hardware communicate.

There''s a software layer in between OpenGL/DirectX and the video hardware - the driver. It takes general graphics commands from OpenGL/DirectX like "draw the vertex at coordinates (x,y,z)" and turns them into low level commands that the specific video hardware understands (since there are many different video card manufacturers who all design their cards differently).

So what are the commands that those cards unerstand? That''s determined by the hardware manufacturer. How do they get sent to the card? It''s usually done by something called memory mapped I/O. That''s where the computer is designed so that specific areas of memory are reserved for hardware to receive input (eg video cards) or give output (eg mouse).

For example, maybe a video card is configured by the operating system to receive commands at some reserved memory address. The card has also been designed by the manufacturer to interpret the bytes at that memory address as follows:

0x00 - clear the screen, start a new frame
0x01 - specify vertex location, next 3 floats in memory are its coordinates
0x02 - specify vertex normal, next 3 floats are the (x,y,z) components
0x04 - specify vertex colour, next 3 floats are (r,g,b)
0x08 - specify vertex texture coordinates, next two floats are (u,v)
0x10 - specify camera view matrix, next 16 floats are the 4x4 transformation matrix
0x20 - specify projection matrix, next 12 floats are the 4x3 transformation matrix
0x40 - done drawing the frame, refresh the screen

The video card driver then translates a sequence of commands like:

glBegin(GL_TRIANGLES);
glNormal3f(1,0,0);
glVertex3f(0,0,0);
glVertex3f(0,5,0);
glVertex3f(1,-5,-1);
glEnd();

into the appropriate sequence of binary commands that the card understands, and places them one a at a time in that memory mapped area. Periodically the data there is transmitted to the actual video hardware. No magic, just electrical signals travelling along wires.

Once those commands/data get to the video hardware they go through the transformation pipeline. This is basically a bunch of circuitry that does mathematical transformations, such as interpolation and matrix multiplication. Basic rendering usually involves the card taking the data associated with a 3d triangle - 3 vertex positions, 3 vertex normals, 3 colours or texture coordinates, a transformation matrix and projection matrix, and transforming this 3d information into a 2d image. That 2d image is written to a big memory array on the video card called the frame buffer, which is basically a 2d array of pixels. The dimensions of the frame buffer are your screen resolution, eg 800x600 pixels.

This whole process is repeated for every triangle you draw until eventually your frame buffer has a nice quake 3 level that has accumulated on it triangle by triangle.

The whole time this is going on your monitor is refreshing, which it does about 60-70 times a second. Each time it refreshes it sends a signal to the video asking for the contents of the frame buffer. Whatever is in the frame buffer at that point is transmitted along your monitor cable and displayed on the screen.

I''ve skipped over some key things like the z-buffer to keep it relatively simple.