Re: [Algorithms] Detecting a breakpoint, Was Re: Network clients running at different rates (Was: Re: 60hz is the holy grail)

[Alen L. <ale...@cr...>]

Just digged this from the dust...

> In fixed timestep we can notify the server of a breakpoint on one machine
> and give it the packet id last received and it can stop all clients and
> put them into step mode.

How do you do that trick? Is there some independent process running as
watchdog, or what?

Thanks,
Alen

P.S. I aploogize in advance if this may appear twice, I had some problems with
my mail reader.

> ----- Original Message -----
> From: "Brett Bibby" <res...@ga...>
> To: <gda...@li...>
> Sent: Monday, August 18, 2003 04:37
> Subject: Re: [Algorithms] Re: Network clients running at different rates
(Was:
> Re: 60hz is the holy grail)
>
>
> Alen, how are you handling variable timesteps and your debuging?  When we
> first implemented variable timesteps figuring out the correct step during
> debug sessions was a nightmare (starting/stopping internal timers to keep
> track of the real timestep due to breakpoints and then resuming many seconds
> later).  It wasn't worth the effort we thought, but is there some easy way
to
> handle this we didn't think of?  We could never figure out how we would keep
> the variable thing working, especially for networked games.  In fixed
timestep
> we can notify the server of a breakpoint on one machine and give it the
packet
> id last received and it can stop all clients and put them into step mode.
We
> can then start/stop the game to check data and problems.  Not sure how we
> could do this with variable steps.
> Brett
>
> ----- Original Message -----
> From: "Tom Forsyth" <tom...@bl...>
> To: <gda...@li...>
> Sent: Monday, August 18, 2003 4:13 AM
> Subject: RE: [Algorithms] Re: Network clients running at different rates
(Was:
> Re: 60hz is the holy grail)
>
>
> > > From: Alen Ladavac
> > [snip]
> > > Yes, on a PC, driver will smooth this up for us by buffering
> > > frames. On a
> > > console, there is not enough memory to buffer frames, aside
> > > from what you
> > > get with double buffering.
> >
> > On consoles you usually get a lot more control over exactly when you
> > flip and how long you have before you need to flip. So it's not hard to
> > either drop the Vsync if you really are taking an average of more than
> > 16ms (i.e. all the timeslicing in the world isn't going to help - you're
> > just doing too much per frame - better to go to 55fps and tear slightly
> > than drop to 30fps), or you can timeslice and know fairly precisely when
> > you have to stop processing gameplay and flip&render.
> >
> > > What we need is a solution that
> > > fits consoles as
> > > well.
> >
> > I think you will still have two solutions. The PC gives you much less
> > control, but buffers stuff up for you and lessens the problems as well.
> > Which is lucky :-)
> >
> > > Distribution of processing of one tick among several frames
> > > helps with that
> > > problem, but it creates another bag full of problems. Yes, we do have
> > > separate positions for simulation and separate for rendering,
> > > so we can
> > > interpolate. But it would need more than that. Interdependent
> > > objects can be
> > > created and deleted between ticks, like a rocket disappearing and an
> > > explosion appearing. If you cut it at the wrong time you'll
> > > get a frame
> > > without both of them. Etc, etc.
> >
> > If you make sure you handle all outstanding create/delete "requests"
> > before stopping to render a frame, that should fix it. Even better,
> > unless handling objects is deliberately ordering within a gameplay tick,
> > handle all deletes and creates first. You have surely got to be able to
> > do that in under 16ms!
> >
> > > Besides all the complications usually involved with timeslicing an
> > > inherently single-threaded algorithm,
> >
> > It's still single-threaded, it just gets interrupted.
> >
> > > how exactly should we
> > > determine the
> > > right time to stop simulation and start rendering? One
> > > solution would be to
> > > always spend the first part of the frametime on rendering
> > > then queue a swap
> > > and spend what's left until a vblank for simulation. But
> > > finding out when a
> > > vblank will occur on PC.... you know that's not possible for
> > > a generic case.
> > > And trying to guess it by using a blocking Swap() fails
> > > because, ironically,
> > > the driver buffers frames. :/
> >
> > But you don't have to do this on a PC - it's buffering frames for you.
> > Just vaguely right is good enough - use timeGetTime() :-). And on the
> > consoles you can know exactly how much time you have left before a
> > flip&render.
> >
> > > Anyway, in my opinion, why "having a timestep that is fixed,
> > > but different
> > > than frametime" doesn't work is: if you need to keep it at
> > > 60fps, it means
> > > you need to keep the worst case at 16ms. So it is best to set
> > > it up so that
> > > the frames are as similar as possible. Having some frames
> > > very fast is of no
> > > use if others are slower on account of that. Also, when
> > > running on the PC,
> > > sometimes users easily force their machine into low
> > > framerates. In that
> > > case, fixed time step hammers the CPU even deeper, while
> > > variable timestamp
> > > scales linearly. To put it in other words: it is much easier
> > > to cause "the
> > > spiral of death" with fixed timestep, than with variable one.
> >
> > Not sure why the spiral of death happens on low framerates - you mean
> > when a user turns on FSAA and 16x anisotropy and 2kx2k textures and so
> > on, yes? So you just render fewer frames per second. Your simulation
> > isn't taking any longer, you just have more steps per rendered frame. If
> > anything, it's now smoother :-)
> >
> > > Well, seems like I have a very opinionated stance against the fixed
> > > timestep. :) Perhaps some of you have had more positive
> > > experiences with it?
> > > And what about variable timestep?
> >
> > That's the thing - all the above sounds slightly complex I admit. But
> > the alternative is variable timestep, and that's just awful. Every
> > project I've been on with variable timestep has suffered horrible
> > problems with staibility and predictability, reproduction of bugs,
> > collision, etc. It's a complete mess, and it's twice as bad if you're
> > trying to do stuff like accurate physics.
> >
> > So yes, I have very strong feelings about variable timestep. :-)
> >
> > > Alen
> >
> > TomF.
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> >
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>