pygame and socket.recv

[Aaron Brady]

On Apr 2, 4:13 am, Tim Wintle <tim.win... at teamrubber.com> wrote:
> On Wed, 2009-04-01 at 18:45 -0700, Aaron Brady wrote:
>
> > My game loop looks like this:
>
> > poll events, get 1 at most
> > send to server
> > wait for server reply
> > render entire frame
>
> The look I'm suggesting is:
>
> poll events
> write to (non-blocking) socket
> render frame
> check non-blocking socket and add events to the event queue
>
> > 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.
>
> Sounds like that may have to be re-factored slightly, afraid this is why
> real-time networked games are tough to make.
snip

> a) How much to move etc. is decided based on some real-time solution
> (not on the number of frames). Ideally all movement methods take a
> parameter that is a delta in time. (i.e. 1/40th of a second)
>
> b) That time is the time that is synced across machines - if machine B
> has to put it's timer forward 1/50 of a second, you call all the methods
> above with a timedelta of 1/50 before continuing.

Tim Wintle's link has an interesting illustration of this:

"""
Basic Concepts
The Update Loop

For example, Doom's movement physics looks like "Position +=
PositionIncrment" while Unreal's looks like "Position += Velocity *
DeltaTime". This enables greater frame rate scalability.
"""

... Perhaps you've heard of him.