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.
 - If you are manually constructing a class and it has an "initialize()" method, then you need to call it before using the class. Most object creation is wrapped
   in methods which do this automatically though. ("create()" methods)
 - Unlike most other objects you don't have to worry about cleaning up GUI elements. You can destroy them manually if you want to get rid of a 
   specific element, but normally destruction will be handled by the owning GUIWidget.
 - 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 (without the _ prefix).
	  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 systems I will use "prefix _" notation interchangeably with friend class approach. Sometimes I prefer to extend the 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.
	  A lot of the classes are only meant for internal usage. In that case the entire class is marked with "Internal class", but none of its methods are prefixed or specially documented. 
	  In such class it is assumed all methods are internal and generally aren't meant for normal day to day use.
	- "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.