On Apr 2, 4:13 am, Tim Wintle <tim.win...@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. -- http://mail.python.org/mailman/listinfo/python-list
