Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualphayer

Posted 19 March 2014 - 02:41 PM

Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.

 

The interesting part is what you do with that data inside the game.

 

Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;

 

Network thread --

Lock incoming queue and write to it, then unlock

Lock outgoing queue and send packages, then unlock

 

Game thread --

Lock outgoing thread and write to it, then unlock

Lock incoming queue and read from it, then unlock.

 

Just to minimize locking. Probably not perfect, but it works so far and I'm happy.

 

 

 

If any of you have any experience regarding entity-component-systems and how to integrate network to them easily while still keeping them flexible/extendable, the whole point of a entity-component-system, then please drop by in my other thread.


#1phayer

Posted 19 March 2014 - 02:40 PM

Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.

 

The interesting part is what you do with that data inside the game.

 

Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;

 

Network thread --

Lock incoming queue and write to it, then unlock

Lock outgoing queue and send packages, then unlock

 

Game thread --

Lock outgoing thread and write to it, then unlock

Lock incoming queue and read from it, then unlock.

 

Just to minimize locking. Probably not perfect, but it works so far and I'm happy.


PARTNERS