pygame and socket.recv
castironpi at gmail.com
Thu Apr 2 03:45:08 CEST 2009
On Apr 1, 8:28 pm, Tim Wintle <tim.win... at teamrubber.com> wrote:
> On Wed, 2009-04-01 at 17:58 -0700, Aaron Brady wrote:
> > I tried writing a small game on a pygame layer. The graphics are
> > fine, and at the moment, it is not graphics intensive. It is multi-
> > player, and for the communication, I am sending a pickle string across
> > a LAN, once per frame.
> > I'm observing some latency. It seems that socket.recv isn't
> > performing consistently.
> Not sure I understand the question, are you blocking for the data to
> come down the network before rendering the next frame?
> For game programming I've always used select with non-blocking sockets
> to receive data - and kept the transmissions to UDP to save time
> (obviously you have to expect some data to be lost). Wire time is always
> going to have too much latency for a message to be happily passed within
> the time it takes to render a frame.
> For syncing time I use a really simple algorithm - both machines send
> each other their local [game] time every few seconds, and if the
> received time is ahead of the local time then the receiving machine
> updates it's time to match - that way they are always out by at most the
> shortest time it takes for a packet to travel from one to the other.
> Tim Wintle
My game loop looks like this:
poll events, get 1 at most
send to server
wait for server reply
render entire frame
Yes, I am blocking for the data to come down the network.
Unfortunately, if I use any "prediction," I will have to go back and
un-render the previous frame, then redraw with the new information.
40 transmissions per second in each way can't be too much to ask, it's
just that they have to alternate, up one, down one.
I don't understand your solution. I can't picture it for my favorite
RTS game or the one I'm writing. Are you saying that the slower
machine just jumps ahead, and its user just doesn't have the
opportunity to make moves on the omitted frames?
I am using TCP, socket.SOCK_STREAM. UDP is a potential solution, but
it still doesn't fix my main loop.
More information about the Python-list