Currently the initialisation sequence of the various subsystems/singletons is hardcoded in src/Engine.cpp.

Possible Solution
Implement kind of 'objectregistry' for storing and retrieving singletons/global objects. The registry should keep track of the construction order of the objects and be able to destruct them in reverse order.
Also modules should be able to register thread-local objects, like the entitysystem currently is.
Those have to be destructed previous to the module itself.

desired additional features:

• #6 Key to event mapping via configfile

Suggestion:

allow the User do define additional config files to be loaded.
access to those files could either be implemented by using the root nodes in the config ptree to distinguish between config files or by giving some other way of accessing other loaded config files

Example:

//loading
Engine::getCfg()->LoadConfig("keymap.cfg");

// usage
Engine::getCfg()->get<int>("keymap.keys.count");

// to access default cfg

Engine::getCfg()->get<int>("system.asdf.count");

the cmake files need to be updated to consider the submodules SFGUI and SFGUI/extlibs/SFML when searching for the libraries.
Also the "old" shipped sfml is no longer available and therefore should be removed from cmake

A window with custom

• title
• message
• type of answer (ok, abort/confirm, input) -> saved in enum
• answer-event -> Event( "MESSAGE_ANSWER_", Data )

features:

• center
• to create message send event (Controller in an existing class to make Messages needed)

extend the scripting interface to include more engine features:

• config access
• logging
• Resourcemanager
• IO Support ( deriving/implementing IOPlugin )
• graphics module: actors, rendering
• entity component system ( find a way to implement components and systems in the scripting language )

As first sfg window the engine should include a debug window for viewing debug_string events and logs
The debugwindow from MaximumFish can be adapted to do this
Additional features desired:

• Minecraft style debug information ( fully transparent window, open close with F3 )
• Customisation support:
• show/hide debug_string events or log, either dynamically ( checkboxes ) or via config

some parts of sbe require configuration values and currently fail with an exception if those are not present.
Maybe implement one of the following options:

• generation of default config files: this requires some knowledge of all used configuration options. Config could be extended to allow 'registration' of used configuration values maybe including some kind of description. An alternative would be to read those system-cfg-values via a special getter which accepts a default value and writes that to the cfg if the key didn't exist before. On Exit the completed config could be written to disk

Write a class that is able to draw simple 2d curves and diagramms.
There a two options for implementing this:
CPU: draw to a sf::Image
GPU: render to a sf::Texture

required by brainpower/Maximum-Fish#15

The camera needs members and functtions to allow limiting the viewport to a certain size

Some images(mostly png?) especially on windows are not loaded correctly.

The wrapper around sf::istream is probably not implemented correctly

This should include:

• #8 Screen class for managing the renderer, graphics main loop, simple eventconversion
• #9 simple renderer ( derived from maximumfish or sba ) for managing actors and layers
• a few simple sfg::Windows for use in applications (from maximumfish):
• #10 debugwindow: shows dbg_string events and log, may include a console

Part of #7
The renderer should support:

• Management of actors in layers
  • z-index for each layer
  • optional culling via quadtrees/view frustrum
  • runtime addition or deletion of layers
• different actor types:
  • sprites
  • vertexarrays
  • animated ImageSet's/Animation's
• adding, removing and updating actors via events

Update the EventUser class to allow registration of an std::function<void(Event& e) callback, so the user doesn't need to write long if-else-if parts inside the HandleEvent method if there would be only a simple action or method call invoked when the event is received.
Optional:
Extend Module to allow registration for events with a callback without having to derive from the EventUser class.

this would allow it to store keymappings in config files

...

The current algorithm doens't take into account how much more time than allowed has been needed in previous frames and thus sleeps for a frame even if the previous took much longer than they should

This probably needs Shaders to be defined in a ptree-resource file to specifiy the name and vertex/fragment programs