I just solved a really hard bug today at work. I was receiving the error GL_INVALID_OPERATION on a glEnd() or glDrawBuffers. This was due to one of our textures that was not unbound to the correct target. We had a 2D texture that was bound to the unit 0 at the target GL_TEXTURE_2D. Then later, we had another texture bound also at unit 0 but in target GL_TEXTURE_3D. This was the cause of the problem. If you do this:
glBindTexture(GL_TEXTURE_3D, texture2); // PROBLEM
It will raise a GL_INVALID_OPERATION. The correct way to do is:
// some code
glBindTexture(GL_TEXTURE_2D, 0); // unbind the texture
If you look at the official documentation of glBindTexture, nothing explains that not unbinding the texture in the previous target will raise this error. I think they should be more specific on this issue.
And the really bad thing is, you will have a GL_INVALID_OPERATION only if you use the associated unit and when you order the drawing with glEnd() or glDrawArrays which is in a totally different place in my program, so going back to the origin of the problem is really painful and long.
Personnally I would prefer an error directly when I try to bind to a different target and I didn’t yet unbound to the previous target… Or even better, just forget about the previous target and the new target just override it. At least it would have saved me two days…
I just discovered that the Runtime-time Type Information in C++ using Visual C++ 2008 was not behaving like I was expecting in some specific scenarii. One of the side effect I had was that a dynamic_cast was returning NULL instead of the object as it should be.
You need to put a file named xchat.protocol in /usr/share/kde4/services that contains:
exec=xchat --existing --url=%u
It can works for other irc clients, just change the name to yours and maybe a little bit the command line 🙂
In fact, if you have something that use xdg-open to try to open a link or an url, it will look up the protocol or mime type and try to find if there is any services attached to the protocol or applications to the mime type. An application usually describes the mime types it can read in its .desktop file (same folder as the protocol files).
Same post as before, no opencl libraries available for mingw32. So here they are:
I found the instructions to do them here:
I was really suprised that the official glew website was not giving directly a compiled version of glew for mingw. So here they are:
For those who want to know my workflow:
– download glew and edit the config/Makefile.mingw to have unix end of line
– download the Qt SDK to have a mingw32 distribution
– download cygwin to have a bash
– open a cygwin bash and do these commands (edit to your needs):
# go to your glew folder
cd /cygdrive/c/Users/Julian\ Ibarz/code/glew-1.5.4
# set in the path your mingw distribution
# compile glew