René Dudfield <[EMAIL PROTECTED]> said: > Iterating it at eg. 72fps means that the quickest data can go out is > at 1/72 messages per second?
You probably don't mean this - 1/72 messages per second is awfully slow. What I've done in situations like this before is to create an outgoing message queue - as my game loop generates information that needs to go out on the wire, it gets added to the queue. Then, after the game update, I do my network "housekeeping", which sends each message from the queue out over the network. I also spend that time to pull all waiting traffic in off the net - could be zero, one, or many messages waiting to be processed inbound and outbound. > If you don't have a consistent frame rate, say a frame too 1/14th of a > second because of some heavy graphics - then messages would only come > out every 1/14th of a second. Yeah, providing a queue permits spiky circumstances to be handled as soon as possible - though you may decide to limit the amount of traffic to move in or out. For example, if you get a LOT of network traffic all at once (a new player entering the game, sending out a lot of initial state information in a short period of time), it's possible that processing all of the waiting network messages in one frame could take too long, causing a visible frame rate drop. So, instead, you might wish to choose a maximum number of messages to process per frame. > Whereas if you ran twisted in another thread it would be separate of > those concerns - and could run at a different frequency. Maybe a > lower frequency even. Yeah, the idea is tempting, but I'm nervous about multithreading, particularly making sure the threads communicate correctly. There are a number of approaches to getting that right (mutexes, lock free algorithms, channels), but that sort of thinking hurts my brain, and I write games to have fun. So I avoid threads unless they're far and away the best choice for the job. > As a bonus all your networking stuff can be handled by a separate > CPU/Core if available. That would be nice, but with current versions of Python (anything with a Global Interpreter Lock - see, for example http://docs.python.org/api/threads.html ), you're not going to get much concurrency on multicore machines. I'm not sure, maybe there's some benefit to be had with low-level networking I/O being processed independently, but the python code will all be serialized (i.e. not concurrent) because of that GIL. If multithreaded Python networking really excites you, I suggest you take a look at http://www.stackless.com - a modification of the Python interpreter which permits a lot of stuff that I find fascinating, but again, makes my brain hurt, so I've almost never tried to integrate the ideas with game development. I'm not saying threads can't be used to good effect, they just require my brain to stretch in ways it's not comfortable with. If they work for you, that's great. -Dave LeCompte