Jump to content
  • Advertisement
Sign in to follow this  
polyfrag

Multithreaded drawing and logic

This topic is 2039 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've separated the drawing and the sim logic of an RTS into two threads.

 

The problem is updating unit drawing position. The drawing framerate might be lower than the sim framerate, but the sim must be kept at 30 FPS. If I use a mutex with infinite wait time, that essentially slows down the sim to the same framerate as the drawing thread?

 

Is there a simple solution?

Share this post


Link to post
Share on other sites
Advertisement

I am trying to understand your problem first, which is a little bit difficult because I don't speak english very good (ironically for a software engineer).

 

> When I got it correctly you have multiple threads which are not independent from one another which is propably an artifact from your design decision to program it at the beginning as a single core game.

So to sinc them you could let your drawing thread wait in an endless loop to be invoked by the sim thread using a simple boolean or vice versa. So they would run both at the same time but one thread would wait for the other to finish.

 

> Your exact problem is that you have problems updating your unit drawing position. This is strange because shouldn't the position of your object be computed in your sim-thead?

 

You should maybe provide more information what your issue exactly is.

I personally can't really locate the problem.

What happens when the drawing framerate is lower (or higher(?)) then the other thread?

Share this post


Link to post
Share on other sites
The problem is if I'm updating the unit position in the sim thread at the same time as I'm reading that position in the draw thread, it crashes.

What I'm thinking of doing is adding a render-state class to each object that gets update only if the sim thread can get a mutex lock. Otherwise it doesn't wait for it and the draw thread draws at a stale position or a unit at a different frame or something.

Share this post


Link to post
Share on other sites


The problem is if I'm updating the unit position in the sim thread at the same time as I'm reading that position in the draw thread, it crashes.

 

Thats why Hodgman suggested multiple buffers, you update one of them while drawing from the other. After both threads have finished, you swap the buffers and repeat.

Share this post


Link to post
Share on other sites

I see. That's what I'm doing. It's making my code ugly though, and I don't know if I will benefit. 

 

There's problems with multithreading for me

 

- must set all the render-state buffer variables for each object each sim/update frame, wasting cpu cycles, insteading of just setting what changes

 

For example, for a building here are all the variables that are relevant to rendering:

	class RenderState
	{
	public:
		Vec3f drawpos;
		int type;
		int stateowner;
		int corpowner;
		int unitowner;
		bool finished;
		int pownetw;
		int crpipenetw;
		list<int> roadnetw;
	};

Is it worth it?

 

[edit] It's probably too much copying because entire vertex arrays might change during a frame.

Edited by polyfrag

Share this post


Link to post
Share on other sites
Another option is to change your threading model. You could run your update phase in a multithreaded fashion, using worker threads to update multiple groups of entities at the same time. Then if it's time to render the scene, create all your draw calls (also could be done in a bunch of worker treads) and send them off to the gpu.

Cheers,

Bob

Share this post


Link to post
Share on other sites

 run your update phase in a multithreaded fashion, using worker threads to update multiple groups of entities at the same time

 

The result of one unit's update might depend on another, so this isn't a solution for lockstep multiplayer games.

 

 

 

create all your draw calls (also could be done in a bunch of worker treads) and send them off to the gpu

 

Sending them off to the GPU in each worker thread? They share the same GL context and would have to constantly switch with wglMakeCurrent. Plus what if they require different shaders?

Share this post


Link to post
Share on other sites

I've decided that there's too many problems with multithreading, so I'm going back to single-threading. Mutex locks everywhere, not knowing if I might be missing one somewhere...

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!