Should reviews that don't use FCAT be ignored?

[Jaydip]

I am having a look at the code now so I'll confirm or otherwise later today.

Thanks I downloaded it too but It has been a long time since I used Perl.

 

[BallaTheFeared]

What he said was the code wasn't in the right place, it should ignore the faulty hardware artifact for it's mock FRAPS read out.

The more it's discussed by lucid people the more it makes sense. Still a strawman however used to discount the entire scope of what FCAT is and does.

 

[BrightCandle]

Ok let me understand this "FRAME1 FRAME2 ---- NEW FRAME 2 scanlines of FRAME1 show up FRAME3 FRAME4 etc." This is what you said.So are these "scanline frames" even smaller than runt frames? does this happen irrespective of any game(i.e. is it a universal thing for amd)? it looks like wasted resource to me to display "scanline frames" .Does fraps detect these frames as being displayed?

pcper.com said it occurred only at high resolutions and gave the reasons. But yes it occurs in all games and its an artefact of the way they composite the different images in crossfire using software.

Fraps has nothing to do with this, its purely a scan out fault not anything to do with the formation of the frame itself. AMD's cards don't bleed one frame into another during rendering the frames are fully formed but when the buffer is displayed to the monitor it exhibits this quite weird fault where frames bleed into others. That is all there is to it.

 

[sushiwarrior]

Ok let me understand this "FRAME1 FRAME2 ---- NEW FRAME 2 scanlines of FRAME1 show up FRAME3 FRAME4 etc." This is what you said.So are these "scanline frames" even smaller than runt frames? does this happen irrespective of any game(i.e. is it a universal thing for amd)? it looks like wasted resource to me to display "scanline frames" .Does fraps detect these frames as being displayed?

FRAPS shouldn't detect these as actual frames, they are only 2 scanlines (ie. 2 pixels). They're so miniscule and they aren't the result of any Present() call.

 

[BallaTheFeared]

Size doesn't matter, the fact that they occur past the point where FRAPS measures is the only part that matters.

Which is why it's tripping up FCAT when it's trying to mimic what FRAPS would show, it's shouldn't actually be there it's a product of faulty hardware/software.

 

[Jaydip]

pcper.com said it occurred only at high resolutions and gave the reasons. But yes it occurs in all games and its an artefact of the way they composite the different images in crossfire using software.

Fraps has nothing to do with this, its purely a scan out fault not anything to do with the formation of the frame itself. AMD's cards don't bleed one frame into another during rendering the frames are fully formed but when the buffer is displayed to the monitor it exhibits this quite weird fault where frames bleed into others. That is all there is to it.

Ok BC lets see Frame 1 is stored at front buffer and the back buffer is being filled with Frame 2.Frame 1 is displayed on screen and Frame 2 is now being stored in front buffer(Frame 3 is being stored in back while we speak). Frame 2 is now displayed.So how on earth even a "scanline frame(just made up the name)" for Frame 1 is displayed now? didn't we already flush out the buffers? I am not really getting the bleeding issue at all.If it does this they should fix it asap before doing anything else.

 

[sushiwarrior]

Size doesn't matter, the fact that they occur past the point where FRAPS measures is the only part that matters.

Which is why it's tripping up FCAT when it's trying to mimic what FRAPS would show, it's shouldn't actually be there it's a product of faulty hardware/software.

My god, it's almost like FCAT isn't giving accurate results of what FRAPS would be showing!

 

[Jaydip]

FRAPS shouldn't detect these as actual frames, they are only 2 scanlines (ie. 2 pixels). They're so miniscule and they aren't the result of any Present() call.

So FRAPS wouldn't be able to detect them but the frame delivery should be uneven(i.e. between frame 2 and frame 3 there is an extra delay , though probably imperceptible to human eyes).So why do it?

 

[Final8ty]

My god, it's almost like FCAT isn't giving accurate results of what FRAPS would be showing!

Don't waste your time with him, at least there are 2 others who are at least trying to find out for themselves and not just throwing what you say out of the window.

 

[sushiwarrior]

So FRAPS wouldn't be able to detect them but the frame delivery should be uneven(i.e. between frame 2 and frame 3 there is an extra delay , though probably imperceptible to human eyes).So why do it?

The frame delivery has no real issues - frame 3 arrives when it should, frame 2 is delivered as it should, the only issue is 2 lines of pixels at the top of the screen which are a remnant from the last refresh. The 2 pixels don't displace frame 2/3, they just replace the top 2 lines of frame 2.

 

[BrightCandle]

Even if it is the case (I am trying to confirm with pcper.com now) its really just a bug with the topline fps not with the actual fps it produces so all the wonderful work done with the tool by pcper.com etc is all perfectly valid, its just a few new sites have taken up the tool and are using a part of it the trustworthy ones don't because its possibly got a problem.

The analysis pcper and techreport have done is all perfectly fine, its the smaller less rigorous sites that have the problem, but still the actual FPS is fine its just the attempt to simulate fraps like FPS numbers that is potentially faulty.

 

[Jaydip]

The frame delivery has no real issues - frame 3 arrives when it should, frame 2 is delivered as it should, the only issue is 2 lines of pixels at the top of the screen which are a remnant from the last refresh. The 2 pixels don't displace frame 2/3, they just replace the top 2 lines of frame 2.

So is it always 2 pixels? that way it would be much easier to handle it in code.So from my understanding it isn't a frame at all, is that right? but we are still wasting resources to display it on screen(bug?).

 

[BallaTheFeared]

My god, it's almost like FCAT isn't giving accurate results of what FRAPS would be showing!

Yeah I'm with you, it's just still a who the flip cares deal.

It doesn't invalidate FCAT, it simply exposes more issues than FRAPS was aware of.

Nobody ever cared about reported FPS, the only thing that mattered, matters, and will ever matter, is what happens when you remove the RUNT and dropped frames which this doesn't effect AT ALL.

Look up straw man, you're doing it.

 

[sushiwarrior]

Even if it is the case (I am trying to confirm with pcper.com now) its really just a bug with the topline fps not with the actual fps it produces so all the wonderful work done with the tool by pcper.com etc is all perfectly valid, its just a few new sites have taken up the tool and are using a part of it the trustworthy ones don't because its possibly got a problem.

The analysis pcper and techreport have done is all perfectly fine, its the smaller less rigorous sites that have the problem, but still the actual FPS is fine its just the attempt to simulate fraps like FPS numbers that is potentially faulty.

It also is interpeted as a 0 ms frametime, so it affects frametime graphs as well (as a tiny frame = huge FPS = tiny frametime). I think the key with FCAT is that it is very "finicky" and takes a lot of interpreting to fully understand what is going on with the results. If you simply "press go" for any given app you can have tons of issues, which all give you problematic results.

The "Actual FPS" numbers that FCAT reports are very useful and quite helpful. The rest of the info should be taken with a grain of salt

Yeah I'm with you, it's just still a who the flip cares deal.

It doesn't invalidate FCAT, it simply exposes more issues than FRAPS was aware of.

Nobody ever cared about reported FPS, the only thing that mattered, matters, and will ever matter, is what happens when you remove the RUNT and dropped frames which this doesn't effect AT ALL.

Look up straw man, you're doing it.

Straw man implies this is an inconsequential issue. This is a two thirds of what FCAT reports (frametimes, "claimed" FPS and "actual" FPS). If having 2/3 of your results with flaws is okay, then you have some serious issues XD Straw man also doesn't apply because this is an issue where every part matters. If you make a ruler that measures fine past 2cm, but 1-2cm is wrong, does that mean it's an accurate measurement device? No, it has errors and as such the validity of any measurement with that ruler comes into question.

Google "statistics" or "stats 101", you may find some useful info.

 

[parvadomus]

If I understand correctly there are 2 lines of the screen showing incorrect data (from previous frames) at some x time during execution. However these are not the result of any Present() call so they dont count as FPS.
I will try to see them when I go back home, however I dont see it as an issue. It seems to me its some kind of garbage stored into memory which is not cleaned for some reason. Obviously FCAT results are totally wrong if they report 15 less FPS for this reason and should be fixed.

 

[BallaTheFeared]

Right, because of an AMD hardware issue the entire purpose of the tool no longer is valid.

This is why we've been arguing since the start.

You believe because AMD has faulty hardware, that FCAT isn't a valid tool to use. You also admit affiliation on some level to AMD, but won't disclose any further information on it.


The problem for you is that everything shows there is a problem with AMD's hardware, not with the software itself. The other major issue is your problem doesn't affect the quality of results that everyone and their mother seeks, which is the actual output to display numbers less the RUNTs and drops. Which is the defining and main purpose of FCAT.

 

[Jaydip]

IIRC FCAT uses a overlay hook to attach to a game, can FRAPS use it too? that way we don't need to use expensive hardware for frame capture, we can do it via FRAPS only.

 

[BallaTheFeared]

I'm pretty sure you need the capture card to get the raw output, otherwise it's not valid. Which is where I stopped, attempting to use FRAPS or MSI AB to record, even using uncompressed relegates it to a set FPS. The results from the extractor are then worthless.

If it was that easy, people like pcper wouldn't have went through all the effort of getting a card and setting up an ssd array to capture the raw uncompressed output.

MSI AB has their own overlay built into RivaTuner.


At least that was my experience quite awhile ago, though I may have been doing it wrong.

 

[sushiwarrior]

Right, because of an AMD hardware issue the entire purpose of the tool no longer is valid.

This is why we've been arguing since the start.

You believe because AMD has faulty hardware, that FCAT isn't a valid tool to use. You also admit affiliation on some level to AMD, but won't disclose any further information on it.


The problem for you is that everything shows there is a problem with AMD's hardware, not with the software itself. The other major issue is your problem doesn't affect the quality of results that everyone and their mother seeks, which is the actual output to display numbers less the RUNTs and drops. Which is the defining and main purpose of FCAT.

No, "actual" FPS numbers are perfectly valid. Those are recorded 100% accurately. Any "claimed" FPS numbers are invalid and frametimes are also questionable because this causes spikes in those too. I didn't say the whole tool is bad, I clearly said the "actual" FPS numbers are perfectly OK and very useful.

It's a hardware issue for AMD, yes I already agreed to this. I just said it's not a "15 dropped frames" level issue, hence FCAT is misreporting this.

IIRC FCAT uses a overlay hook to attach to a game, can FRAPS use it too? that way we don't need to use expensive hardware for frame capture, we can do it via FRAPS only.

FRAPS monitors DX Present() (aka. render the frame) calls, FCAT (or rather, the overlay) just paints bars on using DX. The issue is there is a difference between what FRAPS sees and what is actually outputted to the screen. Sometimes frames don't show up, sometimes bugs like this 2 scanline issue show up (and FRAPS may not see that).

 

[BallaTheFeared]

Wow after all that, I'm good if you're good!

 

[Keysplayr]

Also notice sushi is completely sidestepping any text calling for his affiliation.
He pretends nobody asks him or that nobody is saying anything about it.
Ill ask him.
Sushiwarrior. Are you affiliated with AMD or any of their marketing partners in any way?

 

[Keysplayr]

n/m

 

[bystander36]

FRAPS shouldn't detect these as actual frames, they are only 2 scanlines (ie. 2 pixels). They're so miniscule and they aren't the result of any Present() call.

Those 2 scan lines are just remnants of an image from the previous refresh still in the front buffer. That frame was already counted from the previous refresh and shouldn't need to be counted again.

Given that the overlay software does recognize this, as seen by the color staying the same, I wonder if they also add up that scan line height from the previous refresh.

 

[Will Robinson]

Also notice sushi is completely sidestepping any text calling for his affiliation.
He pretends nobody asks him or that nobody is saying anything about it.
Ill ask him.
Sushiwarrior. Are you affiliated with AMD or any of their marketing partners in any way?

:sneaky::sneaky::sneaky:

 

[Keysplayr]

Looks like Will knows something the rest of us don't.