Original Post
I am engineering a scripted game engine and plan on using threads. As such I am at the point where im designing memory storage and that is where my problem resides. I want my graphics componant to have full access to the current "frame"s information as far as position orientation and states. But I also want the physics, animation, ai and input/controllers (which all seem to need to work in concert) to be able to run while the graphics componant sorts, culls, switches states and calls draw. My first instinct is to just have the same information stored in two states kind of like blitting, ie: CurrentRenderFrame, ProcessingFrame <- swapping when graphics and everything else sync up. I realize that syncing breaks one reason to thread an application but due to memory limitations I think its the best way for game like applications where actions are heavily dependant on each other. I would love to have some criteques and comments on this idea and maybe some radical other ways of doing it. If you need anymore information or clarification on the issue please say so, I really want to think this through all the way lest I be waisting implementation time.