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).

Screenshot of the problem:
http://kortham.net/temp/openglbug.png

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?

If anyone wants to try to replicate/not replicate the bug, here's a download link:
http://kortham.net/temp/Critical%20MassFeb2%2008.zip

Thanks.

Well, I am getting the same thing on my NVIDIA 7300GT... If you showed us what we should be seeing instead, it might help understand what is going on here...

Que Scott to stop being lazy...

Working Screenshot

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.

Well, you've got the trace from the GL profiler, can you paste a frame's worth into a simple test app, and pare it down from there?

Might not be possible if you've got some calls that show up as pointers or whatever, but maybe worth a try.

Ive seen this exact problem before, using vbo's and rect tex's.

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.

Good luck!

I see the same problem when running your code on my imac 24inch 7300.

Do you need to use VBOs for something like this? Seems that if the problem lies there, it wouldn't affect much else if you stopped using them.

Hmm, try dropping the vbos and if that does work try dropping the rectTex's to narrow down the problem.

In the worst case upgrade the card.

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.

So, the leopard graphics update didn't fix the problem. We're gonna try taking out the VBOs. We'll see how that goes.

Yay, Scott fixed it by replacing the VBO code with display lists!

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.