2018 Refactoring Description

@kazuo256 and @josealvim have discussed the current nature of the Graphics System, and have reached a state we want to change a bunch of things about the engine.

We'd like to:

Hide the ugly parts of the engine from the user:

It is not nice that we have to get the managers to register stuff, we get nothing from them, and thus there is no reason for them to be visible to the user. They'll still be around, but they'll do the jobs internally.

Rather than having:

  auto &resourceman =  resource::manager();
  auto archimedes = resourceman.GetContainer<graphic::GLTexture>()->Load("arquimedes.png", "img logo");

We'd have something along the lines of: UGDK::Texture archimedes("arquimedes.png");

The idea is to have the class constructors register their instances automatically, and have most of the accessible classes being interfaces.

Use interface classes for the User Interface:

We want ease of use when interfacing with the engine. For that we'd like to have interface classes that dictate behaviors.

1. Drawable
   • Has method to be drawn onto a Target via a Canvas.
2. Target
   • Wraps the idea of frame buffer, we use it to represent things on the video card.
3. Canvas (per se)
   • Handles the GL context (and possesses a Target), so it stores shader program information, color, clear_color, transformations and whatnot. Can't be interfaced with directly, we need to use proxies.
4. CanvasProxy
   • Interface to for Canvas, we'll use this to draw etc. It can die, leave scope whereas the Canvas itself isn't so local.

The idea is that we have a Target, say, a screen. We make a CanvasProxy from it. It associates that proxy to the appropriated canvas hidden in the implementation.

When we say something like: canvas << bob_dude_model;

When we send a drawable to a canvas for drawing, we should register that request for the graphic manager to execute in the draw phase of the gameloop. There, the canvas will be activated, the context will be set and everything should work. The idea is, we can queue actions on these objects and have them happen (in the right order) only in the draw phase.

Example:

A typical program would be something like:

  #include<a/lot/of/headers.h>
  using a::bunch::of::stuff;
	
  int main () {
    ugdk::Initialize(); /* Initializes the internal ugdk systems. 
	                 * Must be called first */

    Window main_window; // Initializes window with default size.
    Texture  blur_step; // Creates a texture to create the blur.
    blur_step.resize(main_window.size());
		
    auto canvas_p_texture = blur_step.canvas_proxy();
    auto canvas_p_window  = main_window.canvas_proxy();

    // ... some code about bob_dude		
		
    canvas_p_texture << bob_dude; /* Render bob_dude crisply into 
                                   * the texture */ 
    
    canvas_p_window.set_shader(blur_shader); /* set the shader to one
                                              * that blurs things */
		
    canvas_p_window << blur_step; /* We implicitly create a 
                                   * rect and render it to 
                                   * the target, blurry-ly */
		
    ugdk::Finalize(); /* Signal we are done and ugdk can safely commit
                       * seppuku */
    return 0;
}

Perhaps even changing "Canvas" to something like "Context" and "CanvasProxy" to "Canvas" would make it even more legible.