The Framerate Analysis Thread part 2

Silent_Buddha said:
Thank you for including a count of all frames, which is what I'm assuming you are doing here. :)

All frames + percentage of frames with tearing is the sort of numbers I prefer. :)

Regards,
SB
Click to expand...

do I understand you correctly that you prefer ver.2 over ver.3 ?.
Do you care to explain why you do that ?.
 
It's a more accurate representation of the input response. And for FPS games I far prefer responsive inputs than non-torn frames.

For example using the old numbers of 20.654 FPS, that would indicate a quite laggy input response. While 47.981 would in generall be a pretty smooth and responsive game.

Graphics may suffer slightly due to tearing, but that doesn't bother me in a FPS nearly as much as slow feeling controls.

That's just my personal reasons.

More objectively, I prefer this method also as it's a more accurate reflection of reality without having to resort to one persons arbitrary interpretation of what's going.

For example why punish a game twice for torn frames? Once by lowering the reported FPS and then again by reporting the number of torn frames. You're already taking into account some arbitrary number of torn frames by lowering the reported FPS.

Again referring back to the v1 20.654 number. I honest thought the game was rendering only 20.654 FPS with approximately 50% torn frames. Meaning I thought there were only 10 untorn frames in addition to the game having laggy input.

Basically, I just find the method of All frames + Torn frame percentage to be far more truthful and less misleading.

Regards,
SB
 
I see and i Agree with the input response.

But i don't see how you punish it twice if you adding for ex. 0.7 frame to the fps count if the frame is 30percent torn. if you don't and adding a full frame to the fps count you get redundant data and the same parts of the frame will counted twice.

Showing the amount of torn frames is still valid i think.
 
habbe said:
I see and i Agree with the input response.

But i don't see how you punish it twice if you adding for ex. 0.7 frame to the fps count if the frame is 30percent torn. if you don't and adding a full frame to the fps count you get redundant data and the same parts of the frame will counted twice.

Showing the amount of torn frames is still valid i think.
Click to expand...

Well using your numbers for an example.

Say the game is running 40 FPS. And you have 30% torn frames. Of those 50% of the torn frames fall under your cutoff number. That would mean you lower the FPS by 6 down to 34 FPS.

Now you report that X game is 34 FPS with 30% torn frames.

Me, sitting here viewing that does my own calculations and come up with 23.8 frames aren't torn while the rest of them have tearing.

So now, not only am I thinking X game might have bad frame rates for the graphics it renders at 34 FPS. But that only 23.8 frames per second don't have tearing.

When in reality. The game has 40 FPS and 28 frames per second are untorn.

Do you see the disconnect between the reported numbers and the actual numbers?

This is why I always prefer the raw numbers rather than interpreted numbers when possible. And I like that PS360 includes those now.

[edit] Changing numbers, my math was off, making this example look worse than it actually was.

Regards,
SB
 
Last edited by a moderator:
well i see your point.

I'm not talking about an "cutoff" number i'm talking about reporting the actual new data in the frame to the fps count, not reporting the redundant data from the frame before.
 
You must log in or register to reply here.

Similar threads

Shifty Geezer
Digital Foundry Article Technical Discussion [2024]
138 139 140
Replies
3K
Views
246K
GhostofWar
G
L
ARM based Game Consoles on the way?
2 3 4
Replies
73
Views
8K
Lurkmass
L
R
State of GDeflate *spawn
2
Replies
25
Views
2K
Remij
R
BRiT
  • Locked
Digital Foundry Article Technical Discussion [2023]
252 253 254
Replies
5K
Views
534K
chris1515
C
G
Nvidia G-Assist
Replies
2
Views
1K
Davros
D
Back
Top