I’ve now completed some additional engine work and implemented some architectural changes. The “Engine” is now decoupled quite a bit from the other components. So at the moment I have:

  1. SDLGLHandler  which manages the creation and management of the SDL_Window*  and the SDL_GLContext* . Essentially this does the buffer swapping, it also applies a spaceengine::PostProcessingEffectChain to the buffer before being swapped to the window.
  2. PostProcessingEffectChain  which is made up of a series of PostProcessingEffect s. This applies things like bloom and the real-time lens flare and bokeh. This is currently handled by external SpaceFormatFiles.
  3. SpaceEngine  and a GameObject  class which are closely linked. Basically, the SpaceEngine  object holds an SDLGLHandler  and a GameObject*  . When the SpaceEngine  instance is started, it throws the GameObject s Start  method into a new thread and then drops into a standard SDL message pump.

    The only message explicitly handled is SDL_WINDOWEVENT_CLOSE , everything that’s input related is thrown to the InputManager .

    After processing the messages in the queue the draw method of the GameObject  is called followed by the swapping method of SDLGLHandler .

    For it’s part, the GameObject  is an abstract class. When using my engine, you need to derive your own game class from GameObject  and implement the drawing method and update method. You also need to register your own callbacks via the InputManager . This GameObject  features a single std::mutex  as all methods need to be thread-safe.

  4. A static InputManager  class. This class features methods to push events onto a queue and to register callback functors that will be called if a specific SDL_EventType  is processed.

    The InputManager  finally has a Start  method which creates a new thread to process the internal queue, looking at each SDL_Event.type  and calling the correlated functors from the registered callbacks.

I’ve gone with a multi-threaded approach for a couple of reasons. Firstly I wanted to learn how to do it. Secondly, I anticipate needing the decoupled processing to handle the various aspects of the simulation.

I’m pretty happy, aside from any exception handling, the main function looks like this:

SpecificGame is derived from GameObject . You can see how both the SpaceEngine and the GameObject hold a pointer to each other. This allows the Engine to ask the game to quit as well as allow the game to ask the engine to quit.

My reasoning for this is that the game window could be closed, which I consider an engine responsibility, vs game specific menu options which would also need to close the game. I believe I could manually push the window close event onto the queue from the game if I needed to; but I think this method works well enough as it doesn’t require the game to suddenly need to be cognisant of SDL2.

Leave a Reply

Your email address will not be published. Required fields are marked *