GDW Progress 3 (Bah...)

Hello world.

Yes, that's it. Fascinating, huh? I know you may be thinking that I am now in a hopeless position since I still don't have a game, it's due in merely three weeks, and all I can draw right now is a teapot - a teapot that can easily be rendered thanks the GLUT library's already created function. Well guess what, I've programmed a lot more than what you see. I have completed a Light Manager class. What does that mean? It means that I can easily create a light and apply it to any object with very few lines of code.

(Just a heads up readers; if you're not a programmer (as for those who don't know, I send my blog links to my friends on facebook), you may have trouble with understanding what I describe below, and ultimately bail on the article. I apologize for this, and I'll try to make my explanations simpler next time, sorry... :S )

Naturally, the OpenGL system provides eight lights, and are tedious to apply in dynamic scenarios. So what I did was create a class that holds a whole bunch of variables that can be applied to any of the eight OpenGL lights. Such variables include colour, position, direction, attenuation, etc. and they are contained within (what you can imagine as) case-holders. Such case-holders (which are managed by the light manager) are essentially  "light-shells". Those "lights-shells" can be applied to an OpenGL light on the fly, transferring the shell's qualities (colour, position, etc.) to the actual OpenGL light. Once the OpenGL light gains the appropriate parameters, it can then be applied to an object. Up to eight lights can be applied to a single batch of objects. Once the lights are applied to the object, the programmer will then have to call a function called "release", which clears out all the OpenGL lights, and readies them for the next application. The Light Manager also chooses which OpenGL light to apply a given light-shell to (0-7). If all eight lights are used up, then the manager will refuse to add any more light.

So in other words, we can save many many light-shells as a positional light (like a light-bulb), directional light (like the sunlight), or a spotlight. Let's say we want a directional light-shell that contains a dark green ambient light, lime green diffuse light, and bright green specular light. We pull that light (which is labeled by an enum ID number), and apply it to an OpenGL light. If OpenGL Light0 is already being used, light manager checks if Light1 is being used. If it isn't, the light-shell that we pulled out will then be applied to Light1. Once all OpenGL lights have gained the required light parameters, it can finally be applied to an object(s). Once they have been applied, the programmer must refresh all OpenGL lights with the "release" function, and ready it for the next object(s).

Additionally, the lights are also able to move... somewhat. Let's say you have a car object, and you want it to have headlights. Easy, all you have to do is apply a spotlight, and as the car moves, update the position of the light by using the "setPosition" function. Simply input the position of the car plus an appropriate offset, and you've got the new position of the headlight. Now let's say the player restarts the game. Simple, use the function called "reset", and it resets specified light-shell's parameters back to the original parameters it had when it was first initialized (such initialization occurs at game start-up). But wait, what if the player wants to switch off his/her headlight? No hassle, just use the "SwitchLight" function; if it's on, it will turn off, and vice-versia. There are also other functions, including one that allows the programmer to switch the light on, whether it was previously off or not, and vice-versia.

Unfortunately, the light manager isn't entirely complete, as I want to implement a "material manager" within it. Every object has material parameters that are applied before it can be drawn on screen. I want to eliminate such a tedious process with an appropriate materials manager. Rather than create this manager as a separate entity, I'd rather implement it within the light manager class, so that any programmer will instantly know that it's solely related to the OpenGL light. Materials will also have material-shells, and can be called using the enum ID system.

Minus the intended material manager, my light manager alone currently takes up 1,770 lines of code. Yes I worked very hard on this, it was a long-process, but the end result was very worth it. Once the materials manager is complete, my next goal is to perfect the sound manager, and input devices (keyboard, mouse). After that, I will begin to integrate Matricies, Quaternions, sprite holders, OBJ loaders, camera system, and test the texture manager. Those are just a few of the many things I have left to program, however I hope those features each don't need to take up as much code as my light manager did. Once everything I need to do is complete, my engine will be asset ready, high-level (easy to use for my other group members), and game production will increase exponentially. I hope to reach this point by Tuesday the latest. Thanks for reading! :D