Unlocking/locking Frame Rates

[jules 0]

I have fs 2004 and when I checked the frame rates I found that they were locked at 20 fps. How do I unlock them?

Regards

Jules

[Rafal Haczek 1612]

While being in FS open the Settings menu and go to the Display submenu.

There you can regulate the lock up to none (unlocked).

BTW I've got mine at 25FPS.

Best regards,

Rafal

[OPabst 2091]

.. Setting -> Display -> Hardware Tab and there Target Frame Rate Slider (to specify Rafals correct statement)

All above 30 will not realy give you more visible performace, because the human eye will only register around 25 pictures per second as smooth.

To lock the frames can be a good idea, because other processes in the background becomes more time to run smoother to, like fileloads, AI Calculations and so on.

[jules 0]

Thanks Guys,

I've set my frame rates at 25fps. Everything seems ok.

Regards

Jules

[solareagle 0]

All above 30 will not realy give you more visible performace, because the human eye will only register around 25 pictures per second as smooth.

That's actually a common misconception. Any gamer can tell you 60fps is required for the smoothest gameplay, and in fact many gamers would consider 25fps to be "unplayable". Its fine for a slow paced flight simulator but for something like a first person shooter 25fps is about the absolute minimum you'd want to see. Even for FSX I like to keep mine over 30 for smooth gameplay.

25fps is fine for film as film captures motion blur, but a computer render samples only one point in time, rather than sampling a broad section of time like a film exposure does. The fact is the human eye can percieve 60fps and beyond.

[Rafal Haczek 1612]

But we must be realistic.

Turning sliders down only to satisfy this possible physical impression wouldn't make sense.

From my experience I can say 25 is very fine and gives me the feeling of real life smooth flight.

At the same time I have other factors like real (clouds, traffic, complexity, autogen, etc).

We'd need killer machines to run our flightsim at 60FPS flying a PMDG 747-400 into crowded weathered Frankfurt.

Best regards,

Rafal

[Snave 466]

Even after all this time I see the completely erroneous notion of comparing fps in a computer-based simulator to a frame of film passing a lens is prevalent.

The analogy is incorrect, so please desist from facile and irrelevant comparisons. I wrote at length on this in the Eaglesoft forums, and I suppose it bears repeating again:

The rate at which celluloid passes a light source in a movie theatre has almost no correlation with the way images - and moving images - are displayed on a computer screen.

They may both use FPS, but they mean entirely different things in the different mediums. It always cracks me up when I hear these analogies as there is fundamentally NO basis for comparison. And here's why:

Your simulator, your computer is not just `displaying` these frames, like a movie projector does. It is calculating each frame in real time before it displays it. This calculations are integral to the correct display NOT ONLY if the resulting image on the screen, but also the way the aircraft, the scenery, the weather, everything responds to the changes from the previous frame and those for the next.

HOWEVER, the rate at which the behind-the-scenes calculations are done are not directly impacted by the fps, although they are influenced by it...

CPU time is a finite resource. There is only so much of it. FS, for all its gaudy detail and visual brilliance is a CPU-guzzling monster, with only a modest capability to shift the load to the GPU.

This, we already know.

But what this means is, if you are asking FS to use those CPU cycles to maintain a high frame rate, then it follows that there are fewer processing cycles available to do anything - everything - else.

Simple explanation why setting `unlimited` on your fps counter actually does impact your fs experience. It may not be in the visuals (although it often is. As you limit the fps you just watch those extra clouds appear, or the sharpness of the scenery and textures improve) but also in the invisible aspects of the sim - the flight model calculations and response to control input, the atmosphere dynamics and all the other things you can't see, but are being calculated on a frame-by-frame basis.

But there is a law of diminishing returns. If the frame can't update often enough, then the behind-the-scenes calculations can actually fall behind leading to the sim dropping cpu-cycles to keep the speed down. This can manifest itself as sluggish or odd control surface response, strange weather phenomena, even the old bugbear of texture blurring. What you need is a reasonable average, for your system, at that time.

So how do you calcluate that average? Well the tools are all there: You set the fps counter so that it displays Max/Ave/Min frame rates, you put the display on screen - and you go fly in the scenario THAT REPRESENTS THE ONE YOU WANT TO FLY IN. You do NOT use a benchmark, or unrepresentative flight. What's the point? you want the right setting for that sim, that system, at that point in the session.

Set the fps to `unlimited` and then fly around a bit. Monitor the frame rates, in particular the AVERAGE fps in the middle. Also note the % meter on the right hand side. That represents the percentage variation from the average at that particular moment.

After a few minutes, you should have a reasonable idea as to what to set your fps to - it will be at or slightly less than, the AVERAGE fps you see. Lock your fps to that, then return to the sim, and continue flying with the counter still visible. What you are now looking for is the bare minumum variation in that percentage meter, and you can ignore the actual fps. The aim is simply to have that meter as close to 0% as possible, with a small margin for error, based on what you have locked the fps to. But depending on what you have set the frame rate lock to, you may or may not want to adjust the value...

I'll explain with a practical example: After using the procedure above you have decided to lock your fps to 25, have set the limit and returned to the sim. The % meter shows 5% variation +/_. Should you set the fps limit lower? Well, 2.5% of 25 is 0.63, so why bother? You can't set that kind of adjustment in the sim.

But say you've set the fps lock to 35fps. The same 5% now represents 0.88 fs difference - getting closer to the `1`, so drop the fps counter from 35 to 34. It should be obvious that arithmetically, you don't need to change it much unless the variation settles at 10% or more or you see a consistent rather than momentary variation.

Once you have set this, you have optmised the rig for that particular simming environment. But be warned: Change ANY setting, including location or weather, and you may need to repeat the exercise.

With practice, you should be able to set up the sim for best performance with all other settings unchanged in a matter of moments. You also dvelop a feel for what the value should be - and you can adjust it accordingly without having to do much in the way of calculation or benchmarking. I use 25 fps `normally`, 22 in heavy weather. And that's about it.

The Unlimited fps setting is purely for this kind of adjustment, and possibly for benchmarking and should NEVER be used in normal flying. Also fps is purely a relative measure and should NEVER be used as a defining characteristic of `performance`. It can still be used as a benchmark for seeing whether your rig is performing to the limit of its capabilities, but please don't assume that fps has anything to do with fidelity. It doesn't.

Finally, there may - may - be a case to look at locking the fps to a value that reflects a whole integer or half integer multiple of the monitor refresh rate if you are using a CRT. The case for this is not proven, but in theory THIS is the setting that most closely approximates the speed of celluloid through a projector, and not the fps of the software. So if your monitor is set to 100Hz, then you might be best with a setting of 20 or 25fps or maybe 33fps to leave a ratio of 5:1 or 4:1 or close-to-3:1. The theory states that the frame buffer prepares to display the image, only to have to drop it when it gets `out of phase` with the refresh rate. I cannot think of a tool for testing this within FS, so I mention it in passing, without endorsement.

For LCDs the refresh rate is irrelevant.

[Aerosoft Team [Inactive Account] 51558]

That's actually a common misconception. Any gamer can tell you 60fps is required for the smoothest gameplay, and in fact many gamers would consider 25fps to be "unplayable". Its fine for a slow paced flight simulator but for something like a first person shooter 25fps is about the absolute minimum you'd want to see. Even for FSX I like to keep mine over 30 for smooth gameplay.

25fps is fine for film as film captures motion blur, but a computer render samples only one point in time, rather than sampling a broad section of time like a film exposure does. The fact is the human eye can percieve 60fps and beyond.

We done this many many times, put users two time in front of a FS and tell them to guess the framerate (once set at 25 fps and once at 35 fps). We never found anybody who could reliably tell the difference unless they went in slew mode. In fact most people say the slow fps session is the fast one because it is more smooth, without hickups. Smoothness is at least as important as framerate. And smoothness comes in a frame by frame base, not in an average number of frames per second. Just imagine 15 frames that take 0.1 second in total, then a 0.8 second pause and then another 15 frames in 0,1 second total. That would give you 30 fps, but it would be highly unusable. Capping the FPS in FSX cuts down on those pauses.

For professional sims there is almost always a 60 herz requirement. Even though the whole industry knows it is not needed and just triples costs and dumbs down the sim it is hard even in that professional environment for people to accept that 40 fps is totally adequate. 60 is better then 40 right? And people can see something like 90 fps under ideal conditions (or rather they can differentiate between 90 fps and 92 fps when seen next to each other)...

[Snave 466]

We done this many many times, put users two time in front of a FS and tell them to guess the framerate (once set at 25 fps and once at 35 fps). We never found anybody who could reliably tell the difference unless they went in slew mode. In fact most people say the slow fps session is the fast one because it is more smooth, without hickups. Smoothness is at least as important as framerate. And smoothness comes in a frame by frame base, not in an average number of frames per second. Just imagine 15 frames that take 0.1 second in total, then a 0.8 second pause and then another 15 frames in 0,1 second total. That would give you 30 fps, but it would be highly unusable. Capping the FPS in FSX cuts down on those pauses.

For professional sims there is almost always a 60 herz requirement. Even though the whole industry knows it is not needed and just triples costs and dumbs down the sim it is hard even in that professional environment for people to accept that 40 fps is totally adequate. 60 is better then 40 right? And people can see something like 90 fps under ideal conditions (or rather they can differentiate between 90 fps and 92 fps when seen next to each other)...

Precisely. This fetishistic adherence to the irrelevant fps counter serves only to hide the true nature of a simulation product - that what you CAN'T see is just as important as what you can.

In fact, I recall a very theoretical discussion in a very private forum among some noted experts which postulated that if we could do away with all the unnecessary external views and in particular the notionally useless (that's `useless` as simulation - `gaming` evokes a different priority) external view, the resources saved could be utilised to provide a better environment dynamic that might include visual cues that one sees in real flying, but which one does not see in the sim - for example leaves blowing off trees in the wind and so providing a visual cue to a different ground-level wind compared to the declared one at altitude, or other weather or flight-dynamics related advances in place of the graphic and CPU intensive display of images of the aircraft in 3d space which a real pilot cannot possibly see - not being able to step out in mid-flight to see whether the gear is up and all. The interesting part of the debate was the consensus that locking the frame rate to a LOWER figure, to allow more per-frame calculation for these increased quality invisible and visible services might actually improve the sim experience for most, but that it would almost universally be rejected as a great step backward.

Equally, it was accepted that the quality of a payware addon is still very much locked into its visual impression, rather than the ephemeral qualities of `feel` in flight.

Unfortunately, for reasons unrelated to the intention, MS ACES actually seemed to prove the lie with FSX, simply because they used a reduced fps to accommodate the FSX engine, but forgot that very few ardent simmers leave things standard for very long - and that unless you allow sufficient system overheads to cope with sophisticated addon on top of the core engine, you very quickly get dragged down to unacceptable fps levels.

It is only now that high pixel-count products such as the H-1 are available using true FSX SDK methods are proving that you CAN have your cake and overheat it...

[Robert S 75]

Simon,

Very good information and thanks for making it available on this topic. I do have a question for you on this statement however:

...if we could do away with all the unnecessary external views and in particular the notionally useless (that's `useless` as simulation - `gaming` evokes a different priority) external view, the resources saved could be utilised to provide a better environment dynamic

It's my assumption that the CPU & GPU will only be rendering that view which is being utilized by the player at any one time. So for instance, if you are in the cockpit, the resources are rendering that scene. If you switch to external view, then the computing resources are re-directed to rendering that scene. Where is the resource savings, then, if only one scene is being rendered at any one time?

What I am inferring from your theory is that multiple views are being processed by the PC at once, even though you are selecting only one to view, and by eliminating them from the sim you thus save processing power. Is this correct?

So where would the resource savings occur (assuming my understanding of how the sim handles scenes is correct...)? Not challenging the assumption here, just seeking clarification!

Again, good information for simmers here!

[Snave 466]

Simon,

Very good information and thanks for making it available on this topic. I do have a question for you on this statement however:

It's my assumption that the CPU & GPU will only be rendering that view which is being utilized by the player at any one time. So for instance, if you are in the cockpit, the resources are rendering that scene. If you switch to external view, then the computing resources are re-directed to rendering that scene. Where is the resource savings, then, if only one scene is being rendered at any one time?

What I am inferring from your theory is that multiple views are being processed by the PC at once, even though you are selecting only one to view, and by eliminating them from the sim you thus save processing power. Is this correct?

So where would the resource savings occur (assuming my understanding of how the sim handles scenes is correct...)? Not challenging the assumption here, just seeking clarification!

Again, good information for simmers here!

Not quite correct. There is a degree of `forward planning` in the core engine thinking and this by necessity has to include the typical prefetch calculations - the sim is not just calculating the `now` it is also calculating the `next`... which is precisely why it differs from film passing a projector lens. This must also include a degree of anticipation of alternative view scenarios even though the sim may not actually make a full anticipatory calculation. This is evidenced by such things as switching to tower view, then straight back again - notice how the textures are still there, yet now blurred..? That is actually forward planning, FS-style, it holds low-res textures in memory even though the tower view may be many miles away - it KNOWS you will want to return to your plane, sometime..

While much of this is actually GPU, NOT CPU calculation (so with a fast enough buffer, and a large enough repository, these calculations can be made, rendered and discarded as not being required without too significant an impact, particularly with todays HOOOOGE VRAM-filled, wicked-fast cards), the CPU might benefit from removing these forward-planning prefetch calculations - say be removing Spot View (no aircraft textures to render except for those visible from the cockpit) or by removing Tower View (saving the prefetch calculations that are being made in anticipation of the possibility of that view being called) you could remove much of the hefty CPU calculation required to implement the scene above and beyond `simple` graphics. Again you are thinking that sims are just what you see, when the visible spectrum represents only a proportion of the `work` the computer is calculating when rendering a scene: That Tower view also has local weather and dynamics calculations, mesh and landclass assessment, even sound allocations and no matter how fast the graphic buffer, the cumulative load of `surprising` the CPU with these unexpected demands could cause the sim to not only have to calculate those very intensive values, but also potentially drop something else to do so, to play catch-up with the fps demand. Do this with a fast (unlimited) fps counter and you have the CPU playing catch-up, and it's not as good at it as the GPU.

The sim as we know it has very little in common with the simulator as the aviation industry knows it - there it is generally accepted that the Field of View is the limit of the rendering necessary and the technology calculates a `channel` ahead based on current location and direction, speed and intention. Because FS has to accommodate other things like the location of AI (and the possibility you might want to suddenly `go there`) or the re-calculation required by relocation of the POV even just outside the aircraft, there is a gaming necessity to render a much larger scene than might be required for direct, anticipatory flight. The postulated theory was that these many threads conspire to reduce the overall performance of the sim...

A corollary to this was the idea there ought to be menu options OUTSIDE the sim itself to make important rendering (calculating, not visual) selections before the sim itself loads, in order to prioritise the game engine to suit the parameters selected. After all, if one is flying the VFR route up the valley, and has no intention of stepping outside the cockpit does one REALLY need all those ILS and VOR stations in the entire continent or the ATC requirements of major international hubs hundreds of miles away or the calculations of what the desktop controllers movement means for the animated simulation of aileron, rudder or elevator..?

If one could strip away all those game features that were unnecessary for that session, might one save sufficient resources to have a better simulation of ground-induced turbulence, microbursts or those external cues I referred to above..?

[Robert S 75]

Thanks for the further explanation Simon.

If one could strip away all those game features that were unnecessary for that session, might one save sufficient resources to have a better simulation of ground-induced turbulence, microbursts or those external cues I referred to above..?

Agreed!