After building my Opengl/c++ app in Visual Studio 2003 I get very strange rendering artifacts.
http://24.251.98.224:8001/test/screenshotBAD.jpg
It seems like many triangles fail to render if there is something else rendered behing them. The triangles that fail vary from frame to frame so there is massive flickering all over.
The identical code runs fine on windows if it is compiled with gcc-mingw. It also works fine when compiled and run on linux.
I thought this must be some kind of z-fighting or depth buffer precision issue, but it seems that the buffer is being set to 24-bit. I have tried disable back-face culling and enabling depth_test all over, just to see if there is an effect. I have also tried bringing in the far-clipping plane and pushing out the near plane. I also tried disabling fog.
I can’t figure out why it would matter which compiler is used. This is driving me nuts.
Let’s assume the code is correct for the gcc compiler.
I’ve seen similar problems before. Normally it happens if vertex array data gets screwed, indices wrong etc.
Make sure your code is not using any hardcoded sizes, strides, pointers. Carefully examine every memory movement of the geometry data.
Also check for data struct size. For example
MSVC[sizeof(TheStruct)] != GCC[sizeof(TheStruct)]
depending on compiler settings (because of mem align). So, check your map loaders (if you have struct read/write in code), check stride in gl*Pointer call, check struct offsets, check char type (some compilers treat it as signed and others as unsigned).
http://24.251.98.224:8001/test/screenshotBAD.jpg
It seems like many triangles fail to render if there is something else rendered behing them. The triangles that fail vary from frame to frame so there is massive flickering all over.
You could always keep it like that and call it “art.”
I am still having problems. I have the problem on both of the cards I have tried( Ti4600 and Go 4200). I have tried disabling VBO, same problem.
I don’t think it is a problem in the vertex buffers, as I load these only once - yet the flickering appears in random triangles. In other words, any given triangle is rendered correctly in on frame but perhaps not in the next. If the error was in the load, wouldn’t the same triangles be consistently wrong?
I think I will try commenting out large chunks of the application to see if I can spot the culprit.
Thanks again for your replies…
Any additional suggestions are always appreciated.
well it seems that the STL string in gcc can be stored in a const char* but NOT in Microsoft’s STL. Anyway, clearly my code had issues - I don’t know why I was caching the result in a temporary string…grrrr.
Hence, the near plane was 0 and I had massive z-fighting.
Oh well, there goes quite a few hours down the tube.
But at least I finally got it - and it was definitely my code that caused it…grrrrr…
A bit strange to see you declare a constant, then immediately change it. I would have expected at least a compile-time warning - if not a compile-time error over that.
Maybe you meant it to be a static variable, rather than a constant?