This post consists of 2 sections: 1) Errors found with glIntercept 2) Error handling in OpenGL - my research

My main idea was: spring should work on intel video cards. I think that some opengl errors can be fixed/workarounded and spring will run on intel. So I tryed to find out which errors can produce these visual bugs on intel video. And I find a few ways how to get error messages. 1) glIntercept (http://code.google.com/p/glintercept/) 2) glGetError() (http://www.glprogramming.com/red/chapter14.html#name1)

So 1) glIntercept. It works only under windows. So I played short singleplayer game with 2-4 fps using this tool. Error log is attached (gliLog.txt).

2) glGetError(). I downloaded spring code and put

into Game:Draw function to get errors. Also I rewrite clearGlErrors function and some other places where I found glGetError().

So I compilled and tested spring with glGetError() enabled. It logs lot's of GL_INVALID_ENUM too.

I am newbie in c++ and opengl.. So maybe my research was very dumb. I just want to show you these errors, maybe you can fix it and spring will run under intel without problems?

------
Why we can see strange visual bugs using intel video:


What we can do to detect such opengl errors?

If it's hard to fix these errors, maybe we can log them better?

those `errors` are by design and handled correctly

Why spring does not work on intel then? I think because of these opengl errors.

Why we don't log these errors?

Cause their OpenGL drivers have endless loops, pointer dangling, ... in them = their drivers are BUGGED.
Neither do they update/fix once released drivers (for most GPUs there was just _one_ driver released and never updated!)

Cause it is a flush operator? (it will halt the thread until the GPU is finished with processing all commands in the GL stream)

two possible solutions:
improve this, so it works with spring:
http://sourceforge.net/projects/gldirect/ (opengl->directx wrapper) i don't know if its possible to do that with a nice performance (or at all...)

currently it cries about "Needed OpenGL extension(s) not found: GL_ARB_texture_env_combine GL_ARB_texture_compression

use linux! intels opensource drivers should be better as the closed one. they are regulary updated and some steam and intel guys are currently working on improving it.

(just my two cents)

abma, I use linux. And spring has lots of visual bugs with intel sandy bridge video. Unplayable. So OpenGL->DirectX is not a solution for me :-D I think realo solution - understand what exactly causes problems and fix/workaround it.

I rebooted to windows just to get glIntercept reports as OpenGL errors example.


Sounds strange. But I am newbie. So I will trust you.

from your infolog.txt:
OS: Microsoft Windows

sad to hear that its still unplayable. hopefully it becomes better when steam officially supports linux.

glIntercept works under windows only

I tried to research more.. don't be anger please.

Lot's of errors in different places.

For example (from infolog.txt):
[f=0009721] after LocalModelPiece::Draw() glCallList(dispListID); OpenGL Error: invalid operation

How I traced:


Sad that I have not knowledge of OpenGL and especially Display Lists. Can't understand how models can have these lists with errors.

I wonder if MESA dislikes

Wow! I found something!

http://www.mesa3d.org/debugging.html


also

Mesa prints messages like that:
Mesa: User error: GL_INVALID_ENUM in glPolygonMode(mode)
(my logging) [f=0000237] after eventHandler.DrawWorldPreUnit(); OpenGL Error: invalid enumerant

hm... what can be wrong in simple functions like glPolygonMode?

looks like this function accepts constants, why it says: wrong enum? :-D

Searching in Spring code...
...
glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
...
glPolygonMode(GL_FRONT_AND_BACK, GL_LINES);
...
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
...

CommandDrawer.cpp -> glPolygonMode(GL_FRONT_AND_BACK, GL_LINES);
WHAT? GL_LINES? Is it correct constant? looks like not! http://www.cs.rutgers.edu/~decarlo/428/ ... nmode.html

from glew.h
#define GL_LINE 0x1B01
#define GL_LINES 0x0001

I recompiled Spring without LINES and there are now less errors. But still lots of them.

Examples:
Mesa: User error: GL_INVALID_ENUM in glGetFramebufferAttachmentParameterivEXT(attachment)
Mesa: User error: GL_INVALID_OPERATION in glFramebufferTexture2DEXT

Mesa: User error: GL_INVALID_OPERATION in Inside glBegin/glEnd
Mesa: 13 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glBegin
[f=0025148] after LocalModelPiece::Draw() glCallList(dispListID); OpenGL Error: invalid operation

Mesa: User error: GL_STACK_OVERFLOW in glPushAttrib
[f=0025616] after selectedUnits.DrawCommands(); OpenGL Error: stack overflow

Mesa: User error: GL_INVALID_OPERATION in Inside glBegin/glEnd
Mesa: 411 similar GL_INVALID_OPERATION errors
Mesa: User error: GL_INVALID_OPERATION in glBegin
[f=0025619] after sky->DrawSun(); OpenGL Error: invalid operation

Mesa: User error: GL_STACK_OVERFLOW in glPushAttrib
[f=0025810] after featureDrawer->DrawFadeFeatures(noAdvShading); OpenGL Error: stack overflow

conclusion: lot's of problems inside display lists. Only god knows how to fix them. Looks like we need to compile mesa with debug symbols and use "void
mesa_print_display_list(GLuint list)" function from ./src/mesa/main/dlist.c

How to use it? I have no idea.

glGetFramebufferAttachmentParameterivEXT
located in FBO::DownloadAttachment(const GLenum attachment)

and used:
for(int i = 0; i < 15; ++i) {
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + i);
}

why ++i? what will be generated as result?
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + 0);
...
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + 15);
???

According documentation:
http://wiki.delphigl.com/index.php/GL_E ... fer_object
there are from 0 to 15 inclusive.

GL_COLOR_ATTACHMENT0_EXT
GL_COLOR_ATTACHMENT1_EXT
GL_COLOR_ATTACHMENT2_EXT
GL_COLOR_ATTACHMENT3_EXT
GL_COLOR_ATTACHMENT4_EXT
GL_COLOR_ATTACHMENT5_EXT
GL_COLOR_ATTACHMENT6_EXT
GL_COLOR_ATTACHMENT7_EXT
GL_COLOR_ATTACHMENT8_EXT
GL_COLOR_ATTACHMENT9_EXT
GL_COLOR_ATTACHMENT10_EXT
GL_COLOR_ATTACHMENT11_EXT
GL_COLOR_ATTACHMENT12_EXT
GL_COLOR_ATTACHMENT13_EXT
GL_COLOR_ATTACHMENT14_EXT
GL_COLOR_ATTACHMENT15_EXT

I think that for loop should looks like:

for(int i = 0; i <= 15; i++) {
DownloadAttachment(GL_COLOR_ATTACHMENT0_EXT + i);
}

the same for:
FBO::DetachAll()
for(int i = 0; i < 15; ++i) {
Detach(GL_COLOR_ATTACHMENT0_EXT + i);
}

maybe I am wrong

0
1
...
14 !

PS: using post- or pre-increment operator doesn't make any _logical_ difference in for-loops increment part (still pre-increment produces more efficient code with non-native vartypes).

theoretically, yes, but aren't compilers allowed to optimize? (i've been told they do for most stl iterators and such)

jK,

can you fix and commit this? CommandDrawer.cpp -> glPolygonMode(GL_FRONT_AND_BACK, GL_LINES);


So that means that "GL_COLOR_ATTACHMENT15_EXT" will be ignored? It's not a bug and works by design?

interesting info for nvidia and amd video:

A new development area through OpenGL debugging (GL_ARB_debug_output)
http://www.g-truc.net/post-0320.html