The Framerate Analysis Thread part 2

I believe grandmaster suggested to PS360 earlier in this thread that he should account for the overscan tearing somehow. It's a tricky one. Probably needs two numbers, one for absolute tearing, and one for tearing past the top however-many-lines where it's not really noticeable.
 
the bit at the start in the house is pretty bad (PS3) - seemed to be better outside, but I'm hopeful of improvements in the final code
 
Cutscene Comparison
360 Avg:24.013fps Min-Max:19.5-30.0fps Tear: 0.440%
PS3 Avg:24.485fps Min-Max:17.5-31.5fps Tear:39.482%
http://www.youtube.com/watch?v=DdNbLRR998Q

GamePlay
360 Avg:26.490fps Min-Max:15.5-30.0fps Tear:26.231%
http://www.youtube.com/watch?v=q6KfLWIytVU

PS3 Avg:25.763fps Min-Max:15.5-30.5fps Tear:40.146%
http://www.youtube.com/watch?v=lS6jopekTO4

Looks just as bad as I expected after playing the 360 demo.

Honestly, if you just glanced at those numbers you wouldn't realise quite how bad it is. During shootouts (i.e. precisely when you need a good framerate) it looks to average ~20fps or thereabouts on both consoles (with plenty of time spent in the tens on the PS3) and that's with the "joys" of constant tearing to put up with.

It might sound harsh but as far as I'm concerned the game just isn't in a shippable state on consoles. Its strange but the performance on PC is absolutely fantastic.
 
Even a high end PC from 2006 runs circles around any console so it aint that strange.

Yeah, but even a midrange PC from 2006 runs circles around consoles here. The gap is much wider than your usual multiplatform title. This performs better than the recent K&L2 demo on my rig and that was a 60fps game on the 360.
 
Last edited by a moderator:
It should be that way when they optimise for PC taking perfomance ratio and capabilities into account. Sure they could shape it up a bit more but no miracles. An open-world game that also dont have loading screen for indoor parts but instead stream it in/has to render it from a distance (windows letting you peek in etc). That sure adds to the load.
 
It might sound harsh but as far as I'm concerned the game just isn't in a shippable state on consoles.

You're assuming that the demos are off the final builds of the respective consoles, but they actually appear to be the E3 ones going from the vids that have been circulating since early June.

The release isn't that far off so we'll wait and see how they fair, but naturally if you have a capable rig, PC is the way to go.
 
Even a high end PC from 2006 runs circles around any console so it aint that strange.

A 2006 Core 2 Duo doesn't and a 7900 GTX sure as hell doesn't, so I'm not sure what PC hardware you're thinking of. Nvidia squeezed the 8800 GTX in just before *2007, so that would, but that was hideously expensive and only available in very limited quantities so that's kind of a stretch.

*[EDIT] 2007 is generally considered to have followed 2006, and not the 2009(!?) that I originally put at 1:46 AM [EDIT]
 
Last edited by a moderator:
It should be that way when they optimise for PC taking perfomance ratio and capabilities into account. Sure they could shape it up a bit more but no miracles.

The game really doesn't seem that impressive as far as tech is concerned. I see nothing that hasn't been done as good as or better on consoles or PC.
 
I believe grandmaster suggested to PS360 earlier in this thread that he should account for the overscan tearing somehow. It's a tricky one. Probably needs two numbers, one for absolute tearing, and one for tearing past the top however-many-lines where it's not really noticeable.

I suggest he uses a different number based on where the tear is, i.e multiplying it with a value from a lookup table:

Torn Line/IQ Factor
0(No tear)/0
1/0
2/0.01
3/0.01
4/0.02
5/0.03
6/0.05
7/0.07
8/0.1
......
150/0.99
.....
360/1
......
510/0.99
.....
715/0.03
.....
720/0

Or a curve similar to this. A proper tear would be fully counted while tears around the edges would be a lot less weighted.
 
I suggest he uses a different number based on where the tear is, i.e multiplying it with a value from a lookup table:

The thing is that while position of the tear is of course crucial, of equal importance is the content of the framebuffer. If there's a tear in the top third of the screen, but the top third of the screen is basically a skybox, it's virtually unnoticeable.

Similarly if you're moving "into" the screen (for example driving straight ahead), a tear is far less noticeable than if you're turning sharp left/right, or if an explosion occurs.

I'd love to be able to put an "index" on the impact of screen tear but it's just not possible.

I am however a fan of clipping out the overscan area from analysis. The soft v-sync phenomenon occurs in a pretty big percentage of PS3 titles, making the torn frame percentage stat useless.

I shy away from average frame rates stats these days because context really is king. We can have game X at 29.5fps and its other console equivalent at 29.2fps and we can still see huge differences at crucial points: the longer your clip the more averages average out.
 
I shy away from average frame rates stats these days because context really is king. We can have game X at 29.5fps and its other console equivalent at 29.2fps and we can still see huge differences at crucial points: the longer your clip the more averages average out.
A thought just occured to me about a visual presentation for framerates. If you group framerates by perceptually similar, maybe 5-ish frame groups, you could have a chart of distribution. You could then present this with colour intensities, or a distribution graph. This'd give an at-a-glance view of stable framerate (tight distribution, only one or two bars/peaks), variable framerate (broad distribution), 30 fps locked with a little dip (major peak around 30fps, some area underneath), and occassional severe dips (peak in the low end). A game could be given a framerate profile, and this could be fairly compared against other titles including from the same engine.

I dare say the same could be achieved with tearing, with a distribution graph of where in the vertical refresh the buffer switch happens, although as you point out that misses the perceptual impact.
 
Back
Top