If you’ve seen my last post, you’re aware that I’ve been playing with OpenGL and GLUT for a uni subject. As I like to straddle the OS fence and use a mixture of Windows Vista x64, Windows XP and Mac OS X 10.5, I like to have platform independent solutions to problems. The latest little issue I’ve come across regarding GLUT apps is that GLUT on the Mac has a different include. To include GLUT in a project for the mac, you must use the following:
In order to cut code that will compile successfully on either platform we can use optional includes with the
#endif preprocessor directives. Props to “kainjow” for providing this information in his/her forum post. Here’s how:
All this does is say “if we’re running on an Apple machine,
include GLUT/glut.h, otherwise
include GL/glut.h. Now to actually learn OpenGL/GLUT…
I’ve recently had to install freeglut as part of a uni subject and ran across an issue due to the fact that I’m running Vista x64 and wanted to dynamically link freeglut against anything I develop during the semester. First of all, building freeglut (version 2.4.0) was problem free. I simply opened
freeglut.dsw (in the root directory of the freeglut download) in Visual Studio 2005 (VS2005), agreed to convert the project files to a newer format, and then built the solution. An additional step I took, which may be completely unnecessary, was to change the build type from Debug to Release. Both build types built fine, but I used the release versions as I doubt I will be debugging freeglut. Also note that I compiled this as the default 32-bit, not 64-bit, as I’m building 32-bit GLUT apps for compatibility.
Once this was done, I followed the info in
README.win32 (in the freeglut directory) and copied the files to the relevant directories. The specific directories I used for a Vista x64 system with VS2005 were as follows:
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK\Include\gl.
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK\Lib. Note that the correct destination should already contain
- Now here’s the part that caused me problems: copy
C:\Windows\SysWOW64 and NOT
C:\Windows\System32 as you might expect, given that it’s a 32-bit library being used in 32-bit projects
Once the files are in place, you should be ready to use freeglut in your apps. To do so, simply include freeglut as follows:
As you can see, we’re referencing
glut.h and not
freeglut.h. My guess is that this is done to maintain platform independence if your code was being built by a different incarnation of GLUT. For example I used this method to build and run the test app provided by my lecturer (unchanged), who uses the original GLUT.
***UPDATE 2009-02-27 ***
I copied the files I built on my Vista x64 machine to a 32-bit install of XP SP3 on my laptop and GLUT worked fine. The only difference to the above instructions (obviously aside from not building freeglut again) is to copy
C:\Windows\System32. I’ve also put together a zip package of my build for anybody who wants to avoid building themselves.
I’m currently planning on a career in games programming and was looking for some beginners’ tutorials in OpenGL using C++ and found a goodun over at code project. It’s a 3 part tutorial, and as I’m writing this the first two parts have been posted, complete with code and Visual Studio project files. As a relative beginner with C++ and a complete beginner with OpenGL I’ve found this fairly easy to follow. The code is pretty well commented, and the tutorial itself explains things clearly and doesn’t take too much for granted aside from a basic knowledge of programming/C++.
A trap for young players, there was a slight error in the code from the first part that caused the program to not shut down and stay in memory after the window had closed. Nobody else seemed to have this problem, and it could have just been me being difficult and using Vista. Nonetheless, if the code for part 1 hasn’t been updated, the fix is in the comments below part 1. Basically the main application loop did not clear the message queue with each iteration, only taking the first message. From what I’ve read on the issue this means that the WM_QUIT message sent from PostQuitMessage() is never received. This is because PostQuitMessage(0) sets a flag on the message queue which tells it to return a WM_QUIT message if the queue is empty. Obviously if the queue is never cleared, this message is never returned when the queue is queried for the next message.
If you have any problems with this, feel free to contact me. Happy coding!