Question

Hokay so here is what I'm trying to accomplish:

I'm going to be sending some mesh data over a network that my render-er (programmed in XNA) must render. For those not familiar, a typical XNA "game" basically runs in a continuous thread... which updates and draws your data. The problem is, I don't want to slow this thread down by having to de-serialize the network data (it would decrease my framerate). So, I'm thinking I need a thread which listens to the network connection, de-serializes the packets into something the game can use, then alert the XNA thread that the data is ready to be rendered. This way, if there is lag or whatever over the network, my rendering is in sync with the network data.

Now then, I'm familiar with basic threading principles, however I'm wondering if anyone has done this before and what I can do to design/implement this thing? I need to keep the threads separated (that is, the XNA thread can not start executing the listen thread code and vice versa). I'm thinking this is essentially a producer consumer problem, however if anyone could give me some .NET/XNA code (or pseudocode) which outlines the synchronization I need that would be much appreciated.

Feel free to ask for clarification... I'll try to edit as needed.

Was it helpful?

Solution

The draw method in XNA is run as a separate thread that is constantly run. So basically it should just be a matter of writing the new mesh into drawn objects which the draw will render next pass, else if new data not yet available it'll just render old meshes instead.

This does away with the need for synchronization with the actual render as it'll probably be rendering faster than you update those variables anyway.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top