Jump to content
  • Advertisement
Sign in to follow this  
agaudreau

Threaded memory use

This topic is 3404 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by agaudreau
My first instinct is to just have the same information stored in two states kind of like blitting, ie: CurrentRenderFrame, ProcessingFrame <-

Yes. Old state is being rendered, while logic reads from old state and writes into new state. Then states are flipped.

Quote:
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.


This doesn't require sync, only a way to determine when all handlers for current frame have completed, so you know where to flip.

Share this post


Link to post
Share on other sites
Thanks for the reply, this problem has been the bane of this project for a while now.

I dont like the idea of having twice as much data for objects but I guess there isn't a good way around it if I want to implement threads the way I want.

Share this post


Link to post
Share on other sites
This doesn't require sync, only a way to determine when all handlers for current frame have completed, so you know where to flip.[\quote]

Are you sure? I dont want to flip the memory "buffer" if the rendering is not done or if the other activities are not done either. So I would have to wait for both threads to be complete before swapping (syncing yes?). Otherwise the rendering would be not always rendering the same "frame"'s data right?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!