Multithread rendering

using symetrical threads degrades the performance as the threads are competing to access the device.
you can use a thread for each separate task, for example thread for input, thread for rendering and so on, but not more than one thread for rendering.

Quote:

Original post by Fruny ... but OpenGL itself is not designed to allow multiple rendering threads ...

Isn't this the Direct X forum?

In any case, Mason McCuskey has an article on gamedev that mentions mouse rendering in a separate thread.

Quote:

Original post by SiCrane Quote: Original post by Fruny ... but OpenGL itself is not designed to allow multiple rendering threads ... Isn't this the Direct X forum?

I'm tired...

There was an opengl forum question just below it.

I think I'll just delete my post.

Well, the OP never mentioned OGL...but anyway.

If you're polling the mouse in a seperate thread, and updating the position there, it shouldn't matter how high or low your frame rate is. Yes, your mouse may suddenly jump from one side of the screen to another if your frame rate is really low, but if your frame rate gets that bad you've probably got bigger problems than the mouse moving oddly.

You don't want to actually have 2 seperate rendering threads. One thread that updates things, and another that renders is the way to go.

Just keep in mind that if the "update" thread ever has to change data used by the "render" thread (such as rewriting a vertex buffer), it would be most prudent to set some sort of flag that "pauses" the rendering thread (I HIGHLY doubt that your video card will like it if you try to overwrite a vertex buffer that it's in the middle of drawing with).

Thanks for the help. Probably saved me days of banging my head against the wall.

v1nd1cat10n