Hey folks, I'm working on a (very basic) rendering engine for a game, and have come across a snag. The issue is as follows: I want to make a RenderBuffer that keeps track of every renderable object, and lets each object render itself to the window in turn. However, to keep track of these objects the buffer needs references to them. These references need not be mutable, but this still conflicts with the fact that these objects (such as the Player, Terrain, etc) may have mutable references elsewhere. Is there a better way to take care of rendering, or some kind of workaround? Maybe the RenderBuffer should grab copies of the objects each frame instead of references? (though seems highly inefficient).
Don't share references around. Have a struct that owns both the objects and the systems (RenderBuffer and anything else that uses the objects). Then for each system you take references to the entities as an argument, rather than storing them all the time.
This may seem annoying at first, but it's great for keeping your architecture modular, and will save a lot of pain in the long term.
A downside of this of course is that you can't process different systems in parallel, but for most non-AAA games this isn't much of a problem.
Hello,
It may be that copying the data is not so bad after all if you have the spare memory.
Suppose you have a rendering thread which draws a frame and a simulation thread which executes game logic for a frame. The simulation thread can run and then copy all of the data that needs to be rendered into a data structure. The render thread can then consume that data structure and render it while the simulation thread is updating the next frame.
That should give you good performance and allow mutability in the simulation thread while maintaining constness in the render thread.