Thread: theoretical question about c programming

Originally Posted by rcgldr

For example, in the case of Need For Speed Shift, the physics engine always runs at 180 hz

Originally Posted by phantomotap

Really? I had remembered "Need For Speed: Shift" as "clamping" physics to rendering "FPS"; well, "clamped" to "FPS" but with multiple physics passes per frame.

The physics rate of 180hz for Shift has been confirmed by groups of players that have modified the physics of the game. As mentioned before, video frame rate for Shift ranges from 35 FPS to over 70 FPS, depending on a players system and how many cars there are in a race. I recall that NFS2, NFS3, and NFS4 (High Stakes) sampled controller inputs at 32hz, and the physics may have run at that rate or a multiple. NFS5 (Porsche Unleashed) sampled at 64 hz. The video frame rate varied from 40 FPS to over 100 FPS. The physics was extremely consistent: replays simply stored the controller inputs and watching a replay was essentially the game re-running the race, using the stored controller inputs instead of live ones. AI opponent behavior also needed to be extremely consistent. Replays could be exchanged between PC's, meaning that those old games physics were not affected by the PC's as long as some minimal performance rate was met. Toca Race Driver 2 and 3 used the same replay strategy.

Originally Posted by phantomotap

I was thinking of "Need for Speed: Rivals" which, for the PC version I played, was "clamped" to 30 "FPS".

Although the video rate is clamped in some games, the physics rate could still a non-integer multiple of that rate. Usually the clamping just puts a cap on the maximum rate, the FPS may still drop below 30 FPS without affecting the physics.

O_o

Why did you post a response to correct my thoughts when the post went live with an update where I had already said that I had been wrong?

*shrug*

Although the video rate is clamped in some games, the physics rate could still a non-integer multiple of that rate.

[Edit]
(The original segment had a weird feel.)

Most are for exactly that reason. You can investigate this yourself by looking for various games that have community fixes only adjusting the "FPS" limit. You'll see cars turning on a dime. You'll see horses explode into gallop. You'll see a guy swing a massive phallic symbol--a very large sword--at the speed of light.

Seriously, you should watch a few videos of such "glitches" when you have the time; they are great. ^_^
[/Edit]

Usually the clamping just puts a cap on the maximum rate, the FPS may still drop below 30 FPS without affecting the physics.

Well, that is true, but engines that just "clamp" physics, regardless of relationship to rendering "FPS", just give you "jerky" physics with low rendering "FPS".

That is entirely different issue; as much as I hate low "clamped" rendering "FPS", I hate "jerky" physics even more. I don't want to see my car move the equivalent of 150 meters in one second when I've seen only three frames.

Soma

Originally Posted by phantomotap

Why did you post a response to correct my thoughts when the post went live with an update where I had already said that I had been wrong?

That wasn't my intention, and there are cases where the physics rate is tied to the graphics rate, such as consoles which unlike PC's, have a fixed amount of performance, and fixed timers (assuming players don't overclock consoles like a PS3).

Originally Posted by phantomotap

You can investigate this yourself by looking for various games that have community fixes only adjusting the "FPS" limit. You'll see cars turning on a dime. You'll see horses explode into gallop. You'll see a guy swing a massive phallic symbol--a very large sword--at the speed of light.

I've seen some ports of games from consoles to PC's that ended up with physics problems because of tying the physics rate to the graphics rate. Need For Speed Underground 1 as installed from cd rom has a severe form of this problem (game play speeds up if frame rate speeds up), that was mostly fixed in a downloadable patch that was released later on. Other games seem to have some issues with the graphics interfering with the physics engines, but I consider these to be flaws in those games.

Originally Posted by phantomotap

Well, that is true, but engines that just "clamp" physics, regardless of relationship to rendering "FPS", just give you "jerky" physics with low rendering "FPS". That is entirely different issue; as much as I hate low "clamped" rendering "FPS", I hate "jerky" physics even more. I don't want to see my car move the equivalent of 150 meters in one second when I've seen only three frames.

For most games, the physics rate is fixed, while the graphics rate is allowed to vary. A few games will do a type of auto-calibration of the physics rate during installation or perhaps during some type of pre-stage sequence. Once the rate is calibrated, it remains fixed, at least for an entire event, such as a race.

Getting back to the original post, for most PC based games, some type of method to keep the physics from being impacted by the graphics throughput is used, via threading, preemptive event driven code, or round-robin event driven code.

Other games seem to have some issues with the graphics interfering with the physics engines, but I consider these to be flaws in those games.

O_o

Certainly. I surely did not imply that otherwise whatever you may have inferred.

For most games, the physics rate is fixed, while the graphics rate is allowed to vary.

Well, you've misunderstood something in the conversation, quoted the wrong comment, or used "waits in a loop" in a way I did not comprehend.

When you referenced "clamping", or when I thought you referenced "clamping", of the physics engine I suggested that "clamping" just physics wouldn't be enough to ensure consistent physics. The point being, if you are only doing "clamping", the rendering "FPS" needed to be clamped to coincide with physics with modern games--lots of bodies/parts. (Such an approach absolutely does lead to "jerky" physics.) The approach isn't the only way to go, but it is an option a lot of older engines use.

You aren't talking about "clamping" despite giving a "wait" example; you are only talking about "discrete time-steps"--as opposed to "variable time-steps"/"clamped time-steps"--which is a different thing. (Obviously, you may have intended to discuss the approach only for us to misunderstand each other.) You are talking about a physics engine that does use some form of a "accumulation and interpolation" model. With this model, the physics engine is "FPS" governed, but the physics are applied through some form of interpolation/applied multiple times per frame to account for to few or excess rendered frames during a given "time-step".

For example, "Need For Speed: Shift" with physics running at 180hz and rendering running at an inconsistent 47 "FPS" might apply transforms to the schedule:

(The top row represents the 180 transforms; the bottom row represents 47 frames.)

Code:

012345678901234567890123456789012345678901234567890123456789
0123 456 7890 123 4567 890 1234 567 8901 234 5678 901 234 56

The physics transforms are applied 180 times per second, but the "discrete time-steps" doesn't match with frames such that a "wait" will reasonably aline the mechanisms. The physics engine is instead "fed" in "discrete time-steps" which applies excess transforms by "accumulating" transforms over excess frames. (Frame 5 would, for example, see physics as applied from the "missing" frame by the physics engine applying transforms from "time-step" 13-18 before Frame 5 is rendered.) This sort of physics model is smooth over time as unrelated to the "FPS" not by "waiting" on the rendering engine, but by applying physics "regularly" regardless of the "FPS".

Again, you may have intended this sort of physics engine throughout the discussion, but the reference to "waits to achieve fixed frequencies" led me to think you were talking about a different form.

Soma

O_o

I could no longer resist: Skate 3 Funny Stuff Compilation #1 - YouTube (Yes, "Skate 3" has a lot of physics bugs.)

Soma

Originally Posted by phantomotap

"discrete time-steps" ... For example, "Need For Speed: Shift" with physics running at 180hz and rendering running at an inconsistent 47 "FPS" might apply transforms to the schedule

Using Shift as an example the physics engine uses controller inputs, current state of objects, ..., to determine accelerations and then updates objects velocities, positions, orientations, collisions, ... at a fixed 180hz rate. The graphics engine either receives object update messages at 180 hz, or shares a global virtual state of objects that the physics engine updates directly but in such a manner to avoid having partially updated object information during graphics processing (double buffering would work). The end result is some type of shared view of a virtual world that is updated by the physics engine and translated into a graphical view by the graphics engine. Implemented properly, the graphics frame rate can be independent of the physics rate. If an object gets updated during an graphics update, it's usually not a big deal, and most players probably don't bother enabling vertical sync since that usually forces a lower fixed frame rate and/or a delayed view.

Getting back to the physics engine "waiting", say the physics engine can perform it's work in about 3 ms, while 180 hz translates into 5.555... milliseconds, so there's over 2.5 milliseconds of "free time". The physics engine may sleep for 2 milliseconds, then use a tight loop during the last .55 milliseconds polling a high frequency timer counter in order to get as close to an exact 180 hz rate before starting the next update step. On a multi-core cpu, the graphics thread can continue running unimpeded, but even if the entire game is stopped for .55 milliseconds once every 5.55 milliseconds, it's not going to be noticable by the player.

Getting back to the physics engine "waiting", say the physics engine can perform it's work in about 3 ms, while 180 hz translates into 5.555... milliseconds, so there's over 2.5 milliseconds of "free time". The physics engine may sleep for 2 milliseconds, then use a tight loop during the last .55 milliseconds polling a high frequency timer counter in order to get as close to an exact 180 hz rate before starting the next update step.

O_o

Well, despite what you keep trying to assert, if that "clamping" is all you do, you get "jerky" and inconsistent physics; the difference between "5.5...ms" and "it's work" can be negative--as when the physics takes more than "5.5...ms". No, you can just apply the same physics the next loop; that loop may also have a negative difference, but it also may have a larger difference than the "5.5...ms" expected which you would just "burn" leaving no compute to account for more negative differences. You have to account for the difference between "expected time" and "actual time" each "tick". You can't do that by "waiting"; if you "wait", you are "clamping" each "tick" to an upper limit; if you "clamp", you "burn" compute; if you "burn" compute, you may not have enough resource to produce consistent physics.

For example, what happens when you go from only one car to having 32 cars--or whatever count? Yeah, the measurement will not be only "3ms". What happens when a dozen cars pass the same heavy curve at the same time leading to more demand because accounting for friction is suddenly more costly? Yeah, the measurement will not be only "3ms". You say the "physics engine may sleep for 2 milliseconds", but what happens when the physics suddenly takes more than "3.5ms"? Specifically, what happens when the physics suddenly takes more than "6ms"?

If you only "clamp" for physics by "busy waiting" until a "discrete tick", the game is going to be "jerky" and inconsistent. I haven't played "Shift" so maybe the physics is "jerky" or may the physics is great, but if the physics isn't "jerky" they are doing more than "clamping" to an upper limit the way you keep describing with "waits" or "sleeping" and "busy loops".

If you need "discrete time-steps", you can't do that by "waiting" unless you always have an excess of time; if more time has passes than expected, you have to use some form of "accumulation and integration" even if that is just a simple `dt = sub(et, at); if(dt > et)do_phys(sub(dt, et));', and if you do that properly, you don't need to "sleep for 2 milliseconds" because the physics engine only and always applies physics in 180hz "discrete time-steps" regardless of how much--account for missing "discrete tick"--or how little--do nothing until at least one 180hz "discrete time-step"--time has passed.

Soma

O_o

If you'd stop focusing on one particular set of games, for some unknown reason, you might actually understand what I've said. The various physics models apply differently to all varieties of games because different quality of physics is expected for different types of games; if you'd stop focusing on what one game does we might have been able to discuss the science, but every example I've offered to show the differences between approaches I'm hit with "I know Game does things different than what you describe.". Let me make this clear, I do not in any way care what "Shift" does; I only know that for physics to be consistent you can't "clamp" the physics engine as you've described. You can get consistent physics with several models; I've never said anything that could be interpreted as saying that consistent physics is impossible. Saying "You can't get consistent physics by just "clamping"." is not the same as saying "You can't get consistent physics.", and I have no idea what point you find in repeating "Game doesn't have problems." because it is obvious that other models--not just "clamping"--may produce consistent physics.

*shrug*

Feel free to continue thinking that applying physics only on "discrete time-steps" requires "clamping"; I'm done.

Soma

Originally Posted by phantomotap

Feel free to continue thinking that applying physics only on "discrete time-steps" requires "clamping"

I'm confused here, although the video frame rate may be clamped or capped at some FPS, the physics engines typically runs at some fixed rate, well below what would require them to be CPU bound. For an approximate 180hz rate, a game could alternate between 5 ms and 6 ms periods using a ticker driven event (~181.8 hz), I'm not sure what Shift does, other than it's reported to run at 180hz (this is a parameter in one of the game files, "tick rate = 180", and can be adjusted using a special game editor). Maybe there's a programmable timer / event type in Windows that I'm unaware of that has higher resolution that 1000hz or 1024hz.

Again the main point here was a response to the original post, that usually the physics and graphic engines are made independent enough to allow the graphics engine rate to vary without affecting the physics.

Originally Posted by rcgldr

I do recall that another racing game used normal threading methods for most of a time period, but then used a hard loop delay monitoring a high frequency timer, looking for a delta from previous readings to start the next cycle.

I've since confirmed this is how most somewhat high and fixed frequency loops are implemented in games and other time sensitive code. For Windows, timeBeginPeriod(1) is called to set timer resolution to 1ms. However depending on the operating system and hardware, a Sleep(1) will take 1 to 2 ms. From my own testing:

Intel 2600K 3.4ghz, Win XP, Sleep(1) = 1.953125 ms, which corresponds to 512hz.

Intel 2600K 3.4ghz, Win 7, Sleep(1) = 1.000000 ms, which corresponds to 1000hz.

In a typical fixed frequency loop, if there is >= 2ms of delay time remaining, Sleep(1) is called. Once < 2ms of delay time is remaining, QueryPeformanceCounter() is used to read a high frequency counter, from which a previous count is subtracted and the difference checked to see if the delay time has been reached. The "previous" count is based on an original count with delay counts added to it to prevent any "drifting" over time. The delay counts can handle partial count times needed to produce an exact frequency by updating a remainder based on QueryPerformanceFrequency() and the desired frequency. Example code snippet:

Code:

    QueryPerformanceFrequency(&liPerfFreq);
    uFreq = 400;
    uRem = 0;
    u2ms = ((UI64)(liPerfFreq.QuadPart)+250) / ((UI64)500);

    QueryPerformanceCounter(&liPerfTemp);
    uOrig = uPrev = liPerfTemp.QuadPart;

    while(1){
        /* update uWait and uRem based on uRem */
        uWait = (liPerfFreq.QuadPart + uRem) / uFreq;
        uRem  = (liPerfFreq.QuadPart + uRem) % uFreq;
        /* wait for uWait ticks */
        while(1){
            QueryPerformanceCounter(&liPerfTemp);
            uDelta = liPerfTemp.QuadPart - uPrev;
            if(uDelta >= uWait)
                break;
            if((uWait - uDelta) > u2ms)
                Sleep(1);
        }
        if(uDelta >= (uWait*2))
            dwLateStep += 1;
        uPrev += uWait;
        /* ... fixed frequency code goes here ... */
    }