no far clipping in fullscreen mode.

I have this really weird problem. I thought it was initially Z buffer related, but I am using the describepixelformat routine, and stepping through my code, does indeed yield a 24 bit frame buffer.

(As a matter of fact, I can’t seem to get a 16 bit zbuffer. Even when I request 16 bit color, 16 bit zbuffer, and 0 stencil in 16 bit desktop too. DescribePixelFormat always resets it back to 24 bit Z.)

In windowed mode, everything is fine, but in fullscreen mode, 16bit of 32 bit, moving the object past it’s far clipping plane, doesn’t seem to clip it totally. Only once every second or so. Basically the object does not disapear past the far clip plane in fullscreen mode, but instead only intermittantly gets clipped.

This definitly seems to be a clip plane thing, and not a Z buffer thing.

I have a demo if anyone wants to try it.

I am using an a Geforce 3, with 23.11 drivers.


[This message has been edited by Nutty (edited 12-30-2001).]

I am happy to try your demo !
Can you send it to me ?



Will do.

daveperman reckons it’s a driver bug. Though I wouldn’t thought something that obvious wouldn’t have slipped through in the latest offical release.


Why don’t you send me the app?

It does you absolutely no good to talk about driver bugs behind my back. If you don’t send me test apps, the bugs will never get fixed.

  • Matt

Sorry Matt, I’ll send you a program as soon as I re-install a load of stuff, and am able to build it.

Got infected with a virus, and all me .exe files got deleted…

Originally posted by mcraighead:
It does you absolutely no good to talk about driver bugs behind my back.


Remember this app I sent you 1 to 2 years ago regarding a “lighting problem” in my 3D viewer on GeForce DDR (I guess not !) ?

It turned out that the fault was actually in my program and not in your drivers. Can’t remember if you had started looking into the problem when I solved it but it doesn’t matter.

My point is that I think posting such messages here before sending them to you actually saves your time !

OK, it makes everybody aware that your drivers have bug but any developer knows that apps are typically not bug-free. Your drivers are apps !

There’s no conspiracy here: we simply want to check whether the bug is ours or yours before bugging you with test apps !

You sound a bit stressed these days… Keep !



Yes, I get stressed about these things, but you have to remember that perhaps the main reason that I frequent this board is to get bugs fixed, and secondarily to explain certain aspects of how either OpenGL or our extensions or driver or hardware work.

In general, I consider any flaw in our products to reflect poorly on me (whether or not I was involved with that particular thing), and I consider any attack on our products to be tantamount to an attack on me. I have very high standards when it comes to engineering, and I am unhappy when anyone in our company fails to live up to them. The last thing that I want is for some bug to remain unfixed for an additional driver release even though someone did discover it.

  • Matt

when I first installed xp, I had to rely on the nvidia drivers it came with (no hardware GL) because of that god awefully annoying infitie loop ‘bug’ that I still get. BUT, it was software gl, and when in wireframe, you could see the triangles clipped to the far clip plane (as the edge created was a line) - yet when using official drivers, in hardware gl, there is no line there anymore…
I noticed this in both windowed and fullscreen.
or am I just being ignorant and this is just driver optimization or something?


when will we see a refresh rate selector in NVIDIA drivers for Win2K/XP, to fix this monstruous 60Hz D3D/OGL thing and get rid of 3rd party tweakers?

Anyway I’ve never discovered any OpenGL bugs in NVIDIA drivers with my apps. I have to say I’m more than pleased!
I can’t tell the same with the drivers of another well known company.

My only complain would be the lack of details when newer drivers are released. It would be nice to know what particular OpenGL routines have been optimized, enhanced or fixed. Although NVIDIA papers on OpenGL and OpenGL’s performances are a nice help, they’re not always enough.

Man, this has gone a little OT :stuck_out_tongue:

That particular issue is an application bug, as far as I know, so it is unlikely that we are going to do anything about it.

I don’t think we’re ever going to provide lists of changes. Too hard to make a meaningful list, and even if we did, it would not necessarily be in our interest to release it.

  • Matt

True, the 60Hz refresh rate thing is a Win2K/XP issue, but since it has never been fixed… it would be nice. But even under Win9x/ME, where this behavior doesn’t show up, it’s still hard to select the refresh rate you want to each resolution in D3D/OGL.
The drivers of a video card should provide a way to select refresh rates for every resolutions. It’s really something everyone wants, and I don’t think it would take more than a few days to implement such a thing into the NVIDIA drivers panels (I might be wrong). Would be really a plus.

For the changes lists, well I kinda expected that answer… I was just pointing that sometimes new drivers releases were a bit “cloudy” for developers.

One annoying thing for developers I noticed with OpenGL NVIDIA drivers: when there is an error occuring in oglnv.dll, the call stack in Visual C++ 6.0 only shows “OGLNV.DLL” but doesn’t show wich function of my app called it. The only thing available is the ASM code of the drivers and which instruction caused the error.

Because of that a friend and I spent 3 hours searching what part of his code was making the driver crashing (it was due to a display list call making oglnv.dll crashing on a SSE instruction, never found out if it was an app bug or a driver bug. Never heard of it again).
He told me he heard NVIDIA was hidding the call stack to avoid inverse engineering.

PS, now it’s really totally OT

[This message has been edited by GPSnoopy (edited 01-04-2002).]

The drivers of a video card should provide a way to select refresh rates for every resolutions. It’s really something everyone wants, and I don’t think it would take more than a few days to implement such a thing into the NVIDIA drivers panels (I might be wrong). Would be really a plus

Windows 98 does allow you to set the default refresh rate of each video mode (well, at least the various modes the desktop uses). While there is no specific list that lets you set each rate for each mode, you can set your desktop into each mode and set the default rate while you are in that mode. Granted, a 3rd party registry tweaker is easier to use .

In win2k, you can get the refresh rate for every enumnerated mode, before changing the display mode.

I dont know why people keep complaining about default refresh rates, surely it’s up to the application to select which refresh rate it wants, and if the app doesn’t allow you to do this, then it’s not the fault of driver.

There is a program that allows you to change windows default refresh rate for every resolution available, once set, it will use the default refresh rate you set it to. Unfortunatly I dont recall the name of this program.


I think you’re refering to that program:

As you say, any applications should be able to override the default refresh rate at the specified resolution.
However, it should be possible to modify those default refresh rates given by the OS. It’s the same idea with some options in NVIDIA drivers for OpenGL or D3D, you can change default values for some settings (eg: default texture color precision).

We all know this refresh rate problem is not driver related, but a nice refresh rate panel like in PowerStrip would be nice. I’ve seen such panels in non-NVIDIA drivers, why not in NVIDIA drivers?

PS: I’ve just seen they discuss about the same problem in the “Nvidia SDK in multiple projects workspace” topic

[This message has been edited by GPSnoopy (edited 01-04-2002).]

Originally posted by GPSnoopy:
He told me he heard NVIDIA was hidding the call stack to avoid inverse engineering.

That’s total garbage. I don’t even know how it would be possible to hide the call stack, except to corrupt the stack.

  • Matt

mcraighead, I was wondering, if we find a bug that locks up win2k, but it doesn’t do it all the time, what is your advice? To send you the program, and you can watch it for xx mins/hours and hope something happens?

I just happen to have this situation, and I am trying to find out why it caused win2k to lockup. The app in question has no sound code, and I don’t have music apps in the background running, so this tends to rule out the sound card. No virus scanners in backgfround either, nothing much else running except VC++.

And if you can’t get it to lockup your machine, that means that I just wasted your time, and you would ignore bug reports from me in the future (heh)
That is why I tend not to say anything, until I find the problem, then say “BUG BUG BUG!” ( ) But this might be the wrong approach.

What is your $.02 on this ?


Xor with some constant works pretty well. Memcpy() to some other place and nuking with cc even better :slight_smile:


You may want to get ahold of a second machine (say, that old Pentium 120 in a corner) and hook up a serial cable to the machine that locks up; then run WinDbg. Once you have two-machine set up, you can break into most kernel hangs (although you don’t always get enough of a clue to figure out what it is).

Bugs that involve hangs after an extended period of time are difficult. There are many, many possible causes, and it’s probably not a good use of my time to investigate them, certainly not unless they’re very carefully narrowed down.

Corrupting the stack intentionally has a significant performance cost and doesn’t actually make reverse engineering any more difficult.

  • Matt

jwatte, I do have some extra machines, but I need to get another monitor. I use to do remote debugging (On the 68k platform), but the utils I tried to use (for x86) at the time really were bad. Makes me think I should get Softice or that program you mentioned, and crack open a x86 assembly book. If the problem isn’t solved by new drivers, I guess that is what I am going to have to end up doing.
Thanks for the tip though.


I was joking :slight_smile: Doing that stuff would be SO counter productive to pretty much anything. Especially since the code is sitting there in the DLL anyway.


WinDBG can debug at source level, if you actually have the source to what you’re debugging. It’s a free download for 2k (the DDK is not downloadable for XP :frowning: ). It only works on WinNT/2k/XP.

For 9x/ME, there’s something called, alternately, “wdeb396.exe”, “wdeb98.exe” or “debugger.exe” which sometimes cooperates enough to let you do the same thing. You talk to it using a program called “rterm” or “rterm98”. However, it’s not nearly as nice as WinDBG, and I’ve found it to be as flakey as 16-bit windows always is.