Also, I notice there is a “glMapBufferARB” which is not documented – which one should I use? (altho they both return this warning, the “pointer” is always NULL/0, and I always get a GL_INVALID_OPERATION).
And variations involving the ARB suffix that all cause the same issue.
I am guessing there is a problem with library, since pretty obviously it is supposed to be of type GLvoid*. Never seen this before. I’m going to try compiling this on a different system now I guess.
Yeah, the buffer was created and contains data. The object it describes is rendered fine.
Subsequently, I want to modify the data, which I take it that is what glMapBuffers() was for.
Even if that were the problem, it does not explain why a function typed to return a void* is, according to the compiler, only going to return an int.
I am presuming that the object files do not match my headers (well, they obviously do not, apparently ATI installed the libraries, but all /usr/include files are older, I guess from the base mesa install).
It’s a 2.0 card. Should I file a bug with ATI? This is just wrong – if I could find some example code with MapBuffer() in it I could try that, so far all I’ve found is some ES related stuff.
Okay, the “invalid operation” was because I did not unmap the buffer. But that still does not correct the problem.
A pointer is being returned, but it’s address looks very low and it does not have anything valid attached to it, ie, trying to access anything produces a segfault.
The context is like this: in the render loop, every hundred frames I try to map the buffer after I bind it, make a few changes, then unmap and DrawArrays.
According to the spec, a GL_INVALID_OPERATION error from mapping a buffer is due to the buffer already being mapped.
Even if that were the problem, it does not explain why a function typed to return a void* is, according to the compiler, only going to return an int.
That is an issue you should take up with your header file. You, or a library you are using, loaded that function pointer into a variable. Check the type of that variable.
I don’t really follow you here – could you explain a little further?
Anyway, here’s what fixed this. I noticed I would get “implicit declaration” warnings for using any ARB suffixed function*, which can indicate a missing prototype.
Looking thru glext.h, I noticed those are all wrapped in
#ifdef GL_GLEXT_PROTOTYPES
So I added “#define GL_GLEXT_PROTOTYPES 1” to the top of my code, and those warning disappeared.
I put glMapBuffer back in, exactly as before and now it works. If I remove the define, I again get:
warning: assignment makes pointer from integer without a cast
and a segfault trying to access anything returned by glMap.
So, obviously those functions are in the library object files, but GL_GLEXT_PROTOTYPES is not being defined in any header. Is this just a property of mesa, or should it be defined in glATI.h?
*actually, this is also true for those same functions w/o the ARB suffix
Yes, or copy/paste the prototype into your code directly, which is an ugly and non-portable solution.
By default in old C, functions return int unless you say otherwise. That likely explains some of the previous results you were getting without a prototype.
That define causes glext.h to pull in proper prototypes for GL functions so that your compiler can type-check function arguments and return value types correctly.