Checklist/Idea for renderer cleanup

[KevinW1998]

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 to RenderOp?

[Bluenaxela]

• 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.

[KevinW1998]

• 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