Mysterious openGL problem

Hi all. I've got a vague question here. Slembcke and I have been working on a game slowly for the last several months, and I've got a display problem that occurs only on my NVIDIA GeForce 7300 GT (I think).

We're drawing quads connecting touching lines of the same color, but on my card (and mine alone afaik), it draws down to between 0,0 and 1,1 of the viewport, that corner down there.

We're using scenegraph code that Scott wrote, but since it seems to work on his machine, it's hard to blame the scenegraph. The color of the icky quad is that of the previous ball that was added to the game.

We watched the openGL calls in the Open GL Profiler app, but everything looked right.

I guess my question is... has anyone run into something like this before, or seen problems with the NVIDIA 7300 GT?

More info: So it draws the balls first, then does a state change to draw the other little bits like the floating score numbers and finally the connecting lines are drawn using immediate mode textured quads. Somewhere between drawing the balls and the lines, a state change is made that completely hoses OpenGL until the buffer is flushed.

The crazy triangles you see are the quads drawn for the connecting lines. They are always the color of the last ball drawn, (calling glColor at this point no longer has any effect) and half of the vertexes are ending up near <0, 0>. Looking at the function call trace in OpenGL Profiler, all the function calls are there for color changes and correct coordinates for the connecting lines.

I'm still a bit torn if this is my problem or not. On the one hand, I'm not doing anything complicated, VBOs and rectangle textures is as complicated as it gets. So it seems unlikely to be a driver bug. On the other hand, I can't reproduce it on any other machine, the code throws no GL errors, I've been over the code (and the profiler trace) a bajillion times and can't find any problems.

We had this issue before in another part of the game, but it went away when some of the state changes were rearranged. Unfortunately, because the state change code is encapsulated in the scenegraph code, it's difficult to pare down the number of state changes to determine what is causing the problem.

Turned out to be a bad card, it would only show up sometimes. Luckily we had two cards in driving separate displays. Thought it was the pcie slot on the board, switched the card location and same problem, only opposite display. Picked up a new card and she was good.

Its very strange though, we run tonnes of simulations but it would only happen on very large particle simulations.

Thanks for the confirmation, reubert. At least now I know it's not a bad card.

Also, tonight Scott shuffled around some things and happened to change the draw order. Now the strange problem no longer occurs, but some of the text does not show up. We're probably going to see the problem disappears on 10.5.2, and if not, we'll try some of these suggestions.

I've seen a similar problem when using DirectX vertex buffers, where random or semi-random quads would appear on the screen. The problem in my case was that I was drawing more primitives than the VB contained, causing it to use random memory as vertex data.

I ran into the problem a lot when rendering text, where, with word wrapping and other effects, it was easy to lose track of how many quads I needed.

Not sure how relevant DirectX is to this problem, and it seems to be fixed anyway, but that's just a guess as to what might have been happening.

The thing is is that the VBOed geometry was the only stuff that seemed to be working correctly. It was the immediate mode and display list drawn stuff that was getting corrupted.

In the end display lists are just simpler. The idea was to use VBOs as it would lend itself nicely to allow dynamic geometry for interpolated models and such in C code. That's still a long way off, so I was just filling the VBOs with static geometry from Ruby code.

The display list code is only slightly slower, so I guess I'm happy with it then.