A helicopter simulator (no link yet)
As I'm currently reworking my web warren into something more, well, presentable, I don't quite have a page for this gem yet. That'll be rectified when (if?) I find some free time. The rotors on the sim spin based on the amount of throttle applied, and application works with joystick input (throttle on the "Z" axis of a joystick, buttons 1 and 2 control collective, and 3 and 4 control throttle - I think) and is challenging to control - just like a real helicopter!
As I mentioned earlier, this was an extension to the earlier code for Adventures in Evil Stick Land, but the code itself ended up being... unclean. The project was written in under three weeks on top of another class and a full-time job (much like all of the code I write), so I wasn't so much designing a solution as I was flailing about wildly in visual studio hoping that I can get it working well enough that it doesn't break during the demo. The result, as you can imagine, was somewhere between a well-documented application framework and spaghetti with garlic bread, but it worked.
After I finished that course I had to do some cleanup and improving before I could even think of showing it to someone else (see the color scheme above? I hadn't yet figured out 3ds materials - that changed right quickly). So I made some improvements to the code base and did a hell of a lot of commenting. The drawing code itself was fairly compartmentalized, and didn't need to be touched too much (until the need to load a model with multiple components arose), so at the very least I had that going for me.
I know, I'm digressing a bit from the original topic of this post, which was... well... to be honest I didn't really have one. I want to venture a bit now into some design aspects of the application framework I am working with. I'll be using the day-night application mentioned below as my testbed app for the time being, to be improved as I find the need. The development of that resulted in a fairly messy program architecture.
I spent two years or so as a .NET architect, so I tend to resort to diagrams to get across my points. However, I'm out of practice - my diagrams may not follow any standards, nor are they academically... accurate, so to speak. Not to mention that Visio 2003's use of UML is atrocious - Why do I need to create a BS project to make a class diagram when all I want is to indicate a composite relationship? In any case, if my diagrams aren't clear, feel free to ask for clarification! Alternatively, feel free to offer corrections.
The end result of that coding effort is the architecture below:
New (and improved?) version
This is, to put it simply, bad. I'm being generous by calling my mishmash of code hidden in main.cpp an implied application class, and I'm also being generous in calling my std::vector of graphics objects an implied scene. I've left out auxiliary classes - the material library and the 3ds loader, among others - but I was only trying to get my idea across: the architecture needs some serious rework.
I've done some work in the meantime on adding a scene graph (very basic, more or less a tree of graphics objects), and defining an application base class, with a child derived for GLUT displays. I've also done away with display lists, as they are... extremely touchy. Not to mention that even the simplest of abstractions caused the display lists to stop working properly, as well as the textures (I'm still tracking this down). I took out the movement code, pending abstraction into a camera and player class, so the scene itself is pretty boring. In any case, here's the "improvement" in all of its glory:
New (and improved?) version
More to come as I work on the project, but for now I need me some sleep. I'll try to post an inital shot at my new architecture tomorrow - I have something in mind, but it has yet to be put on paper.