6
\$\begingroup\$

How useful is it to keep a measurement of framerate over the course of long times (such as an hour) spanning multiple scenes/data environments?

I've had plenty of times where data throttling/pushing was based on a poll of what's going on in regard to framerate over the course of a minute. I've used ~10 minutes a few times when the game can be sensitive to upcoming high-detail/volume renders to task some unused processing power/memory bandwidth ahead of time.

Anyone come across any situations where long-term polling of frame speed is useful?

Improve this question
\$\endgroup\$
10
  • 3
    \$\begingroup\$ -1 because there doesn't seem to be a specific problem to solve here, it's just a discussion starting question. \$\endgroup\$ – Tetrad Apr 22 '11 at 22:22
  • \$\begingroup\$ The problem would be 'can I stretch my mind to think of new ways to optimize' especially in areas like this which I would generally ignore. \$\endgroup\$ – Garet Claborn Apr 22 '11 at 22:46
  • \$\begingroup\$ Still "no" because you have a presupposed answer in search of a question. \$\endgroup\$ – Tetrad Apr 22 '11 at 23:05
  • 2
    \$\begingroup\$ I see a legit question: "Are there any real situtaions, however niche, where developers ... make use of ... frames per hour?" So it had a little fluff in it, and it wasn't the best-phrased question. I wouldn't consider it -1 material. \$\endgroup\$ – corsiKa Apr 23 '11 at 1:58
  • 1
    \$\begingroup\$ Tetrad's point is that you have an answer - "frames per hour" - and are looking for the X in question "What's the best units to measure X?". Stack Exchange sites are not good for discussion questions like this, and frankly I think it's a dumb question anyway. \$\endgroup\$ – user744 Apr 23 '11 at 8:51
11
\$\begingroup\$

It may be more useful to create a diagram showing frames per second over a period of time. Ideally this diagram contains annotations about what happened in the world, for example changes of areas, starting and ending of fights.

annotated diagram showing FPS over time

In the sample diagram it is easy to see that the frame rate is a lot better in the home town than in the dungeon. And there seems to be something very fishy going on in the desert; likely a memory hole.

Improve this answer
\$\endgroup\$
5
  • \$\begingroup\$ Hey good point! That would be a fairly helpful debugging technique in some cases \$\endgroup\$ – ultifinitus Apr 23 '11 at 16:20
  • 3
    \$\begingroup\$ I really want to -1 this because it's not an answer to the question at all, but that says volumes more about the question than it does about the quality of the answer. \$\endgroup\$ – user744 Apr 23 '11 at 17:25
  • \$\begingroup\$ While it is not an answer to the title of the question, I am confident that it addresses the first paragraph and the "edit" one of the question posting. \$\endgroup\$ – Hendrik Brummermann Apr 23 '11 at 21:29
  • \$\begingroup\$ This graph looks somewhat similar to the test case where I had a drop after zoning to more than 3 areas. Thanks much for the added input and especially +1 for added visual. \$\endgroup\$ – Garet Claborn Apr 24 '11 at 6:03
  • 1
    \$\begingroup\$ @Joe: I think it's a useful illustration of why a large sampling period is less useful than a small one. If you were measuring over a larger window this same graph would have a much smaller dip in the middle and a slower decline at the end, potentially hiding useful information. \$\endgroup\$ – Kylotan Apr 24 '11 at 12:59
9
\$\begingroup\$

Seems almost as useful as a speed limit saying "2400 km/day" or "614400 km/year". Both are the same as "100 km/hour".

From the mathematical standpoint it makes no difference, but we humans have a narrow perception and we can deal much better with smaller numbers and time-frames.

If you throw 216,000+ FPH at me, I had no idea how long a frame is.

If you tell me 30 frame/s I can calculate without a calculator that 1 frame is 33.3 ms.

So no, I don't think it's a useful measurement, I've never heard somebody using it during several years in game-industry.

Edit: Now that I think about it, it would make sense, if 1 frame is very long, like 30 mins, then it is 2 frames/hour, but I doubt the fun factor of that game would be very high ;) So still "No" for game-industry

Improve this answer
\$\endgroup\$
8
  • \$\begingroup\$ Pretty much in agreement but it is scratching at my mind to find a use for it anyway :) tyvm for input. \$\endgroup\$ – Garet Claborn Apr 22 '11 at 22:37
  • 2
    \$\begingroup\$ Actually, there is a difference. I can run my car at 120mph, but I can't run it at 2880 miles/day. I have to stop to rest, fuel my car, eat, etc. \$\endgroup\$ – corsiKa Apr 23 '11 at 1:52
  • 2
    \$\begingroup\$ @glowcoder: it doesn't say anything about the duration of your trip. You can drive 2880 miles/day for 10 seconds as well as 120 mph for 2 days. The time you traveled has nothing to do with it, its just the speed. \$\endgroup\$ – Maik Semder Apr 23 '11 at 8:49
  • \$\begingroup\$ Or in other words: you have to rest and fuel your car too if you drive 120 mph for one day, there is no difference, its just a scalar multiplied with both sides of the equation, the underlying information remains the same. 1 mph == 24 mpday, its the same speed. \$\endgroup\$ – Maik Semder Apr 23 '11 at 8:59
  • 2
    \$\begingroup\$ @Maik I get your point, but the intent here is not to simply scale fps into fph - the point is to run the simulation/game for an extended period of time to get a view of the long term stability of the frame rate (in exactly the same manner as I described my car. I should note that it doesn't go 120mph anymore, now that I have a wife and kids... :-O ) \$\endgroup\$ – corsiKa Apr 23 '11 at 9:11
5
\$\begingroup\$

Frames per hour is an okay measurement if you're making a render farm or some other non-realtime rendering system. (A better measurement would be hours/hour though.)

Frames per second is not particularly useful either, and most developers that are any good at optimization will look at ms/frame instead, even if they still describe targets as X fps.

This question seems a bit artificial because I've never seen anyone actually describing measurements as such though.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ FPH is definitely artificial, just looking to see if anyone has ever dealt with it or any longer-term measuring of framerate in any form. Given ms/frame is more precise, but I deal with avg fps over a few minutes pretty often to calibrate throughput. \$\endgroup\$ – Garet Claborn Apr 22 '11 at 22:36
2
\$\begingroup\$

No, there's no use for frames per hour, in a system that requires multiple frames per second. it would be like measuring speed in millimetres per hour or something.

Even if you did have a situation where you want to look forward 10 minutes (why?!) to predict some slowdown event, any problem will manifest itself as a sharp negative spike in the frame rate at that point. By merging that freak event into the more normal rendering 5 minutes either side of it and looking at the 10 minute aggregate, you actually make it harder to spot these problems, not easier.

Mathematically speaking, taking the average of a set of samples effectively applies a low-pass filter to the data, leaving you with less information than you started with. The larger the set of samples, the more the filter cuts out. Since there's nothing you can do with less information that can't be done with more information, there's no use for this value.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ In response to "(why?!)": because there was an FMV coming up that had alot of dynamic parts to it. We usually had advanced notice through the scripting and quest engines that there would be some heavy rendering coming up while, at the same time, the player is about to go through a fair number of dialog-driven changes to said FMV during which we prerendered parts of the video. \$\endgroup\$ – Garet Claborn Apr 24 '11 at 6:25
1
\$\begingroup\$

FPH? I had no idea what that meant till I clicked on this question.

And no I cannot see what could be useful about knowing how many frames per hour.

What would be useful is logging the frames per second over time to make a visual graph, or to analyze programmatically.

With frames per hour, you could have 60fps most of the time, and every 20 seconds 1fps, and the final reading wont look different than a solid fps that is lower than 60.

Improve this answer
\$\endgroup\$
7
  • \$\begingroup\$ Good point, this is really what I'm talking about - will reword it somewhat. \$\endgroup\$ – Garet Claborn Apr 22 '11 at 22:47
  • \$\begingroup\$ FPS looks bad on a graph because it's an inverse of what we actually optimize, which is ms/frame. \$\endgroup\$ – user744 Apr 23 '11 at 9:18
  • 1
    \$\begingroup\$ @Joe I don't know about you, but I optimize for user experience. I'd rather have a slower framerate that doesn't get noticed by the user (which you can do with blurs and other tricks) than a faster framerate but still not fast enough to be missed by most users' eyes. \$\endgroup\$ – corsiKa Apr 23 '11 at 9:25
  • \$\begingroup\$ @glowcoder: I have no idea how that's relevant to your poor choice of units. \$\endgroup\$ – user744 Apr 23 '11 at 9:29
  • 1
    \$\begingroup\$ The two claims are completely independent of each other. My claim of "I optimize for user experience" and "fph can be valid" are two entirely separate comments. \$\endgroup\$ – corsiKa Apr 23 '11 at 18:16
0
\$\begingroup\$

Quite a few years ago, when professional vehicle simulators were very expensive, I heard about a vessel simulator (e.g oil tanker type of vessel) which had a frame rate of 2 frames/second.

In that context a 120 frames/hour metric would be meaningful, perhaps even more useful compared to 2 frames/second, especially if you have reason to believe that those two numbers are not exact but something that has been estimated.

Assume the scenario that those numbers (120 and 2) are based on some values that are rounded to 120 or 2 respectively. In the case of 2, you could expect the frame rate to vary quite a lot, anywhere from 1.5 to 2.5 frames per second. In the case of 120, the frame rate could vary from 115 to 125 frames per hour, which is a bit more accurate.

But again, quite a hypothetical kind of simulator software these days.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Except it's 120 frames/minute, not 120 frames/hour. In this case I'd want seconds/frame anyway. \$\endgroup\$ – user744 Apr 23 '11 at 8:46
  • \$\begingroup\$ You are right, it would be 7200 frames hour. Mea culpa. (Someone should downvote my answer... it's that stupid!) \$\endgroup\$ – IllvilJa Apr 24 '11 at 7:59
-2
\$\begingroup\$

Frames per hour says a lot more about your environment. It is a keen indicator for the long-term enjoyability of the game.

For example, you may have 50fps in some parts of the game, but in crowded areas, or areas of high intensity graphics or physics, you drop to 10 or 12.

If you graph the fph over the course of the game, you have a general idea of where you're at. It's no substitute for knowing that the frame rate drops in some circumstances, but if you're consistantly only at 15 or 20 fph you know there's a problem. The game should be high fps MOST of the time, if not ALL of the time. So having a moving average of the the long-term fps can help you achieve that goal.

Improve this answer
\$\endgroup\$
5
  • 1
    \$\begingroup\$ That being said, you mentioned "the only use is for benchmarking." Well, in a sense yes. The only use for metrics on your frame-rate (no matter the unit) is for analysis on the performance of the program. \$\endgroup\$ – corsiKa Apr 23 '11 at 1:56
  • \$\begingroup\$ This doesn't work anyway - graphing FPH gives the same results without losing sudden drops in the FPS. And if you want variance, just graph variance. (Or its more well-known square root, standard deviation.) \$\endgroup\$ – user744 Apr 23 '11 at 8:52
  • 1
    \$\begingroup\$ @Joe I've used it as a metric in the past for games (and other simulators) and it's been quite effective. I actually used the metric of 10 minutes instead of an hour, but the philosophy is the same. I didn't need anything fancy - just noticing that the "average fps" was only 18-20 indicated there was an issue in the general case, not the specific case. We did some refactoring and increased it to about 30. We never would have had that without the fph-stype metric. \$\endgroup\$ – corsiKa Apr 23 '11 at 9:10
  • 3
    \$\begingroup\$ -1 because FPH == 3600 * FPS, its simply the same information, only scaled by a higher number. The implication that it has anything to do with a long run or not or that it shows any additional information is simply a wrong understanding of what frequency means. \$\endgroup\$ – Maik Semder Apr 23 '11 at 9:48
  • 2
    \$\begingroup\$ @Maik not only do you not understand this, you don't understand algebra. It is NOT simply fps*3600. Why? Because the fps changes over time. It is (average fps) * 3600. Yes, that's correct. But that's the main point - AVERAGE fps over time. But to simply say FPH = FPS * 3600 is entirely missing the point of FPH. \$\endgroup\$ – corsiKa Apr 23 '11 at 18:15
-2
\$\begingroup\$

There are times when it is necessary, for "serious" applications, such as real-life Flight Simulators.

EDIT: In a flight simulator environment, such as the ones used to train pilots in routine and adverse situations, it is entirely possible that the simulator knows what scenario is coming up, and would need to pre-plan out possible responses the pilot may make, which may include abrupt changes in altitude (height), attitude (roll and pitch), direction (yaw), all of which may quickly change the upcoming scenery. The simulator plans for this by preloading the data and precomputing visibility in the potential upcoming scenes.

The long-term polling of frame-rate is necessary to help ensure that the training was a valid experience for the pilot. If the frame-rate had dipped below an acceptable level, then the training regimen may not qualify for FAA (re)certification of pilot readiness.

Improve this answer
\$\endgroup\$
11
  • \$\begingroup\$ Why? They have similar requirements on the frame-rate like any other game, "serious" or not. What is the advantage of saying my heart beat is 3600 beats per hour over 60 beats per minute? \$\endgroup\$ – Maik Semder Apr 22 '11 at 22:16
  • \$\begingroup\$ Can you expand on this at all? Would be very interested to understand the applications for flight simulators. \$\endgroup\$ – Garet Claborn Apr 22 '11 at 22:38
  • \$\begingroup\$ @Maik: still holding that it doesn't seem particularly relevant to go for an hour but when reading different amounts of time (say 60 fps vs 3600 fps) it can be useful to see the differences in the distribution. i,e.. which seconds have + or - 60fps during that minute can be indicative of places you can get a little extra performance or bottlenecks that need to be avoided. \$\endgroup\$ – Garet Claborn Apr 22 '11 at 22:41
  • 2
    \$\begingroup\$ If you measure the frame-rate for an hour or for a day or for a minute, it makes no difference if you measure it in frames/sec or frames/hour. It's just the frequency, it says nothing about the resolution or the sample-rate or the duration, you just multiply both sides of the equation with a scalar, the underlying data remains the same. Maybe this makes it clearer: When you say my car drives 100km/hour, it doesn't mean you are driving for 1 hour. It says nothing about the total time you traveled, its just the speed. \$\endgroup\$ – Maik Semder Apr 22 '11 at 22:50
  • 1
    \$\begingroup\$ Due to the down-votes, I won't be participating in this community, which could be a shame, since I actually know of what I speak. \$\endgroup\$ – Andy Finkenstadt Apr 25 '11 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.