pygame and socket.recv
castironpi at gmail.com
Sun Apr 5 04:11:59 CEST 2009
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.
> 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:
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.
More information about the Python-list