ddfreyne wrote:

The game loop example you posted doesn't do this. It couples state updates with redrawing as tightly as possible: the frame rate is fixed and that the game speed is the same as the redraw speed. With such a game loop, naïvely getting rid of the 30 frames-per-second cap would mean that the game could suddenly run twice as fast, or even shift between half as fast and twice as fast or so (I am already getting motion sick ).

Actually, the game loop posted takes the time difference into account, and uses that in the update calculations... therefore the frames-per-second can vary, but the animations, physical movements, etc will be adjusted to how long its been since the last call.

Edit:

Unless you are referring to the fact that the Physics/states are dealt with 'in the game loop' at all, as opposed to being dealt with separately in another thread which the game loop only queries when its time to redraw. Of course, that brings into it all kinds of fun with threads and volatile data, and can potentially make things distinctly unstable - not to knock it though, well-written multi-threading such things to keep them separate can given many benefits.

I guess the Physics could be done in another thread and then feed the resulting data into shared objects.

I tried something similar to this a while back and it made odd hiccups because the render-loop would come across locked mutexes and would have to wait for them to be unlocked.

I've found changing the rate objects move based on the frame-rate to be the best. You get a timefactor which you can multiply with, say, a constant speed in the X axis to get constant motion in the X axis for instance. This way you can code all your motion stuff as if your framerate updated at a constant increment of 1 frame per <take your pick of units>.

Mmm... should've named the TimeSinceLastUpdate var: TimeFactor (like it is in my actual code).

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

Last edited by Lontahv on Sat Jan 24, 2009 12:18 pm; edited 1 time in total

Lontahv wrote:

I've found changing the rate objects move based on the frame-rate to be the best. You get a timefactor which you can multiply with, say, a constant speed in the X axis to get constant motion in the X axis for instance. This way you can code all your motion stuff as if your framerate updated at a constant increment of 1 frame per <take your pick of units>.

That seems to be the way a lot of it is done... certainly to the point of it being the standard way most games-development platforms (and tutorials) [that i've come across] tend to provide.

I think the question ought to be, do we remove the FPS limiting totally (letting the cycles run as fast as they can on the hardware provided) or do we just consider upping the fixed time-cycle (60 may be a good option) - obviously still taking into account time-step, so if the game-cycle(fps) does get bogged down, it'll take it into account.

Of course, maybe we ought to be thinking laterally, and tryingto decouple as much as possible from this loop, but some things are going to be inevitably bound to it, and if we aren't careful, we may end up essentially re-writing the Engine from the ground up.

Read this for some good articles on the subject, in particular the Fix Your Timestep one.

Do we know what the effect is on timed animation puzzles such as the Gahreesen gear room? If the puzzle timing itself is frame based (which I consider unlikely) it will become impossible to solve. If the puzzle on the other hand has a fixed time and the animation is frame based won't they go out of sync?

_________________
D'Lanor (ɹǝʇunч puǝƃǝן uɐqɹn)

♪ KI# 33949 ♪

Christian Walther wrote:

Read this for some good articles on the subject, in particular the Fix Your Timestep one.

Good articles, and I note there is a Networked Physics article there as well, dealing with prediction and other techniques for dealing with lag. Gahreesen is one example of where lag and physics can really foul up a puzzle, but as (hopefully) our FCAs develop in quality and cunning, it could be something we run up against more and more.

A common game-time clock is essential in a multiplayer game. If Uru isn't using a global clock it's one of the first things we should look at implementing.

_________________
Can you withstand the gaze of the Eye of Eternity?

Being a mathematician, I can't resist pointing out that while having your physics engine timestep dependent on the framerate means that the game can maintain a consistent speed as the framerate varies, the accuracy of the physics engine will suffer greatly when the framerate drops. This can be quite bad for puzzles that depend on precise timing or movement. A prime example of this would be Eder Kemo and Eder Gira, where the puzzle that requires the most precise movement also makes the most use of dynamic lighting in the game. Since multi-core processors are now more prevalent than discrete graphics cards, it makes the most sense from an architectural perspective for physics and graphics to be in different threads with different timing, so that quality of physics can be maintained even when the quality of graphics must suffer.

isomorphic wrote:

A prime example of this would be Eder Kemo and Eder Gira, where the puzzle that requires the most precise movement also makes the most use of dynamic lighting in the game.

I ought to point out at this point that dynamic lighting is not a physics-engine calculation, its done purely on the GPU (or CPU if lower end cards are catered for). Just a minor correction. Although obviously it needs to know where to 'generate the lighting effect', where Gira/Kemo are concerned, the effect is only around the visible avatars, so the lighting effect will be visible correctly around the avatars (and influenced polygons) in the client, even if the physics is lagging behind.

That said, your comment about dealing with actual physics calculations is correct up to a point - hence using various methods to cater for and (in multi-player environments) semi-predict positions, bearings, and accelerations, to get the best match of location you can, even if it's not perfect visually (as long as it ultimately ends up corrected to the right positions when it counts).

D'Lanor wrote:

Do we know what the effect is on timed animation puzzles such as the Gahreesen gear room? If the puzzle timing itself is frame based (which I consider unlikely) it will become impossible to solve. If the puzzle on the other hand has a fixed time and the animation is frame based won't they go out of sync?

Both the animation and physics are time-based, (think about the frameTime value in the keyframes) and based on the python, the puzzle's timing appears to be controlled by the state of the animations (they can be flagged to call back when they finish or reach certain markers) rather a separate python timer.

_________________
Live KI: 34914 The Story So Far
Again KI: 23247

SCGreyWolf wrote:

A common game-time clock is essential in a multiplayer game. If Uru isn't using a global clock it's one of the first things we should look at implementing.

Agreed. We can also talk about having different timesteps for clients, working in concert with other client-side prediction, but it all needs to "snap into place" with server updates.

This of course leads to jitters and zooming avatars in extreme lag situations, but there's never been a fix for that. Better than "cannot move" lag.

I think the components, in rough order of importance, will look like this:

Server:
-Consistent server update rate ("tick rate" in FPS parlance) sends updates to clients regularly, timing out clients after a set interval without any response. Server runs physics.

Client:
-External, to server: Sends attempted movement vector to server as often as possible (not framerate limited, but limited first by the server and then by bandwidth), server returns whether this is allowed or not by updating the client's position. Sends / receives special non-movement commands like world interaction, emotes, chat / voice strings / data. Always allowed except for certain situations and perhaps limited in number of updates per time period (to prevent various forms spamming)

-Internal: Attempts to predict position of clients based on their last known position. Updates with "solid" information from server when given. Not synchronized: All ambient animation, ambient sound and music (non-puzzle? Is there any call for having synchronized music or ambient sound? I could see its use in puzzles actually, but it would definitely be an unusual feature, and I think most will make happy with the usual stuff triggered by events i.e. touching a cloth) and visual effects.

Nadnerb wrote:

Both the animation and physics are time-based, (think about the frameTime value in the keyframes) and based on the python, the puzzle's timing appears to be controlled by the state of the animations

If the time is centrally controlled - and I can't imagine why it wouldn't be - that seems like a sensible solution to the issue. Folding the issue of the timing into the animation design of a puzzle probably helped the designers all stay on the same page about what was happening, and allowed artists to rapidly develop a workable mockup of any given puzzle. Of course, the Garden Age introduced in the GT beta was notoriously buggy, so perhaps there were gaps in the implementation, or perhaps the artists were having trouble debugging the puzzles. It doesn't seem like it's a bad idea though.

Rusty_Russell wrote:

I have to admit to being slightly amused at this discussion. When I was in Prologue on my Ge Force 4 Ti 4600 I had an fps of oh... about 7 .

Wohba. If that's not too much of an exaggeration, there must've been something else wrong with (or underspecked in) your computer. I ran Uru from the earliest on a GeForce 4 Ti4200 with a 2 GHz Pentium 4 and it did just fine in the frame rate department.

Actually, I lied. From the very earliest I used a GeForce 2 MX on a Pentium III 800 Mhz or so. I probably did get literally 7 fps in Teledahn with that bad boy. Couldn't run up ramps, stairs, or the sewer pipe until I upgraded.

Not an exaggeration. I can't remember the processor chip at the time though.