A few notes about GameLib

Well, the time to post GameLib is getting closer. I've been keeping a little SVN database on my local machine to keep track of it. Once commit #7 (this is after a years worth of coding) is done, the system will have a very mature implementation for matrices (now it's quite basic), and have it's own entry-point (the current one is platform-dependant).

What does GameLib look like in code? It's OOP design was partly inspired with DirectX compatibility in mind (that I wouldn't have to do too many hacks to port it). Well, let's say it has the following interfaces/objects (and more):

• Object - handles reference counting/allocation tree


• IString - handles static strings


• I3D_Device - access to state of currently-rendering-to 3D device. Also allows creation of sub-objects from device.


• ILight - A light, allocated from the device


• ITexture - A texture,


• IGPUDataPool - Use this to prevent loading the same image twice into memory (retains pooled objects with weak references)


• IVertexBuffer - Used for holding everything that is needed to describe a mesh


• IInputDevice - Used for getting input from a game-pad, etc.


• IState - Used with the finite-state machine (game is loaded up in a state).

I'm still wondering about initialization; but will code it as follows (since booting up the system is getting more complex every day). Right now, I'm debating whether having a struct be filled, or having an object that can be queried and can return errors.

Also, the exceptions are used only in cases of extreme failure, and should not be used to manage program state (once the library gets out).

And for the license, do I have to pre-pend it to the start of each file? If so, then that'll take a bit more time before the first upload.

All this, to say that it exists, I've spent a year or so on it, but I just haven't gotten to uploading it yet.