BansheeEngine/TODO.txt

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

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
 - Resizing from the top doesn't work
 - Resizing from the left actually resizes the right side
 - 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

Over the holidays:
 - Profile code to see why it runs to slow in debug (AQTime probably)
 - Window docking/undocking

IMMEDIATE:
 - Clicking on a window to focus and immediately trying to drag/resize it, doesn't work. I first need to click, then click again to drag/resize.
 - 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:
 - Key-repeat? Pressing left/right/up/down arrows doesn't repeat the keys (also delete/backspace)
  - Add special text input commands, which will get repeatedly sent as long as their corresponding key is set in GUIManager
 - Get DebugCamera to ignore input if GUI has already processed it
 - Cut/Copy/Paste
 - Clicking on the InputBox doesn't display the cursor. I need to click another time and then it shows up.

 - LATER
  - TAB between input elements
  - Context menu with copy/cut/paste
  - 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

Later add InputMap class in which you can bind certain actions (like move left, fire, etc.) to Keyboard, Joystick or Mouse buttons.

-----------

 - 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)

------------------------------------------------------------------------------------------------
Longterm plans:

<<Multithreaded GUI rendering>>
 - Event handling and normal "update" will still be done on the main thread
 - At the beginning of each frame a GUI mesh update is queued on the GUI thread
 - Since we're queuing the update at the beggining of the frame we will be using last frames transform and gui element states.
   - When queing we need to make sure to store GUIWidget transform, and specific element states (e.g. "text" in GUILabel)
 - At the end of simulation frame wait until GUI update is complete. After both simulation and GUI updates are complete, proceed with submitting it to render system.

<<Figure out how to store texture references in a font>>
 - Currently I store a copy of the textures but how do I automatically update the font if they change?
 - Flesh out the dependencies system?
 - I can import texture as normal, and keep it as an actual TextureHandle, only keep it hidden
   if it was created automatically (by FontImporter) for example?
    - But then who deletes the texture?
	- Set up an "internalResource" system where resources hold references to each other and also release them?
	 - In inspector they can be expanded as children of the main resource, but cannot be directly modified?
	 - Deleting the main resource deletes the children too

<<Window controls>>
 - Create GUIWindowFrame/GUITitleBar control that can be added to the widget
   - it has onMaximize, onMinimize, onClose, onMove, onResize callbacks
    - when window is floating onMove/onResize will resize the actual Window
    - when docked (EditorWindow should know if it's docked or not) it will call back the layout manager
   - (Frame and title bar need to be separate as some windows will used tabbed bar instead of normal title bar)
 - GUITabbedArea that will serve for tabbed EditorWindows
   - GUITabArea allows you to move tabs around, but also dock/undock them if the user drags the tab outside.
 - MainEditorWindow - handled specially, no need for a good interface
   - Keeps a title bar, status bar and a layout manager (i.e. docking manager)

<<MessageBox class>>
 - A good first test case for my GUI windows

<<Other>>
 - GUIManager events
 - GUIElement and GUIWidget "hasFocus" flag
   - Only elements in focus receive keyboard events
 - There is an issue that custom-UIs won't have their mesh shared. For example most game UIs will be advanced and will 
   likely use on GUIWidget per element. However currently I only perform batching within a single widget which 
   doesn't help in the mentioned case.

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

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

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

----------------------------------------------------------------------------------------------
Medium priority:
 - Add a field that tracks % of resource deserialization in BinarySerializer
 - 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

----------------------------------------------------------------------------------------------
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
  - Add GL Texture buffers (They're equivalent to DX11 buffers) - http://www.opengl.org/wiki/Buffer_Texture
  - 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
 - Add support for diacritical marks to the input system (in WindowEventUtilities)
 - onMovedOrResized is still used by Viewport while that same callback is offered by RenderWindowManager. There is no need to have them in both places.
 - Replace list of windows in WIndowEventUtilities with RenderWindowManager list. No need to keep two lists I think
----------------------------------------------------------------------------------------------
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
 - If possible, make sure GLSL uses EntryPoint and Profile fields I have added to GpuProgram
 - Move all x86 libs to x86 folders. Move all binaries to x86 folders as well
 - 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
 - Instead of doing setThisPtr on every CoreGpuObject, use intrusive shared_ptr instead?
 - Renderer::render(CameraPtr) is currently commented out because I moved Camera out of Camelot and I didn't want to bother figuring how to port this
 - 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

 ----------------------------------------------------------------------------------------------
After polish and ideas:
 - Each view (i.e. camera) of the scene should be put into its own thread
 - How do I handle multiple mesh formats? Some files need animation, other don't. Some would mabye like to use QTangent, others the proper tangent frame.
  - Asset postprocessor? Imports a regular mesh using normal importers and then postprocesses it into a specialized format?
 - Load texture mips separately so we can unload HQ textures from far away objects (like UE3)
 - Add Unified shader so I can easily switch between HLSL and GLSL shaders (they need same parameters usually, just different code)
    - Maybe just add support for Cg and force everyone to use that? - I'd like to be able to just switch out renderer in a single location and that everything keeps on working without 
	  further modifications.
 - Port boost threads to std threads (CmThreadDefines.h)
 - Remove HardwarePixelBuffer (DX11 doesn't use it, and DX9 and OpenGL textures can be rewritten so they have its methods internally)
 - Multihead device
 - 3D rendering (use low level hardware methods for it)
 - Don't forget to check out Unity DX11 documentation on how to implement DX11 features (http://docs.unity3d.com/Documentation/Manual/DirectX11.html)
 - Go to Game Engine Architecture book and make a list of Utility systems we will need (Config files, Parsers, File I/O etc)
 - Go to GEA book and read about resource managers before implementing them
   - Actually I should re-read most of the chapers in the book, or all of it
 - When building internal GUI make sure to use CEGUI as a reference
 - OpenGL non-Win32 window files haven't been properly parsed or tested
   - Since I probably can't compile them, try adding them to VS and see what intellisense says?
 - Textures and all other buffers keep a copy of their data in system memory. If there are memory constraints we might need a way to avoid this.
 - Move all multiplatform files (window creation, cursor, etc.) into a separate PlatformSpecific folder. So anyone porting it to a new platform
   knows that he only needs to change those files.
 - Make sure my Log system uses XML + HTML