LunaLua
LunaLua copied to clipboard
Checklist/Idea for renderer cleanup
Here is a checklist for cleaning up the Renderer class:
We'll do for sure:
- [ ] Move to smart pointers instead of raw pointers
- [ ] clean up things relating to RenderOp::m_FramesLeft as that's not particularly clean/clear right now
- [ ] Remove some leftover stuff that's in "if (false) {" blocks and unused
- [ ] Move things that are part of the "Render" namespace (as opposed to Renderer class) into their own file
- [ ] Design it to support multiple queues of RenderOps, for supporting multiple layers. Could be something like std::map>. Even if only one layer (HUD) is defined initially it would be good to set this up to support that in the future.
Ideas:
- Move from std::list to std::vector (better performance?)
- Transfrom RenderString and std::list<RenderString> to RenderOp?
- Feel pretty neutral about smart pointers, but they could be okay.
- For moving some things away from std::list, I suggest std::queue rather than std::vector, as that better matches the purpose.
- Might want to clean up things relating to RenderOp::m_FramesLeft as that's not particularly clean/clear right now
- Remove some leftover stuff that's in "if (false) {" blocks and unused
- Move things that are part of the "Render" namespace (as opposed to Renderer class) into their own file
- Design it to support multiple queues of RenderOps, for supporting multiple layers. Could be something like
std::queue<RenderOp*> mRenderQueues[RENDER_LAYER_MAX];
. Even if only one layer (HUD) is defined initially it would be good to set this up to support that in the future.
- Smart Pointers: I tend to use smart pointers for sake of organization
- Container: Probably std::queue is best for the design method. I have read that vectors can have better use of the CPU cache, because dereferencing cost a bit of performance (latency)...
For the other points I totally agree