Currently I have these parts:
1. assert/debug lib: This lib contains an enhanced assert which is not only able to skip asserts for N times but which also can send an error report by email to the developer who has provided his email address.
2. baselib: which contains some stuff as different containers (string, dynamic arrays etc), the memory manager, the system stuff (such as the file system, streams and the plug in management), seeded random generators, etc.
3. config: contains reading of xml based data stuff (this can be an config file, but also any other data based on xml).
4. utils: which contains thread code, timer stuff and xml based parameter reading.
5. math: a math lib basically thrown together from various math sources, mostly the Eberly math stuff. Contains everything from color convertion to ray casting and collision detection.
6. input: Takes care of mouse, keyboard and joystick/pad input. Handles function to event binding (ie. the e key calls a function which opens the editor; the kind of keyboard mapping you find in games ;)). Those events contain also axis stuff like mouse up, mouse down, mouse wheel etc.
7. GFX File Formats: Basically I had a whole bunch of different plugins that were able to load different file formats. I switched to FreeImage and wrote a gfx plugin that was able to work with it. I still have to write a DDS file loader since FreeImage doesn't handle mipmaps.
8. Renderkernel: This is a DirectX based render kernel implementation which can do shaders (up to the latest version) and all things a neat renderer should be able to do.
9. CoreEngine: This is called core engine but in reality, this contains stuff like the scenegraph handling, the nodes (geometry, camera, lights, etc) but also the gui stuff (which contains everything from simple text output to buttons (check, radio, push) and input (editfields, editlines). The core engine also contains a complete animation engine, some physics stuff, a terrain engine, etc).
10. Scripting: I also have a lua 4.0 based scripting engine which is quite complicated to use.
11. Game Framework: The game framework is some kind of wrapper class which takes care of opening a window, initializing the important plugins (system, file access, renderer, input, etc) and which does the main loop. It calls overloaded functions such as DoLogic, Prerender, Render, Postrender. It also provides callback functions for input (event handling) and the gui (intermitten gui rendering).
Phew... this is some years of work ;)
Now, I have plans to do some changements:
1. The whole stuff has to be multitask able. Means that I want to be able to start different threads with different parts of the engine. One thread for physics, one for file access, one for the rendering, one for the logic etc.
2. I want to rewrite the render kernel to be shader based only. Right now it has a whole bunch of fixed function codes which I want to get rid of.
3. Scripting! I've taken a look at Lua 5.1. It seems to me that it is much easier to handle C++ classes (and their function calls) with this version. With 4.0 any function binding was a PITA. I tried converting the 4.0 code to 5.1 but it contains so much special cases... argh... I'm tempted to rewrite the entire scripting stuff from scratch.
I also want almost any part of my game engine accessible through Lua scripts.
4. I want to improve the ease of use. Don't get me wrong. Using the Game Framework doesn't take you any longer to have a new, running framework in less than 10 minutes. I want to make the function names and the usage more intuitiv.
5. Add some GFX file formats which can take care of mipmaps.
6. Improve the 3D format handling. Right now, I have my own exporter (for a known GFX software ;) ), but it's a pain to keep up with the fast releases of those applications. So I'm thinking of writing some main stream importers (MDx, Collada) and either have them integrated directly into the engine or write converter software. I want to be more or less independent of the gfx source; it's the format that matters, not the software.
7. Improve the core engine to better handle rendering to target, post processing (it has a complete post process engine but it's a PITA to configure it), shadow maps, ID buffers etc.
8. Try to seperate the physics from all the rest.
9. Rewrite the sound code (which is a fmod wrapper right know) and make it a plug in (as almost everything else).
Well... a lot of things to do ;)