Original Post
Here is my text-additions I have mentioned in previous posts and on IRC: "How does it all work?" you probably think. As mentioned in the intro-lesson you basicly tell OpenGL what things you want rendered (rendered = image drawn) and it then does it for you. However, before we start talking about the actual rendering we have to explain some things (don't worry, it won't take long). First lets talk about which systems are involved in OpenGL-rendering. There are several subsystems that act as middle-hands. You won't need to bother much with them, but you need to know what they are and where they fit in. Take a look at this figure: Graphics-card <-> Driver <-> OS & Window-layer <-> Application Graphics-card: the hardware in the computer that does the actual rendering. Driver: the driver for the graphics-card that takes care of all the card-specific things (see lesson-intro for more info on what a driver is). OS: the operating system your application runs on. Windows, Mac, Linux, *BSD et.c. . Most of the time you will need to deal with the issues of each OS you code for (read on for more info). Window-layer: There are essentially two main parts of OpenGL. One that takes care of the "real" work (meaning you tell this part what colour you want, where you want your 3D-objects to be placed et.c.). This part is OS-independant and is basicly called OpenGL. Then there is the second-part: the window-layer. While the actualy OpenGL-calls are OS-independant (meaning they will work on every OS without having to write specialized code for each of them), the creation and handling of windows are OS-specific. Windows has its own APIs to deal with window-management, Linux and *BSD has theirs, Mac has its et.c. On windows you have whats called wGL, Linux and *BSD uses GLX and has aGL. If you look at the old Nehe-tutorials they are written using wGL (and then later ported to other system). "This sounds troublesome" you might think, and it is. If you want your software to work on more then one platform you need to deal with all the window-systems. However, there are ways around this problem. Remember that we talked about how in the old days you needed to deal with the specifics of each hardware and that this was solved by creating abstract APIs? Well, you can do the same with the various window-systems. You create a common API and then use "drivers" to deal with the OS-specific issues. "Do I have to write such a system?" No you don't [smile]. There already are finished ones that you can simply use. A handfull of years there was a system called GLUT (stands for Graphics Library Utility Toolkit) that was common. Nowadays another one called SDL (Simple Direct-media Layer) is the most common. Fact is, the new Nehe-code is such a system! You only need to learn how to use the interface-code and then just select a backend (backend = driver) we wrote for the appropriate OS. That way your code will work on all platforms we have backends for! So you get this: Graphics-card <-> Driver <-> OS & Window-layer <-> Nehe Introcode <-> Application We also have an SDL-backend (which is the preferd backend) so you get this: Graphics-card <-> Driver <-> OS & Window-layer <-> SDL <-> Nehe Introcode <-> Application "You then get two abstraction layers, isn't that a bit of a waste? Why didnt you just use SDL?". Both yes and no. When we started updating Nehe we considered the possibilty of just binding all our code to SDL. Then our system would have been much simpler. However, we choose not to as we didn't want to be locked into one system. Also, making the system we now have made gave us the opportonity to teach new programmers what an API really is (as NeheIntro is a very simple API but at the same time shows the fundamentals) and one of your goals with the new Nehe was to teach good and important programming-practices. Of course, there is always a choice to be made on this. You either take the fast and simple but not very agile approach (which, in our case, was to just use SDL) or the more complex one that takes more time to write but is more powerfull and agile (writing our own abstractation-system, which we choose to do). Some development-studios prefer the first approach, others the second. There is no definate answer, you have to judge it case by case and the skill of good judgement comes with experience. If you are a beginner then our advise is to first take the simple approach, in this case just use SDL or NeheIntro (so that you faster get a finished application), then the second time make your own abstractation-system as it teachers you a lot (just be prepared that its going to require more time), then after that we would recommend to generally use the first approach, as its the final product that counts. Who cares if you made a uber-powerfull abstractation-system? There already are a dozen of them and what people are interested is the final program you deliver (whetever its a game or another form of application). Modern graphics use whats called "Raster-graphics". There is also whats called "Voxels" and "Raytracing" but we will mainly use Raster as its the industry-standard and what most GFX-cards are built for. Raster-graphics are built upon whats called a polygon. A polygon is basicly a geometric-shape, for example a cube, a pyramid, a sphere et.c. Polygons consist mainly of 3 things: vertices, lines and faces. Lets take a look at a simple 2D-polygon: a triangle. Each corner of the triangle has a vertex, so the triangle has 3 vertices. Their locations are: However, if we only use the vertices we only get 3 dots, so we need something more. If we draw lines between these vertices we get a wireframe-triangle. We don't directly create lines, we simply place the vertices and OpenGL creates lines between the vertices automatically. Now we have a triangle, but there is nothing in it! This is called a wireframe. Now if we fill the inside of the triangle with, lets say a colour, we get this:
