BansheeEngine/TODO.txt

----------------------- CAMELOT 2D / GUI -----------------------------------------------------------

LONGTERM TODO:
1. Finish localization
2. Finish docking manager
3. Window drag'n'drop detect
4. Basic profiler
  - When building a profiler have main Profiler class which just does measurements, then ProfilerOverlay for data display on-screen, ProfilerEditor for Unity-like Profiler, etc.
  - For now just create a profiler with basic measuring stats (FPS, core & sim thread time, plus times for most important systems), and ProfilerOverlay to display them

PROFILER:
 TODO: Profiler is right now including windows.h. I need to work around that but don't feel like bothering with it atm
  - Easy way would be to move CPUProfiler outside of Utility and into Core (PROBABLY THE WAY TO DO IT - No point in wasting time on this)
  - Complex way would be to edit Timer and remove all the excess crap from it and just leave basic begin/end queries
 - When rendering GUI in front of scene view it seems to be rendering before the actual scene
  - This probably because the render texture alpha is less than 1, which makes it blend with the surface below it
 - In OpenGL rendering GUI to texture doesn't seem to work!?
 - Main window renders before the GUI render texture!

TODO: Viewport can be modified from the sim thread, but is used on the core thread without any syncronization mechanisms. Maybe add a method that returns VIEWPORT_DATA, and have that used on the core thread.

I still re-create GUIWidget mesh every frame instead of just updating it.

MAJOR ISSUE: writeSubresource/readSubresoure doesn't require a shared ptr to GpuResourceData which means it could get destroyed while still in command queue. Right now it only works because I block right after I call those methods, which ensures nothing is destroyed.
  - When fixed, make sure I remove blocking calls after writeSubresource where they're not needed (GUIManager for example)
I call waitUntilLoaded too many times. Sometimes 5-6 times in a single function. Each of those calls will be extremely slow.
GUIWidget::updateMeshes leaks. If I leave the game running I can see memory continously going up
 - BansheeApplication should probably derive from Camlelot application. Right now user needs to know the difference between 
   gApplication and gBansheeApp, which is non-intuitive (e.g. retrieving a window can be done on gApplication, but running main loop can happen on both

 Windows drag and drop detect
  - http://www.codeguru.com/cpp/misc/misc/draganddrop/article.php/c349/Drag-And-Drop-between-Window-Controls.htm
  - http://www.catch22.net/tuts/drop-target
  - http://msdn.microsoft.com/en-us/library/windows/desktop/bb776902(v=vs.85).aspx

IMMEDIATE:
 - OpenGL rendering slows to extremely with time (seems to be related to rendering, possibly GUI, possibly in general Pass/Material/Shader/PassParams)
 - Update debug camera so it uses callbacks
 
 - I have disabled linear filtering because it doesn't look good on scale9grid textures. (Add another material so it works with stretched textures?)
 - Enable alpha test so I don't render completely transparent pixels.
 - What happens when I don't set a texture for a state of a GUI element. Use a dummy white texture probably?
    - Make sure GUI system uses a dummy texture if one isn't available
	- SpriteTexture keeps a static reference to DUmmyTexture which I need to release before shutdown

- Hover colors of the scroll bar are wrong

TextBox needed elements:
 - Get DebugCamera to ignore input if GUI has already processed it

 - LATER
  - TAB between input elements
  - Remove updateText calls from updateRenderElementsInternal and instead call it whenever offsets change
  - I might consider not rendering caret from within input sprite to avoid redrawing it while, and draw it directly from GUIManager

GUIDragManager
 - GUI system sends startdrag/enddrag/drag events to all elements
 - startDrag(void* userPtr) changes cursor
 - releasing the cursor sends enddrag event and then the control can retrieve the user ptr
 - SINCE currently non-active elements ignore drag events, add GUIElement::acceptsMouseDrop property
   - Such elements will receive mouse drag and mouse up events if other element is active, and they can filter if they want to accept it

-----------

 - My test model is rendering back faces. I need to flip them.
  - Although more than likely I am loading the model incorrectly since it works in Unity?
  - I probably want to determine front faces based on normals

Immediate TODO:
 - A way to update mesh buffers without recreating vertex/index buffers (Setting data currently does exactly that)

----------------------------------------------------------------------------------------------
Other:
 - Move Debug to CamelotCore and add SetFillMode

-----------------------BACKLOG TODO---------------------------------------------------------------

----------------------------------------------------------------------------------------------
High priority:
 - GetRenderOperation doesn't consider sub-meshes

----------------------------------------------------------------------------------------------
Medium priority:
 - Mesh loading:
  - Example Freefall mesh has one index per vertex, and there are 17k+ vertices. I think I need a post-process step that optimizes them.
  - Imported FBX meshes are too big
 - Ogre performed special DDS loading. I removed that. I'm not sure if I'll need to re-add it?
 - My log is not thread safe yet it is being called from multiple threads.
 - RTTI:
     When defining RTTIType like so: 
      RTTIType<D3D9HLSLProgram, HighLevelGpuProgram, D3D9HLSLProgramRTTI>
     I need to make sure that HighLevelGpuProgram class has valid RTTI type as well. Otherwise the inheritance hierarchy will not be correct. Right now this isn't checked anywhere.
 - Make sure that I am able to blit contents from render textures on all render systems
 - Command buffer:
   - Make CommandQueue not use mutexes and use atomics instead??
   - Figure out how to handle accessing texture from a non-render thread?
   - When importing a resource, and registering it with Resources I don't think it properly gets added to the loaded resources array? For some reason shaders get created twice.
   - Doing setPixels_async in the texture doesn't make sure that the user doesn't actually modify the provided PixelData after that call.
   - In general I need to rethink how to handle modifying resources with multithreading
 - Closing down a window (any window) will shut down main rendering loop
 - GUIManager draw call merging:
    I merge two GUI elements if they don't overlap each other, however I don't consider if there is some world geometry between them. Another reason to move batching out of GUIManager.

----------------------------------------------------------------------------------------------
Low priority TODO
 - Mesh loading:
  - Sub-meshes aren't being transformed by world matrices of their nodes
 - Remove template from RTTIType and move it to IReflectable? This way i can hopefully move GetRTTITypeStatic and GetRTTIType to IReflectable so I don't
   need to manually implement those for every method.
 - Viewport needs to be updated when I call RenderTarget::setFullscreen/finishSwitchingFullscreen/updateWindowRect/windowMovedOrResized. Currently it's not
 - D3D9Texture::createTextureResources is commented out at the moment. It gets called on device reset, and at that point I should reload texture resources.
  - I should probably keep all resources by DX managed. OpenGL apparently keeps a mirror of all its resources anyway.
 - Device reset and resource re-loading in general
 - Fix up WorkQueue as it doesn't lock when initializing, to make sure threads are actually started before returning
 - CPU reading or writing to a render texture in OpenGL is not supported. (CmGLHardwarePixelBuffer::upload/download). 
 - When saving a resource, make sure resource is properly loaded before saving
   - Add doc to Resources::save that says it will block until render thread updates the resource
   - Add documentation that tells the user that reading a resource non-async will block the thread and execute all queued render commands first
   - Remove Response handlers from Resources
- Cg doesn't work. Either remove it or get it to work
- System is not yet ready for multiple rendering contexts
- When serializing/deserializing derived classes, deserialization is done from most derived to base, while it should probably be done the other way around.
- 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)
  - Arrays of objects aren't supported in HLSL or GLSL because of limited GLSL introspection
    - I might need to add an exception thrown if user tries to use them
  - Structs aren't supported in GLSL for introspection reasons
 - Go through pixel formats and removed unused ones: L8, L16, A4L4, and many others
 - Having shared_ptrs used in RenderSystem and CommandQueue can cause potential performance problems. Dozends of thousands of shared
    pointers may be getting queued in command queue per frame, in a slightly more complex scene, which will most certainly cause performance problems
    due to thread safety and atomics used by shared_ptr. However I still need some guarantee that objects queued in RenderSystem won't be destroyed
	by the sim. thread.
  - A way to bind buffers to a Pass, while specifying buffer range
  - Better creation of PrimaryWindow
    - RENDERWINDOWDESC accepts a "externalWindow" flag and an "externalHandle" so when creating the primary window with RenderSystem::initialize we don't always need to create a new window
    - Actually new OpenGL seems to support creating context without a window with the help of wglCreateContextAttribsARB and wglMakeCurrent:
  - OpenGL render window no longer looks for a monitor index
  - Material RTTI should also serialize shared buffers (they need to be made into a resource)
    - BE CAREFUL on how this will be implemented. Likely it will have much of the same interface as a material and/or GpuParams
  - Mesh::setMeshData is currently always synced
  - queueGpuCommand is handled weird. shared_ptr isn't used for setting (this) parameter, and could be optimized out by the compiler
    - test if everything is okay in release mode
  - Resources::unload will deadlock if the resource isn't being loaded!
    - Maybe re-think how I handle ResourceHandle.isCreated?
  - Check D3D9/D3D11/GL resource usages. DX11 reports many unreleased objects. I'm guessing DX9 will as well. Not sure how to check OpenGL.
 - Shared GPU buffers
   - wouldn't work atm due to the way I update the buffers (and the way I mark them dirty)
   - Material::setParamBlock is commented out
 - onMovedOrResized is still used by Viewport while that same callback is offered by RenderWindowManager. There is no need to have them in both places.
 - Texture "ScaleToFit" will cause the texture to repeat instead of clipping the image. e.g. a 50x20 texture placed on an 50x100 area will repeat 5x

----------------------------------------------------------------------------------------------
Optional:
 - Need better handling for shader techniques. Some Materials are able to run on all renderers yet I can only specify one. This is problematic
    for Materials for things like text and sprites, which should run on all renderers, even if user adds a new one
 - Add precompiled headers to all projects
 - Serializable callbacks can't be null otherwise compiler complains
 - FBX importer can be greatly sped up by implementing a better allocator
 - Extend texture copy so it accepts different subregions & subresources (currently only entire resource can be copied)
 - Need a way to convert MSAA render texture into a normal render texture
 - Vertex buffer start offset is not supported when calling Draw methods
 - When rendering Scale9Grid GUI elements the stretched center will cause linear interpolation to kick in and blend the edges with the border parts of the texture.
  - I should use point filtering for scale9grid, but that doesn't work in general case for stretched textures as they would look bad