I've added camera support, so that the camera placement is loaded from the scene file as well. I support two kinds of cameras, perspective (which cause perspective distortions, e.g. parallel lines appear to converge) and orthographic (no distortion, used in architecture sketches to maintain proportion, etc.). Since cameras are treated differently from objects (they're not rendered, etc.) I can't store them in the same linked list, and thus I ended up having to copy and paste the functions and variables used to implement the factory method for the objects and replace all the occurrences of 'Object3D' with 'Camera3D' (the Camera3D class is still based on the Object3D class, but it itself serves as a base, for the PerspectiveCamera3D and OrthographicCamera3D objects). Obvviously this isn't the best way to go (and when I add lights, this would require another set of of linked lists and factory) so I'm thinking of using templates somehow to create a generic way of implementing the factory method. This ought to be fun, but I need some time to think about how this will work.

On a somewhat related note (i.e. also 3D related), a couple of days ago I found this cool OpenGL game (although it's more like a demo now, since you can't do that much except fly around) called glUFO. From the screenshots it looked really cool, except that it was for Windows. Fortunately, the source code was provided, and as it turned out the author used GLUT (Graphics Library Utility Toolkit) for the user-interface, so I figured I should try to port it. The first problem was that the author used GLUT 3.7 (a.k.a. GameGLUT, since it includes a bunch of functions for setting the resolution, etc. which are useful for games) which hasn't been ported yet to the Mac. Then I had to redo the key handling, since he'd used Windows specific code there (GLUT only supports one key down at a time, and provides no way to detect if a certain key has been released). This involved adding some #define's (my goal here was to modify the source code as little as possible, so most of the modifications were made in the header files) to map the KEY_DOWN macro to the appropriate function. Then I had to find all the key-codes, and #define their Mac counterparts. Finally, there were a bunch of compiler errors with the function calls, mostly that he'd define function a as 'void a(int)' and then called it with 'a();'. I guess Visual C++ is more forgiving than CodeWarrior, but fixing them didn't take that long.

Now the program finally compiled, but it would quit immediately. The fix for this was rather simple, I had forgotten to actually create a window to display the game in. The program then worked, except it was very slow. However, this was as expected, since I was using the software renderer. I added the fullscreen flag to the initialization options, so that the 3D accelerator would kick-in (the current drivers only support full-screen acceleration, although the hardware itself can do windowed rendering). To my dismay, nothing showed up on the screen. The main problem here is that since I was working in full-screen mode, it was very hard to debug. I obviously couldn't switch in to the Metrowerks debugger, but even MacsBug wouldn't display anything (the screen would go gray, but no text would show up on the screen). With a set of Debugger (which invokes the current debugger, whatever it may be) calls placed at various points throughout the code, and the use of the StdLog (which logs, among other things, the name of the current function) command typed blindly into MacsBug, I was able to determine that the code was indeed entering the main execution loop. After examining the code more carefully, I discovered a commented out call to glutPostRedisplay (which causes the display to be redrawn) in the idle function. After uncommenting this, and modifying the display function a bit, I finally got the app to show something on the screen. My theory is that when in software mode, the window was redrawn automatically the first time, but in full screen mode it wasn't, so I had to call it myself.

Although there was finally something on the screen, things still weren't quite right. The coulds, exhaust and bullets would show up as black rectangles, sign that there was something wrong with the transparency, and the mountains weren't textured at all. Fixing the transparency involved changing the destination alpha (the alpha channel being the transparency channel in an RGBA environment) from GL_DST_ALPHA to GL_ONE_MINUS_SRC_ALPHA. I guess the destination alpha was one value by default in software mode, and another when the 3D accelerator was enabled. The problem with the texture took me a while to figure out. As I was reading the release notes for the program, I saw something about Voodoo cards only being able to handle 256 x 256 textures (I already knew this) and that thus the 1024 x 1024 ground texture will appear rather blurry. I thought that perhaps the Mac driver, being still in development, doesn't do any scaling to make the textures fit, and rather simply rejetecs. I opened up the texture file in Photoshop (it was in a raw format) and scaled it down to 256 by 256. Finally, that worked too, and I was able to play around with the program as expected. If I can get it into a stable state (there's still some more issues with one other texture) I'll see about submitting the changes and the executable back to the author, so that he can provide a Mac version too.