[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Direction of Linux games...
>What I don't get is why people support variable framerates when
>there's a multiplayer possibility -- and currently there is with
>about every new game. If you're writing physics to progress with
>the framerate, then won't you run into problems when you try to
>purge a simple client/server model out of it, where the server
>runs at a fixed 20 Hz or something ? Granted, it's easier to
>fit a fixed timestep into variable code than vice versa, but why
>bother, usually single player games are implemented as
>"just one client C/S with server running on client machine", ie
>local loopback, right ?
>Unless you can draw interpolating frames that will indeed give
>you jumpy frames (temporal aliasing, basically), but at least
>the game will progress at fixed rates (ie you have 20 hz because
>that's how the server ticks, not because of refresh rates)...
Weeeellll... the last C/S game I coded, the server ran as fast as it possibly
could, and did variable step universe updates, ramping down that speed as
complexity grew and network saturation approached. Each update resulted in a
series of atomic updates sent to each client - the client database, therefore,
at any time between an update packet is a state where it can be rendered ( it
might have a total inconsistency of maybe 1/20th of a second across the database
is all. ) The clients, similarly, render as fast as they can. The 2D
input/output used to be about 50Hz, the 3D rendering was only about 10Hz
(software renderer, and not a terribly bright one, I was pushed for time).
The server used a buffering database to amplify the data, which was hosted on a
fourth machine ( 2clients, 1 engine, 1 database buffer, all P100s, back then
about the fastest thing you could buy) to prevent the game server having to send
the data to all interested clients (theoretically, the client count could climb
to about 16 without performance degradation in the data systems, but I doubt the
10baseT ether could keep up...) and so the engine used to frequently top 100Hz
updates to the universe. Which I considered fast enough.