| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246 |
- ----------------------- CAMELOT 2D / GUI -----------------------------------------------------------
- ----------------------------------------------------------------------------------------------
- When I'm canceling command queue commands I might be canceling important user commands.
- - (e.g. user schedules a resource update and I cancel the command)
- - render commands can be cancelled with no repercussions?
- - maybe I should someone block sim thread if its running too fast?
- - input lag?
- --------
- DebugDraw
- - DebugDraw support for AA lines
- - Add DX9 and GL debug draw shaders
- 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 wait a single frame.
- GUIWidget::updateMeshes leaks. If I leave the game running I can see memory continously going up
- IMMEDIATE:
- - Add window-management command to DeferredRenderContext - I already have resource management commands
- there, few window related ones won't hurt. I can always split the class if needed.
- - Possibly add guards to render target classes so they aren't accidentaly accessed from the render thread (similar to how Texture is handled)
- - 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
- TextBox needed elements:
- - Render element: background texture and a text sprite
- - Keyboard focus: Mouse click gives focus, tabbing between elements gives focus (TODO: explore how will tabbing work)
- - Input: All characters get forwarded to element with focus
- - Input cursor - Mouse click within box moves input, arrow keys move input. If cursor goes out of clip limits, move text.
- - CURSOR needs to flash. Implement it as a GUIManager::showInputCursor(depth, position) method instead of doing it in GUITextBox.
- - Text selection - Shift + arrow keys select text. Mouse drag selects text, and scrolls the text if needed. Text selection is drawn using another single color image sprite. Selection height is determined by line height.
- - Text operations - Select all, copy, paste (using shorcuts, possibly also context menu?)
- - Make sure multi-line text boxes work fine as well.
- Window needed systems:
- EditorWindowContainer
- - TabbedTitleBar widget
- - contains minimize/maximize/close buttons
- - contains window toggle buttons, and in between them invisible buttons that serve as drag drop points and for moving the window
- - dragging the in-between button will cause the window to move
- - droping another window will cause the window to be docked at that location
- - dragging the window toggle button will cause the window to undock. (or if the window is already undocked and is the only one in the titlebar, it will cause the window to move)
- - contains title bar background
- - Window frame
- - contains tiled window background
- - contains scale9grid frame
- - frame allows for resize
- - frame changes color when window is in focus
- - Contents
- - Actual Editor Window with custom contents
- 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
- -----------
- I need to be able to provide smaller bounds used for UI input
- - Add padding - reduces the size of the element and that is used for input
- - Add margins - spacing that is added when laying out multiple controls after each other
- Figure out how to deal with callbacks properly. I recently eliminated them from Input but I'll need them for my GUI elements...
- - How do I implement them? I really don't want to do Unitys approach to GUI
- - If I do figure out a good way to keep callbacks, maybe rethink Input and re-add them?
- - 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 handle onMouseOver, onMouseOut, onMouseDown, onMouseUp events
- - (optional) Implement DirectDraw for drawing the bounds so I know they're correct
- - 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
- ----------------------------------------------------------------------------------------------
- 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.
|