TODO

*******************************************************************************

DONE:

*******************************************************************************

WORKLIST:

- Game VFS: https://github.com/kiith-sa/D-GameVFS - interesting, this is
  something I have thought to make with BLOB (layering them to allow
  patching).

- Awesomium for GUI?

- render/ is for 2D/3D pipeline building blocks. ext/ and ext/simple/ will
  contain fully assembled, generic, ready-to-use pipelines for common
  situations.

- Shader GLSL code need not to be included to BLOB. If it goes there
  automatically, it is OK. In other cases (e.g. stock shaders), we can
  always use import to link the GLSL.

- ALMOST DONE: Replace ulong with size_t (make 32-bit compilations to work)

- Emulated joystick: trigger axis is between -1 ... 1, not between 0 ... +/- 1

- Enums have .max property: check if this can be used in joystick definitions.

- There is a need to separate gpu.Shader and GLSL compilation results. We
  might have shader with same source, but with different options.

- Camera now has initial zooming. There is a need to make the solution more
  generic.

- Canvas (direct draw): Canvas do not contain "passive" objects to be
  rendered, instead it has objects to create drawing commands on canvas. Mainly
  for use as a base for GUI.

- We need "removed" flag for certain objects, like Node. As we don't know in
  what groups/lists node is added, we can mark it to be removed, and when
  it is found somewhere, it is then removed.

- Examine order-independent transparency:

    http://casual-effects.blogspot.in/2014/03/weighted-blended-order-independent.html

- Start developing portal engine. Start with level editor. We need editor
  to create portals.

- Start working with navigation. The first step is to create a network
  of nodes suitable for pacman-like games.

- I need more freedom. What I should do is to create now a high (game) level
  interface to rendering. Then, while working with internals, that does note
  (necessarily) affect to the game functionality. It - no, they do not need
  to be perfect. I can create high level interface for specific subset of
  games.

- I should port my java applet ShootEmUp to this platform (Linux, D, OpenGL).
  There are ready-made graphics (not too high quality, though) and game logic.

- Model loading (and other nice tutorials):

    http://www.learnopengl.com/#!Model-Loading/Model

- Renderer framework: Better integration of SkyBox (and forthcoming
  postprocessing effects) to 3D scene rendering.

- Cubemap needs all faces to be: same size, same internal format, same
  mipmap level. Ensure this in loader.

- GLSL files may need some common libraries? In any case, think about
  how to organize GLSL source files.

- Framebuffers: It is possible to share depth buffer between multiple
  framebuffers, when we are only interested in color map.

- After dividing shader implementation, there's problem with VAO as data
  packet. Somehow we need to be able to create class to keep data... It
  might require storing VAOs and such to shader itself.

- I would need to collect some default setups to e.g. ext/ directory,
  so that I could work at higher levels without needing to worry about
  low level changes.

- "Active nodes" - combine Fiber and Node to ease making actively working
  nodes.

- Decals (e.g. for targeting circles)

- Examine, if BLOB (std.archive) could support symbolic links

- Model.sheet: This is using atlas for rendering. It would be
  probably best to implement dedicated atlas sprite blitter...

- Bitmap manipulation: when loading BW bitmaps, convert them suitable
  for colorizing.

- Study: Shader Uniform buffers? Any use?

    https://www.opengl.org/wiki/Uniform_Buffer_Object
    https://www.opengl.org/wiki/Interface_Block_(GLSL)

- Fonts & Texture loader: Fonts may need specific texture loader, for example,
  if the glyphs are zoomed considerably (e.g. text in 3D graphics). This is
  partly done, we have Texture.Loader class already to set sampling options.

- One thing to think about some times: we would like to activate GPU
  processing as soon as possible, to make it work parallel to CPU. But there
  are things that restrict this. For example, CPU needs to fetch all
  nodes before they can be sorted.

*******************************************************************************

MISC: Yet uncategorized "Post-It" notes...

- License - as things fall under default copyright laws without license,
  I need to think about this. Is it PD or MIT?
  
        Check: http://choosealicense.com/

- "Multi-material" meshes: It would be good to think about the
  implementation a little bit, so that it would fit to future development.
  Quickly the current thought:

        VBO + IBO   0   ... x       MeshPart 1
                    x+1 ... y       MeshPart 2
                    ...

  MeshPart is an IBO range. When rendering, you can keep both VBO
  and IBO binded, while changing material between next range.

  This is just not necessarily enough, as you may want to render parts
  in different rendering stages. As a simple example, consider a tree.
  Trees are usually constructed so that trunk and larger branches are
  solid meshes, while leafs and small branches are transparent textures.
  
  What you want, is to separate solid and transparent parts to different
  rendering stages.

- CONTINUE: Node modifiers: Add support for "multi-textured" nodes - the idea
  is to have sort of "stamping", textures over textures. We add node-specific
  material modifiers at some point (like color modifier, but at the same time,
  we could add texture modifiers, too).
  
- Node modifiers: this needs to be a bit more sophisticated mechanism. For
  example, when drawing humans, we want skin color (as modifier) to be the
  base color under everything. Then we have clothes colormap, and also
  clothes variable colors (dyeing).

- Node/Model classification. We assume, that no model (part) ever is added
  to two batches in single stage. So, what we need, is to know to what
  batch the part is added in different stages:
  
        class Model {
            VAO vao;
            struct Part {
                Batch[Stage] destination;
                material;
                (IBO) range;
            }
        }

  For example: We have two rendering pipelines, one for rendering view,
  one for rendering shadow maps. We have tree, that contains several
  materials, some of them solid, some of them transparent:
  
        tree.trunk.destination[viewrender] = viewrender.solid
        tree.trunk.destination[shadowrender] = shadowrender.solid
        
        tree.leafs.destination[viewrender] = viewrender.transparent
        tree.leafs.destination[shadowrender] = shadowrender.transparent

  Basically, we could also use some kind of tagging to locate correct
  batch. We would then also need information to which rendering stages
  the model/part is included:

        viewrender.tag = "visual";
        viewrender.solidbatch.tag = "solid";
        
        shadowrender.tag = "shadowcaster";
        shadowrender.solidbatch.tag = "solid";
        
        ...
        ...

        model.tags = ["visual", "shadowcaster"];
        model.part.tag = "solid";

- Add "persistent" flag to Batch? Even regular 3D game may have
  rendering objects that are persistent (no need for visibility checks,
  and always rendered).

-------------------------------------------------------------------------------

HOTTISH TOPICS:

-------------------------------------------------------------------------------

FIX/INVESTIGATE: Crashes, flaws etc.

- SkyBox is not working on my laptop. Find the reason.

- IMPORTANT: Querying shader uniform and attribute locations will not work
  correctly if the shader is not activated (the functions will return the
  locations of the active shader). So, during uploading, we should ensure that the
  shader (or at least its family) is active. Another way to do this is to use
  fixed locations, but it sounds very laborous and inflexible solution.

- FIX: glGenerateMipmaps() seems not to work when using OpenGL 3.3 - with GL2.1
  it works.

- FIX: Font rendering fails randomly:

    http://stackoverflow.com/questions/26956658/sdl-ttf-rendertext-blended-fails-randomly

- FIX: On 32-bit Ubuntu, SDL FillRect segfaults (code that cuts textures from
  sprite sheet).

- Shader compiler (see gpucompiler.d) can only report error location for
  noveau/intel driver. Needs (1) driver detection, and (2) custom reporting for
  each driver.

- With normalized integer vectors (see gputypes.d), we use scaling, but
  in reality (for 8-bit) -1 -> -128, +1 -> +127.

- TBN calculation in current shader has its flaws (not normalized nor
  orthogonal in fragment shader), but it might be so that it has no
  significant effect to rendering result

- Current Bone implementation has a transformation cache. It is unclear to me,
  how it works with games loading levels (that is, does it cause memory leak).

- wolfish (and cylinderium) generally run at least as fast as pacman, although
  they use much more complicated CPU and GLSL code. I need to investigate 2D
  performance, as because of GUI elements it will matter to 3D games, too.

-------------------------------------------------------------------------------

DEBUG FEATURES, PROGRAMMING HELPERS, "USER-FRIENDLINESS": Features for helping
to debug and develop things, making source more portable (32/64-bit,
Linux/Windows), easier to set up, and so on:

- "Debug channel" to rendering batches: adding a debug mesh to an object
  will be sent there. Geometry shaders could be excellent for this purpose?
  To create debugging primitives (lines for normals, ...) automatically?
  
- It would be nice, if we could direct nodes / entire groups to
  "Wireframe shader"

- Found enforce from D documentation. It is like my old ERRORIF, a bit more
  advanced, though, because using template to allow it to return the value if
  it was OK. Go through code to find good places for it! Also, I implemented
  ERRORIF using same principle - this is good to give simple error message,
  instead of getting Exception dumping call tree.

- "CPU rendering": Rendering objects without uploading them to shader
  (as VAOs, VBOs), like simulated immediate mode. This might be good for
  example for debugging (rendering normally invisible things). Low priority,
  thought, at least initially.

- It would be nice to add D doc comments, at least test it. Finally, it would
  be nice if I could make it to compile with dub, and use dub registry.

- Do some debugging aids: Seeing matrices etc.

-------------------------------------------------------------------------------

USER INPUT:

- There should be interface for game to set the default emulation
  (e.g. Arrows: arrow keys -> left stick, WASDArrows: WASD -> left stick,
  arrows -> right stick).

- Include mouse to emulation. Mouse can emulate two axes.

- Joystick messages, including emulated ones, should only come from
  active controller.
  
- When choosing controller, we need to process events from all controllers.

- For GUI: Because you might still use keyboard/mouse for GUI even when
  having controller (when examining things closer), it is good that even
  with controller keyboard & mouse works for GUI. Currently, it works:
  we process emulated joystick, and that happens to be configure for
  arrows -> LT. This does not necessarily work if emulated controller
  is e.g. WASDArrows.
  
- In fact: I have thought that if game asks for naming things, you can use
  keyboard to type in the name. But... If we have emulated keyboard, then
  that typing has side effects... Need to be resolved at some point.

- "action detected" flag to joystick, so that we can flash at joystick
  selection menu from which controller we have received some action.

-------------------------------------------------------------------------------

RESOURCES:

- Create some simple 'Giana sisters' / 'Super Mario' universe. It would be nice
  to have 3D asset, so that it can be used to create (1) pseudo-3D platform,
  (2) pseudo-3D maze, and (3) 3D maze game.  

- How about "Paper Doll" set? 2D meshes with skeletal animation for 2D games?
  Is it possible, is it easy, does it help anything?

- Sintel The Game! There could be a set of animated 3D objects for my
  development purposes!

        http://sintelgame.org/

-------------------------------------------------------------------------------

GENERAL:

- Static linking: examine possibilities to link needed libraries
  (SDL?) statically to remove system side dependencies.

- VBO updating - or, in fact, "CPU-side" VBOs, mainly for instanced draws
  like particle engines. See e.g.
  
  * https://www.opengl.org/wiki/Buffer_Object_Streaming

  * http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/particles-instancing/

- Layer <-> geom needs reference point... This is/was intented to help creating
  2D HUD & games. It may be so that 2D games get their own Scene class some
  day? And anyways, geom module has had not much to do with 3D graphics ever
  since implementing Wavefront loader.

- Maybe some offline tools for processing images, meshes and materials?

-------------------------------------------------------------------------------

LOADERS, FILE FORMATS: We started to use Assimp to load model files. Some
design, sketching and planning is needed, as well as tuning the render
architecture more suitable for models loaded from files.

- Currently there seems to be some sort of a bug with LuaD and DMD 2.067+
  compilers causing it to segfault at exit. I might want to postpone the
  development until the problem is found & fixed.

- CONSIDER SERIOUSLY adding scripting support for asset loading! The idea
  here is, that e.g. lua scripts to load specific things are stored with
  the models, and thus they are stored to BLOB, too - no need for complex
  building mechanism to include correct converters to compiled program.

- Blender file (archive) loading

- COLLADA file loading. This project has some possibly interesting
  Collada files to try out:

    https://bitbucket.org/EricPoggel/yage/src/c12a0715d0a7?at=default

- BLOB "attachments": Larger games probably like to have separate resource
  files to ease updating. Without breaking existing behaviour, this could
  be done so that it is possible to include external archives/directories
  to look up for files.
  
- BLOB: Game saving: At some point, we need to add file writing to the engine.

- Wavefront loader: change it to use ASSIMP

- Wavefront loader: smoothed normals

- Wavefront loader & mesh-material pairs: Wavefront file format has
  groups (s[moothing group], g[group), which could be used to load
  mesh-material pairs, so that they can use same VBOs. Between each
  batch, we change IBO and material - nah, no need, we can give
  range to drawing command, and thus keep the same IBO.

- Some simple file format to create scenes (placing objects, creating
  object hierarchies, ...) could be useful. POVRay may be too complex.
  Something that can be used together with .obj & .mtl files... Of
  course, we need support to other mesh data formats, too, but .obj is
  quite common & useful anyways.

- Winding: In case that winding is incorrect when loading a model, we
  could have methods in Mesh class to try to fix it. At least, this
  would be better than changing winding parameter (CW / CCW) when
  rendering.

-------------------------------------------------------------------------------

FIBERS, EVENT PROCESSING:

- It would be good to be able to send events to be processed by a Fiber.
  If we have player Fiber, we might want to get the input events there.
  Think & design how to do this.

- It might be good, that FiberQueue callbacks return boolean value
  if they want to continue processing, or if they want them removed. Other
  way to do that would be adding the calling queue to parameters, so that
  callback can remove itself if wanted

- It would be good to implement (frame) timers to Fiber queue.

- simple.gameloop may need a function to determine loop breaking? That
  could simplify certain things...

- Check vibe.d for ideas for game actors (fibers)

- It would be good to create active nodes (nodes that are both nodes
  and fibers).

-------------------------------------------------------------------------------

GAME ALGORITHMS:

- Path: Create simple node network for games like pacman, where all movable
  objects follow paths from node to node.
  
- In pacman: player and ghost have (slightly) different path network. Also,
  we can use some kind of weighting to make ghosts to come out from their
  "nest" quicker, and prevent them getting back.
  
- Waypoint: Mechanism to create transform paths with waypoints.

- Navmesh: This is where we area heading to

- Set start & end derivates for Translate, and let it smooth the translation

-------------------------------------------------------------------------------

SHADERS: Shaders are so central part that they reserve their own section
here. Shader is connected to at least objects, materials and scenes, so these
issues have their relations to other sections in this TODO document.

- ONGOING: 3D shader, 2D GUI shader, and postprocessing effect shaders, they
  all have very different interface. Because of that, I probably need to drop
  Shader implementation even lower level, and create intermediate structures
  between render, canvas and such --> Because of this, I might consider taking
  glamour there.

- ShaderToy: Web site with WebGL, has working shaders. Could be very cool
  place to go through looking for shader ideas.

- Shaders: Raymarching? What is that? Realtime raytracing is the future. I
  should investigate it very closely!

- Shaders: Interior mapping, quite cool:

    http://interiormapping.oogst3d.net/

- I might need to go to version 130 with shaders. For creating compatible shader
  banks, it is mandatory to ensure that attributes are at the same location.
  Otherwise, loaded VBOs (via VAO) do not work: not a problem at the moment, as
  attributes are bind by hand.

- Half-done: Improve introspection: dumping uniforms etc at compilation module, to
  help improving & debugging shaders.

- Design "multi-shader" shader: A shader that has several compiled shader
  programs, that can share the same instances.

- Some sort of batch processing with shaders? See:

    * http://www.gamedev.net/page/resources/_/technical/opengl/opengl-batch-rendering-r3900

- It is possible to compile GLSL library code to shader program, and then
  link multiple of these programs together with specific main(). Investigate
  this:
  
      http://stackoverflow.com/questions/9168252/attaching-multiple-shaders-of-the-same-type-in-a-single-opengl-program

- Think Shader subsystem. We would like to have specialized shaders for
  particle engines, not using the regular mesh-material data structures.

- Shader family: It could be time to concentrate on shader management
  before going forward:

  * Shader family: to upload stuff to GPU w/o creating actual shader

    - Problem: for binding VBOs and VAOs, the shader program needs
      to be active...

  * Shader compilation: for error reporting, would be good to create
    "precompiled" libraries. I have a feeling that I can never make
    error reporting reliable (w/ current OpenGL implementation) for
    "preprocessed" sources, so it would be best to compile GLSL files
    just as the programmer made them.

  * Move default shaders to ext/ directory... Would be better to locate
    them to stock/ - or create a new directory for defaults...

- Move default shaders under ext/ directory (?)

-------------------------------------------------------------------------------

GEOMETRY SHADER: Creating shapes on-the-fly:

- Create rectangle for blitting 2D sprite to screen (from point input)

- Create particle mesh for particle engine: But maybe it is better for this
  to store it as VAO, so that you can change the particle shape.

- Debugging: Showing normals etc.

-------------------------------------------------------------------------------

SPECIALS:

- Interior shading: Creating interiors (viewed outside) just with
  fragment shader without any geometry. Think if we find good application
  for this, or can use the basic idea for something useful:

        http://interiormapping.oogst3d.net/

-------------------------------------------------------------------------------

OPTIMIZATIONS: While optimizations are not that important, here is some list
of optimizing features I might consider for implementing. For that purpose,
keep these in mind so that architecture does not prevent implementing these:

- Organize triangles to strips, study primitive restart:

    * glEnable(GL_PRIMITIVE_RESTART)​
    * glPrimitiveRestartIndex(65535)​
    * https://www.opengl.org/wiki/Vertex_Rendering#Primitive_Restart

- Sorting drawing so that the same vertice is preferably used in consecutive
  calls, to improve GPU cache performance.

- Think if it is possible automatically pad things:

    "Padding is added to make the vertex structure a multiple of 32 bytes
     since some GPUs prefer it that way, such as ATI/AMD."

    https://www.opengl.org/wiki/Client-Side_Vertex_Arrays

-------------------------------------------------------------------------------

SCENES, LAYERS:

- I'm still not entirely satisfied with the current system. It is currently
  possible to use batch groups directly as scene graphs, which is basically
  good for games like pacman. But:
  
  * We should have node sorting (front to back, ...): It is possible
    to do at draw function, thought.
  
  * We could remove viewing information from scene node, and add it
    to batch node.

- How about making unbuffered batch? Currently, nodes are buffered to
  batch, but we could send them directly to shader: basically, if
  first batch in batch group is unordered, it could be unbuffered, too.
  There is - of course - problem to determine when render state block
  is applied...

- Store viewing information to batch node, not to scene node. Same node
  may be retrieved multiple times from different angles.

- Probably it is better to classify objects at Layer/Scene level already...
  Keeping objects in one single list helps lookups, but (1) I assume that
  they are more rare operations than rendering calls, and (2) that can
  be simulated anyways (lookup looks from all lists).
  
  * Look at Cylinderium: it has 2 interleaved scenes, one for mother ship,
    one for star field. We might consider generalizing something similar?

- Because of this, it might make some sense to bind lights, visibility
  checks and such to camera. The same information could then be used
  by all scene layers. Need thinking...

- Skybox: Cylinderium could use this, in addition to star field. Skybox
  does not replace star field - star field is three dimensional, skybox
  is basically just two dimensional background image.

- Occlusion queries?

    * https://www.opengl.org/wiki/Query_Object#Occlusion_queries

-------------------------------------------------------------------------------

3D OBJECTS:

- Reconsider rotation, it's very unintuitive at the moment. Currently you
  need to make parent hierarchies to keep rotations in order...

- Currently, we have Grip class, that generates transform matrices from
  position, rotation and scaling. It is possible, that we need also
  other ways to generate transform matrices - so, be prepared for that.

    * We might want to get Grips from game logic/physics layer (e.g.
      portal, or navmesh)
  
- Scaling is not entirely working, mainly because it would need updating of
  bounding sphere. Non-uniform scaling is anyways pretty hard to make
  to work correctly (affects to normals etc).

- Points & lines: (1) in meshes, separate points, lines and triangles
  (different IBOs for each; combine somehow with material groups). Think
  a system to tell point size (glPointSize), and finally, we might have
  particle engine...
  
  * In fact: Meshes are meshes. Lines and points are rendered by different
    shaders, or at least, they form different kind of objects, not meshes.
    
- Multiple mesh-material pairs in same object: Maybe with vertex groups?
  Adding IBO-Material pairs to VAOs? No need for separate IBOs, just start
  index for each batch.

- Ways to extend Mesh class. Some way to attach more vertex data to
  Mesh so that Shader understands it, for example, skeleton.

- LOD, Level of Detail: like textures have mipmaps, 3D objects could also have
  representations in various details. Including materials. And shaders? No
  need for high-quality shading for low-detail objects.

- Billboards and imposters

- Half-done: Instanced rendering: Layers with single mesh type for OpenGL
  instanced rendering? Probably no, it is probably better idea to have "instanced
  instance", instance with single shape and multiple positions. But well...
  Maybe a particle layer is not a bad idea? Need thinking...
  
- Where instanced rendering would perform best? If there is multiples of same
  mesh near each other, then we could take the advantage of both worlds:
  having efficient CPU-side prunings, AND instanced rendering. For example,
  branches and leaves in a tree.

- Investigate using of GL_ARB_vertex_attrib_binding functions to bind
  buffers and attributes, instead of glVertexAttribPointer.

-------------------------------------------------------------------------------

PARTICLE & SPRITE ENGINE: It might be nice to have specialized
classes to blit lots of things into 2D/3D space.

- Found OpenGL Array Textures. Can these be used instead of atlases? For
  sprite sheet blitters?

    https://www.opengl.org/wiki/Array_Texture

- Particle engine can (most probably) have only 1 texture. So, the solution
  is to create sprite sheets?
  
- Anyways, there are probably at least three different sprite engines:

  1) Lowest performance engine works like current TextBox: We could add
     depth things there, so that you could draw text background *after*
     printing the text. Or can we? It will be tricky...

  2) Highest performance engine is "regular" particle engine.

- We might want to separate static and dynamic sprite engines: backgrounds,
  starfields and such would be rendered by static engine, moving sprites
  by dynamic engine.

-------------------------------------------------------------------------------

2D OBJECTS, GUI, HUD: GUI sketching/planning/designing is ongoing. Sure, the
focus is on game rendering engine (render/ directory structure), but also sure,
GUI/HUD is pretty damn important to play a game, even a 3D game. And sure,
if we need 2D graphics engine for HUD & GUI, why not use it for implementing
2D games?

- Maybe we use SDL rendering for GUI? Just to get rid of artifacts?

- Maybe own dedicated 2D shader for GUI?

- Z-buffering with 2D: It could help at certain things, as then you could
  send objects to blitter in random order. But it would not work with
  transparent bitmaps anyways, and most 2D games trust heavily on transparency
  to implement shapes (unlike 3D which uses meshes for shapes).

-------------------------------------------------------------------------------

ANIMATION:

- Blender: http://wiki.blender.org/index.php/Doc:2.6/Manual/Animation

- One tough question: How to update bounding volumes on animated (deforming)
  meshes? Use coarse approximation? Try to guess the max possible?

- Easy curve generator to tools... Some curves are easier to generate
  numerically with simulator...

-------------------------------------------------------------------------------

LIGHTS, MATERIALS: Lights and materials are fragment shader inputs. It would be
good that these are generic (but simple enough) to support different kinds of
shaders.

- Design light management... Shaders will always possess limitations to how
  many lights they can handle per object

- Shadows

- Study other shading models

- Half-done: Design some sort of mechanism for some uniform material parameters,
  so that you can change shading model and still have somewhat similar results

- It would be nice to have some kind of "database" system for materials,
  combining e.g. color & normal maps and roughness together, so that you
  could load materials with fewer lines in the code. Similarly, there
  could be data files for other assets like sprite sheets (describing the
  dimensions of the sheet) for loading them with less efforts.

- It might be wise to move normal maps from material to "mesh": it is more
  like added geometry than a material parameter... Although it can be
  that, too...

- Environment mapping (reflections):

    http://learnopengl.com/#!Advanced-OpenGL/Cubemaps

-------------------------------------------------------------------------------

POSTPROCESSING EFFECTS:

- "Flashing" - we do this as we did at the beginning, by blitting a
  window size rectangle at the top of the rendered scene.

-------------------------------------------------------------------------------

CAMERA:

- Viewport settings to camera... In fact, create sort of RenderTarget
  class.

- Camera: Store projection parameters to a class, and let it generate
  projection. This is needed for zooming. Could act like Grip works for
  Transform.

-------------------------------------------------------------------------------

TEXTURES:

- Texture update (updating Texture pixel information from CPU side)

- Texture download (downloading e.g. rendered Texture to CPU side)

- Rename Texture.Loader to Texture.Sampler?

    https://www.opengl.org/wiki/Sampler_Object

-------------------------------------------------------------------------------

BITMAPS:

- CPU-side bitmap operations that could be useful: (1) scaling, (2) adding/
  removing alpha layer. Maybe (3) "loadtime" "stamping" (blitting bitmaps over
  bitmaps): we most probably need the feature in shader, but we could also
  support combining bitmaps at loadtime.

- Load-time scaling of bitmaps (some kind of image manipulation
  library)

- Some sort of "tile toolkit" to create tiles?

- Also, some sort of normal map toolkit to create normal maps

- Atlas creation

- Bitmap.splitSheet: Scaling splitted sprites does not work.

-------------------------------------------------------------------------------

FONTS:

- For some reason, rendered text at plain alpha channel does not work.
  Investigate.

- Half-done: Bitmap sheet loading need to be generalized, needed for both text
  and (at least 2D) game objects 

- At some point, we need to modify text to support UTF-8 (for moe3d)

- Investigate possible alternative solutions for rendering (HUD) text. Maybe
  rendering at CPU, and using subtextures?

- Also, we could use GPU to scale letters, no need to create font for all
  sizes. Check the result.

- Also, current system is made for HUD (screen coordinates), design a way to
  use it for 3D objects

-------------------------------------------------------------------------------

SOUNDS:

- Think a little bit about them...

-------------------------------------------------------------------------------

ARCHITECTURE:

- Shaders and layers... VAOs, VBOs and such, they are sort of bind to shader.
  At some point, we might need to ensure that shader can't be switched after
  meshes in layer are bind to certain shader. Or something like that.

-------------------------------------------------------------------------------

LOW PRIORITY:

- Study Manhattan distance to be used as quick way to filter nearby elements