Sign in to follow this  

Engine parts and where to put them.

This topic is 3660 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, This days I´m really busy with my engine. I have finished several subsystems of it, and I´m wondering where should they be placed to let client apps use them. I have a Render Subsystem (Ogre3D), a ScriptSubsystem (ScriptManager + Script Class), a Sound subsystem (DirectSound) and an Input Subsystem (OIS). Well, first of all, would you put every subsystem in a namespace? Things like Render Subsytem, Sound and Input are just a class ready to innstantiate and use. Would you mantain this subsystems as singletons and access them globaly? Example: #include "InputSubsystem.h" AGameClass::function() { InputSubsystem.GetInstance()->DoThings(); } Another option I have thought about is just throw all this in a base app class and let game apps derivate from this, something like: class BaseApp : Singleton<BaseApp> { ... SoundSubsytem* GetSoundSubsystem(); InputSubsystem* GetInputSubsystem(); ... protected: SoundSubsystem* m_pSound; InputSubsystem* m_pInput; RenderSubsytem* m_pInput; .... } Last option, is to have a Engine class, where all subsystem instances are held (same as with the Base Application option) but separated in a Engine class, then, the App will contain a instance of Engine (or perhaps Engien would be a namespace?). I´m a bit confuses with this, If anyone could explain how you have lay out your engine, I would be really greatfull, remember that I don´t want any explanation about implementation, just how to Organize everything when you have the parts for easy/logical access. Thanks in advance, notbad.

Share this post


Link to post
Share on other sites
I consider an engine to be a toolbox. It consists of layers, where each layer is designed to ease the use of the underlying layer (except the bottom layer, which provides actual engine functionality, such as printing graphics, playing sounds, gathering input or sending network data). The superior layers are not necessary and may be loaded/created at will.

Share this post


Link to post
Share on other sites
In my engine I have a Video sub-system (e.g. X11Video, CGVideo, ...), Audio sub-system (e.g. ALSA, CoreAudio (Mac), ...), Input sub-system (e.g. X11Input, CarbonInput,...), and the rendering sub-systems Sounds (OpenAL, ARTYSounds,...) and Graphics (GLGraphics, SVGraphics, ...). The top level is the System (non-sub-)system (e.g. LinuxSystem, MacOSSystem). All base classes are in the basic namespace, but implementations may have their own; they _will_ have if they are implemented as a plug-in (in general, all my plug-ins have an own namespace).

I've written the (sub-)systems so that an Application is able to run w/o the knowledge on which concrete type of System it is running. On the other hand, an Application _can_ do OS specific stuff if it knows the System's type. E.g. it is possible that an Application provides its own special Input derivative, plugging it into the System that runs the Application. However, this way implies that concrete Video, Audio, Input, Graphics, and Sounds are not singletons but instances created when needed and plugged together, either automatically or manually.

In this concept the engine isn't a class by itself. Also the System cannot be seen as engine, since System doesn't know something about e.g. 3D. It does nothing more (well, approximately) than to grant access to suitable Video and Audio instances (e.g. LinuxSystem tries to load the ALSA Audio sub-system on default, and if that fails it may try to load the OSS or whatever) that itself enumerate Video::Device and Audio::Device instances, that itself provide those Graphics and Sounds instances for which they are suitable backends.

The engine as such is hence the sum of Extensions (named instances that are available from registries; e.g. the Video::registry holds all currently known Video sub-systems) that are plugged together by the Application. If the Application doesn't successfully activate a Sounds sub-system, then there will be no need to power on the speakers.

BTW: One can ask why I go this complex looking way. Well, I develop more than 1 application, and large parts of the libraries are used in almost all applications. Included are tests executables, little technology demos, and real applications like 3D world editors.

Share this post


Link to post
Share on other sites
Thanks for thte anser but I´m still a bit lost.

ToohrVyk could you explain your view a little more? For example where should the World class go? Can it be considered a subsystem?.

Thanks in advance,
HexDump.

Share this post


Link to post
Share on other sites

This topic is 3660 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this