Implement example framework/debug GUI

[pmiddend]

This is mainly a brainstorming issue.

Open questions

• I'd like to put the initialization of sge::systems into the example framework, but how do we determine which examples needs which subsystem? This goes along with providing the ability to dynamically switch backends (see below).

  Random Ideas

• We might need peformance analysis graphs, for example the fps graph (which should not be displayed all the time). This is non-interactive and can be implemented as an overlay, maybe with a heading "FPS:" and the graph below. rucksack might help with the layouting stuff.
• We also need a mechanism to dynamically configure plugins. Maybe you want to start an example with OpenGL and DirectX to compare the two. Or with OpenAL/DSound.
• The example framework should wrap "render only if we have a viewport" or later "render only if we are shown" (when the show/hide notifications are in place).

  Parameter handling and the command line

  Graphical

• To experiment with parameters, we might need text input fields or sliders for numeric values. This is, of course, interactive, and should be displayed in a separate "dialog".
• The interactive dialog should be easily accessible, for example by pressing the F1 key, and then be opaque or transparent, lying atop the rest of the application.
• The dialog then, of course, needs the input focus (this should be switcheable)
• To output important stuff like "Scene took 30ms to load", instead of just using "cout" (which is cumbersome in Windows where you usually don't start your applications in a console window), we could output to the debug gui. This could, in turn, output to cout and additionally render the output to a buffer, which is displayed when pressing F1 (see above).
• Maybe we also need a way to easily pass parameters such as "window size" to the program, even when we have no command line (like on Windows). A simple launcher might do the trick here.

  Command line

• We could use boost.program_options for the command line parameters.
  • The particular example has to specify which command line options it accepts. To do that, the example has to provide a boost::po::options_description.
  • The example framework could use this to parse the command line (or maybe additionally a configuration file).
  • The framework could then offer a boost::po::variables_map for access via vm["foo"].as<int>() (which is, of course, type unsafe).
  • Alternatively, an options description can include strongly typed arguments via boost::po::value<T>.
  • The example framework itself could easily add its own command line parameters (for the chosen renderer backend, for example).

[pmiddend]

This is somewhat connected to #53 or "Implement better crash behavior".

[pmiddend]

Inspiration: http://www.ogre3d.org/tikiwiki/tiki-index.php?page=SdkTrays