WGL, pixel formats, and some changes
1,029
2
Advertisement
Today I took a look at the next few sections of the book. My goal for the day was to get the first full program working. The first program creates a window and then draws a triangle and rotates it. As usual I want to understand how everything I use works. I did have to suspend this to a certain point. The actual drawing code works off of theories and functions not covered yet.
I have no experience at all with 3D graphics programming so I did not understand a lot of camera stuff. However I did have linear algebra and numerical methods in college so I was able to keep up with the general idea of what was going on. I drew the triangle on graph paper by reading the coordinates to make sure it worked like I thought it did, and drew a few frames of the rotation. Also I was able to understand the OpenGL function calls at a functional level as far as type etc.
WGL
It turns out that OpenGL cannot handle window functions and interface issue on its own. These still need to be handled by Windows itself. Windows has a set of functions (prefixed wgl-) that handle coordinating OpenGL rendering with the device it is presented on.
This is done with a rendering context on the OpenGL side and a device context on the Windows side. The Windows GDI uses a device context to hold settings for drawing modes and commands. OpenGL has a rendering context for its settings and commands. The two contexts both have the same pixel format (more on this later).
The wgl functions allow all of this to happen.
So as you can see the device context is needed to make the rendering context. So what the heck is HGLRC?
Well we can make an educated guess that the H stands for handle again, based on the Hungarian Notation.
Searching Win32 help for device context gives us:
While this does not tell us what the GLRC type means exactly, I am going to go on the assumption that it is also a structure and therefore may contain several data types. So my guess is that HGLRC is probably a pointer to a structure that contains the information that OpenGL needs to interface with the device context. This would make sense with the definition for the rendering context.
The wglMakeCurrent() function will make your rendering context the current rendering context that OpenGL uses. You will need to pass it the rendering context and the device context. These nees to have the same pixel format. They do not have to be the rendering context matched with the device context used to create this. Obviously there is opportunity for error here. This function is a BOOL. It returns false if it fails. I was unable to determine if it fails by being passed a rendering context and a device context of different pixel formats.
wglDeleteContext() will delete your rendering context when you are done with it. It is also a BOOL. You need to make sure that it is not the rendering context set to current.
You should create the context and set it to current when the window is created, then reverse the process when the window is destroyed.
Pixel Formats
The book covers this pretty well. Basically the pixel format is a structure that contains all the parameters for the pixels drawn. You set this up and then pass it to ChoosePixelFormat() with your device context handle. However it is possible that your device may not support that exact format. This is whats cool. The function returns and int index that fits the closest available format. You then pass it to SetPixelFormat() to set it. This returns a BOOL for error checking.
As I said before the actual drawing part was not really covered and I will hold off on how all that works. However I didi have a few problems ggetting the program to run and I will address them now.
It turns out that the program calls an old auxiliary header for OpenGL called glaux.h that is no longer in use. It also calls some Windows functions that are no longer in the headers the book asks you to include (the book is a few years old at this point). However thanks to the MSDN it is easy to track down the unknown function names and add the needed libraries and includes. Here is what my include section looks like now:
and these are the libraries I have:
You will notice that libglaux.a was something I was able to find. However I could not locate the glaux.h header. There are a whole bunch of work arounds out there for this (you can search here on this page for some) however I was able to find all the functions I needed in other libraries so I went with that.
I am really enjoying this book and with a little bit of research the age difference doesn't really seem to hinder learning from it. In fact it makes it better because I have to think harder and research what all my functions actually are.
I have no experience at all with 3D graphics programming so I did not understand a lot of camera stuff. However I did have linear algebra and numerical methods in college so I was able to keep up with the general idea of what was going on. I drew the triangle on graph paper by reading the coordinates to make sure it worked like I thought it did, and drew a few frames of the rotation. Also I was able to understand the OpenGL function calls at a functional level as far as type etc.
WGL
It turns out that OpenGL cannot handle window functions and interface issue on its own. These still need to be handled by Windows itself. Windows has a set of functions (prefixed wgl-) that handle coordinating OpenGL rendering with the device it is presented on.
This is done with a rendering context on the OpenGL side and a device context on the Windows side. The Windows GDI uses a device context to hold settings for drawing modes and commands. OpenGL has a rendering context for its settings and commands. The two contexts both have the same pixel format (more on this later).
The wgl functions allow all of this to happen.
HGLRC wglCreateContext(HDC hDC);//This gets passed the handle for the device context and returns the handle for the rendering contextSo as you can see the device context is needed to make the rendering context. So what the heck is HGLRC?
Well we can make an educated guess that the H stands for handle again, based on the Hungarian Notation.
Searching Win32 help for device context gives us:
Quote:
A device context is a structure that defines a set of graphic objects and their associated attributes, and the graphic modes that affect output. The graphic objects include a pen for line drawing, a brush for painting and filling, a bitmap for copying or scrolling parts of the screen, a palette for defining the set of available colors, a region for clipping and other operations, and a path for painting and drawing operations.
While this does not tell us what the GLRC type means exactly, I am going to go on the assumption that it is also a structure and therefore may contain several data types. So my guess is that HGLRC is probably a pointer to a structure that contains the information that OpenGL needs to interface with the device context. This would make sense with the definition for the rendering context.
The wglMakeCurrent() function will make your rendering context the current rendering context that OpenGL uses. You will need to pass it the rendering context and the device context. These nees to have the same pixel format. They do not have to be the rendering context matched with the device context used to create this. Obviously there is opportunity for error here. This function is a BOOL. It returns false if it fails. I was unable to determine if it fails by being passed a rendering context and a device context of different pixel formats.
wglDeleteContext() will delete your rendering context when you are done with it. It is also a BOOL. You need to make sure that it is not the rendering context set to current.
You should create the context and set it to current when the window is created, then reverse the process when the window is destroyed.
Pixel Formats
The book covers this pretty well. Basically the pixel format is a structure that contains all the parameters for the pixels drawn. You set this up and then pass it to ChoosePixelFormat() with your device context handle. However it is possible that your device may not support that exact format. This is whats cool. The function returns and int index that fits the closest available format. You then pass it to SetPixelFormat() to set it. This returns a BOOL for error checking.
As I said before the actual drawing part was not really covered and I will hold off on how all that works. However I didi have a few problems ggetting the program to run and I will address them now.
It turns out that the program calls an old auxiliary header for OpenGL called glaux.h that is no longer in use. It also calls some Windows functions that are no longer in the headers the book asks you to include (the book is a few years old at this point). However thanks to the MSDN it is easy to track down the unknown function names and add the needed libraries and includes. Here is what my include section looks like now:
#define WIN32_LEAN_AND_MEAN //trim down the libraries#include //main windows headers#include #include //OpenGl include#include //OpenGL utilitiesand these are the libraries I have:
Quote:
lib/libuser32.a
lib/libgdi32.a
lib/libglaux.a
lib/libopengl32.a
lib/libglu32.a
You will notice that libglaux.a was something I was able to find. However I could not locate the glaux.h header. There are a whole bunch of work arounds out there for this (you can search here on this page for some) however I was able to find all the functions I needed in other libraries so I went with that.
I am really enjoying this book and with a little bit of research the age difference doesn't really seem to hinder learning from it. In fact it makes it better because I have to think harder and research what all my functions actually are.
Advertisement
Advertisement
Advertisement
Discussion