Hello everyone, I'll do a quick outline of what I'm using first. Microsoft Visual C++ Express Edition 2005. Mainly programming for Win32, though I plan to eventually port to Linux. I'm using OpenGL for graphics. I'd like a few suggestions on my engine design. It's not strictly a game engine, more like a graphics engine (That can be used for games, obviously). The whole engine is based on a hierarchal design (see example below). This makes it easy to program new parts to the Engine, as well as update the old. However, it also means there's very large include-trees (I think #including one .h file causes 10 other custom ones to be included at one point, which in turn includes even more standard .h files). I'll provide my texture management system as an example (though other parts are based on the same design, ie: geometry, sound, physics, network, etc). I have two low-level classes. One class is the 'buffer', which manages holding image data in system memory, as well as loading files from the hard drive. The other class is the 'Texture' class, which manages the OpenGL texture ID, and copying the data from system memory to the GPU. On the next level I have a class called 'hTexture', which requires both the 'Texture' and the 'Buffer' class to operate. It manages swapping the texture from the GPU/RAM/HD as needed. On the same level is the hGLSL class which manages GLSL shaders. Then, on the next higher level I have the 'Material' class, which, as it sounds, handles opengl materials. It combines multiple 'hTexture' classes for multitexturing, handles properties (glEnable), and requires the hTexture and hGLSL classes. I've spent 1.5 years programming the Engine, so redesign is not an option, however, I'd like any tips and comments about the above design. Is it good? Is there anything I should watch out for? Any interfaces I should provide to the end-user to make it easier to access? In theory, the end-user should only have to access the 'Material' class to make it all work. On a completely different note, my engine requires a WindowContext to be created to display the window, and create an OpenGL context. Some variables in it need to be shared with other classes, however, there may not be any opportunity to pass the WindowContext to the class as a pointer. Currently, my solution to this is to create a global pointer with the current active WindowContext class. However, to have multiple contexts requires switching between each context on a single thread. A more efficient solution would be to have multiple threads, each with its own WindowContext class. However, this makes a single global pointer to the current class unreasonable (as there could be multiple current classes at the same time). I've been reading about TLS (Thread local storage, via __declspec(thread) ). Is this a plausible method? Is there a better way than having a thread-specific global pointer? Thanks for reading my essay I'll appreciate any feedback you may have, ~Zix

A few comments:

1 - Why, oh why hTexture? Hungarian notation needs to die an evil death (Only thing I can think of for the hTexture thing). Intellisense rules!

2 - I prefer to keep things simple at the lower levels. You said you have a buffer that loads the texture and holds it in system memory. I went a different route. Putting my loaders (game can use/make custom ones and register them) into their own area and they pass back a buffer which my texture class holds. That in turn is referenced by the material class as one of it's "skins" (bumpmap, specmap, etc). I figured a texture shouldn't load itself, it should just manage itself. But I've seen it done both ways.

3 - You should really abstract out all the OS stuff now, otherwise porting will be a nightmare. It's never too late technically, but mentally it's a chore to do later.

As for your "bonus" question :)

Our engine handles windows creation itself, holding and passing the window handle around as an ID to the other parts of the engine that need it. I use an internal messaging system to do some of this passing later if its needed. Technically the engine currently can create multiple windows but it doesn't allow to multiple message loops. I don't need it right now but it is on the "if you have time and are really bored" feature list :)

Thanks for the suggestions. In general, I've moved away from the hTexture notation style things. That class happens to be over a year old, and some of my programming styles have changed since then.

I also can't imagine porting being too hard. I only have to modify the WindowContext class, the sound initialization (FMOD is cross-platform), and the socket management. All of the libraries I use are cross platform, so it shouldn't be very difficult.

I might implement the internal message system idea, though.

Thanks for the suggestions,
If anyone else has any, they're still welcome
~zix

We all progress. You can do find/replace all if you want to change it. We've done that once in our engine when we changed from m_ to just m (what a waste of a key _ is)