Yah thats another thing I've done. Although Classes don't register what types of messages they send, only the messages they're interested in. Any "MessageHandler" can subscribe to messages, by type, or by type AND from a particular source. So basically the Core just puts out messages like a RenderOneFrame message, and anybody listening, ie the GraphicsSystem, should receive that message, and respond by calling renderOneFrame.
The reason I said that classes could register message types is in case they want to spend specific sorts. Say you have a standard list of message types, by which I mean the sort of data they'd ship around... so (just for example), type 0 is for input, type 1 is for network polling, type 2 indicates a filesystem message, type 3 could be for the renderer, and so on. Perhaps a class wants to add a type of message, for whatever reason. It asks for and is allocated a message type ID, and all messages of that type are bound to that module. Within each type, of course, you can subdivide to your heart's content.
I agree that subscribers should be able to filter by originators, too.
Now that you've read my code snippet, consider this:
// Path to bitmap image for splash screen
const std::string splashBitmapPath = ".\\resources\\rotm-splash.bmp";
Gaia::LinuxSplashScreen* ss = new Gaia::LinuxSplashScreen(splashBitmapPath,0,255,0);
Gaia::Core* engine = new Gaia::Core(ss);
Gaia::StateManager* stateManager = Gaia::StateManager::getSingletonPtr();
RotM::Play* playState = new RotM::Play();
The differences are small and big at the same time.
I bow to your obvious greater-than-me-ness, but I take much egoboost from the fact that I'm thinking along the same lines as you
Although I wouldn't do things quite the same way that you have. I'd make all the systems you have there just make a subscription to one of the zero priority messages. Maybe I'm misreading the code (it's late here), but the engine still is tied to the render system: it's not fully decoupled as it is with mine. With the 'CPU' I have in mind, there's absolutely no point of contact between the core and the modules which interface through it beyond the messages. It doesn't need to know anything that's going on around it, so it doesn't know.
 By the way I agree with Calder above, he highlighted 3 really big points. Ogre claims to be just a rendering engine, but its really a massive beast, its hard to treat Ogre as just a component. My library Gaia has its own Vector2, Vector3, ColorValue, StringUtil lib, Math lib, StringConverter lib, etc.. and its all from Ogre, but I don't want my engine to depend on Ogre, nor are those data types/utility functions Ogre specific. Pretty sure everybody has copied the classes I've listed numerous times.. *cough Ogre needs to split these classes into a generic util lib*
Ogre isn't a component, sadly. Ogre is a real pain in the butt.
That message subscription system sounds really cool! If I'm not mistaken, you two are basically saying the exact same thing as with the exception of registering senders. Out of curiosity, have either of you ever used Objective-C? From the wiki page:
I've never used it, but I've read about it when bored and idly flicking through Wikipedia. I like the idea of it, with message passing, and I suppose it's unconsciously part of what I'm thinking of. That said, what would be very fun is if data could somehow just be left 'for collection', as it were... if each module were to run in its own thread (yeah, I know, as if) then it could just grab data from some central point and it would be possible to cut out the function passing entirely. Erlang does things in that sort of way, if I remember correctly.
Edit: Speaking of Objective-C, I was just forced by circumstances to write an equivalent for it's callInThread() function. There's sum really funky templating going on, but all in all I'm pretty satisfied with it. You can call pretty much any function with up to three arguments (could be arbitrarily large with some copy/pasting) and have it executed during Ogre's frameEnded sequence as either blocking or background. I'm considering re-writing our BufferedObject implementations with it to simplify things. Here's the code if anyone's interested: JDThreadUtils.cpp and JDThreadUtils.h
That really is some funky code. Made my eyes water and bug out on stalks. Templates are not something I'm particularly hot on, to be honest. I've only been at C++ for two or three years, there's a lot to learn.