BansheeEngine/TODODoc.txt

 - Render system threading:
   - Make a list of thread-safe RenderSystem classes
    - For example HighLevelGpuProgram is thread safe but GpuProgram itself isn't
    - Classes that are safe to use outside of the render thread: RenderSystem, Mesh, Texture, HighLevelGpuProgram, Material, Shader, Technique
	- Classes that are only accessible from the render thread: GpuProgram, HardwarePixelBuffer, HardwareVertexBuffer, HardwareIndexBuffer
   - Add documentation notes to specific methods of classes that may be used both in and out of render thread
     - RenderTarget & RenderWindow for example. Methods like getWidth/getHeight can be made thread safe, while swapBuffers() cannot
  - GLSL limitations
     - layout(row_major) is not supported and will likely result in incorrect matrices
	 - Because GLSL introspection API is built around basic types I don't support structs or arrays of objects: 
      - I can't determine the size of struct or object arrays, as GL compiler will optimize out unused elements
 - Can't determine size of individual struct either, for the same reason (some struct members might get optimized out)
  - Texture limitations: Only 1D, 2D, 3D and Cube textures (and their samplers) are supported. Support for multisampled textures
     is included where necessary to implement render targets. Support for texture arrays and is not included.
 - Multiple inheritance is not supported on any class that is serialized with the help of RTTI. If you use it you can expect
   very weird issues.
 - If you're creating a hierarchy of classes with RTTI support, ALL classes in the hierarchy must have RTTI implementations. You cannot just leave
   some out, even if they contain no data. This would create incomplete RTTI class hierarchy which can cause various issues.
 - Notation rules:
    - Method prefixed with _ (i.e. _getDevice()) are internal methods used by the engine systems and normal user should not need to call them unless 
	  he really knows what is he doing. Those methods might also be marked with "Internal method" notation in their documentation.
	  Only methods that are part of the public interface have this syntax, as private methods are not visible to the user anyway, so there's no need for special notation.
	    - When communicating between system I will use "prefix _" notation interchangeably with friend class approach. Sometimes I prefer to extend to public interface and 
		add a _ prefixed method, and in other cases I prefer not to modify the public interface and make a class a friend and use a private method.
	- "Core method" notation in method documentation. This means the method is only meant to be called from the core thread. Calling it from another thread
	  will cause an exception at best, or cause unpredictable behaviour at worst.