ExtremeTech Article Up

The picture with the clipping plane problem is actually the first game, the benches are from SE though, I believe from a timedemo. I also find it extrodinarily difficult to even begin to think that the 3dMark issues were NOT deliberate, which leaves the possibility of there being a bug in only one portion of code.

Still, the coincindence in the nature of the issues is very suspect.

edit: formatting correction

 

Hehe... now where have I seen that before?! Mindless fanboys posting baseless drivel on the nV News forum perhaps? CAN'T BE.

MuFu.

 

Again very simple to verify, load the 43.45 drivers or earlier versions with slower SS:2 perfomance, run SS:1 and test both driver sets, if the clipping is showing in only in 44.03 drivers well we might have a 'problem'.

 

Doom, that would unfortunately be insufficent to actually make a solid determination of what was going on. The introduction of the 'bug' and the speed increase may be completely separate code segments (not that I think that'd honestly be the case, but we can't be sure about it like we can with 3dMark) It'd certainly make things seem more likely for a driver hack though.

 

Of course its not 100%, the only way we'd get that is having some form of 'free look' option in SS:2..but if the 'graphic anomolies' only present themself on drivers that significantly improve benchmarks using SS:1 (similar to 3Dmark)..it is a start.

Edit:reworded

 

I agree, but it would bring us one step closer to the truth. I think both SS and SS SE should be tested using at least the 44.03 and 43.45 dets both with the included timedemo and a custom timedemo (8 benchmarks in total). That would provide us with enough data to say something remotely useful, even if can't reach a final conclusion.

I also think someone should look into some of the other cases where the 44.03 dets provides big performance increases such as UT2K.

 

agreed

 

That would be a step forward.

For example, if custom timedemos in UT2003, SS:SE, and other benchmarked games do not show the same increase in performance that standard demos do, then there's support for demo cheating.

Of course, several custom demos in a variety of situations have to be used per game to establish a valid test.

I'm sure somebody cares enough to do this.

 

Hello guys. Old reader of the forums but I had to register to clear this SSam issue.

First, this is old news. It's happening for instance with all 4x.xx drivers with a GF4 card.
But the prerequisite condition is to change the folowing setting:

ogl_iFinish=1

to

ogl_iFinish=0

Iit's happening in both SSam versions.

 

ogl_iFinish=1


What does that switch do ?

 

Still no evidence of any cheats outside 3d mark then, I hope really hope that it stays that way (hoping they are innocent, not that they get away with any wrong doings).

 

Doom this is just a guess, I'm not very knowledgable with OpenGL, but taking a quick look at the documentation this may have something to do with its functioning.

void Finish( void );
forces all previous GL commands to complete. Finish does not return until all
effects from previously issued commands on GL client and server state and the
framebuffer are fully realized.

If I'm reading that right, setting the flag to 0 if it has a similar function to the above would allow the engine to display to the screen before the frame is fully rendered.

Mind you, it's highly likely that I'm totally misinterpreting something due to my lack of knowledge, but if that's *forced* to 0 I'd think it'd cause a frame rate increase since the frames being displayed wouldn't have to be wholly processed.

[Edit: On further thought if it does do that it may very well end up creating rendering errors like the one shown in that screenshot.]

 

Well it would be nice to find out what the switch is turning off

 

Just me showing some boredom on the topic, this is afterall nothing new, and yes it sucks big time.

 

Yep sounds like Kyle, it is all a game and spoken like a true Business Man as that is what he is.

 

This isn't entirely enlightening but it seems that setting ogl_iFinish to 3 is necessary to make the rage pro work with the SS engine. I'm again wondering if this has to deal with whether or not the program is allowed to render a frame without fully completing it.

 

Boring, old-hat, tiresome? You bet.

Irrelevant? Not a chance...

 

Checked my config, it is already set for 0. I'll check it out using 1. BTW- I'm not getting the artifact in SS:SE. I've been playing back through the game and am about 3/4s of the way through, the screenshot from SS is right where you start off.

 

I did some searching on the Croteam Forums, I didn't see any reference to ogl_iFinish=1, I wish there was some documentation that states what these switches do.

 

So what is the final determination with Serious Sam (one or two)? Is it really just a "known" issue of changing "ogl_iFinish=0" that fixes the visual anomalies?