PDA

View Full Version : my "glMapBuffer" does not return pointer?



akashiraffee
12-18-2009, 04:44 PM
I get

warning: assignment makes pointer from integer without a cast

for


GLvoid *ptr = glMapBuffer(GL_ARRAY_BUFFER,GL_READ_WRITE);


Is my library screwed up? :lol: The prototype is there in glext.h:

GLAPI GLvoid* APIENTRY glMapBuffer (GLenum, GLenum);

Like, WTF???

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

Just to be clear, the call is like this:


glBindBufferARB(GL_ARRAY_BUFFER_ARB, obj.ID);
ptr = glMapBufferARB(GL_ARRAY_BUFFER_ARB,GL_READ_ONLY);

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.

akashiraffee
12-18-2009, 04:51 PM
Same problem on both FC-10 64-bit and Ubuntu 32-bit, altho it's the same machine using the same ATI drivers.

Alfonse Reinheart
12-18-2009, 05:03 PM
Well, did you allocate the memory buffer with glBufferData first?

akashiraffee
12-18-2009, 05:34 PM
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.

akashiraffee
12-18-2009, 06:03 PM
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.



GLfloat *ptr;
[...]
glBindBufferARB(GL_ARRAY_BUFFER_ARB, BGround.ID);
if (change) {
ptr = glMapBufferARB(GL_ARRAY_BUFFER,GL_READ_WRITE);
// printf("%p %f\n",ptr,ptr[0]); fflush(stdout);
glUnmapBufferARB(GL_ARRAY_BUFFER);
}
glColorPointer(4, GL_FLOAT, 0, BUFFER_OFFSET(36*sizeof(float)));
glNormalPointer(GL_FLOAT, offset2, BUFFER_OFFSET(offset2/2));
glVertexPointer(3, GL_FLOAT, offset2, BUFFER_OFFSET(0));
glDrawArrays(GL_QUAD_STRIP,0,6);


Everything works fine except for the glMapBufferARB() bit -- and if I uncomment the printf, accessing ptr[0] causes a segfault.

Alfonse Reinheart
12-18-2009, 06:48 PM
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.

akashiraffee
12-19-2009, 10:17 AM
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

Dark Photon
12-19-2009, 12:46 PM
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.
This is proper behavior. In fact, if you always want prototypes for everything GL, this is the proper mantra:


#define GL_GLEXT_PROTOTYPES 1
#define GLX_GLXEXT_PROTOTYPES 1
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glx.h>


If you don't need GLU and/or GLX bits, then of course you don't need to include them.

And this:

* http://www.opengl.org/registry/api/glext.h

is of course a link to the gold-standard glext.h. Your file should match this one, or be an earlier version of it.

akashiraffee
12-19-2009, 05:00 PM
This is proper behavior. In fact, if you always want prototypes for everything GL, this is the proper mantra:

Is it also normal that in order to make use of glMapBuffer() I would have to include the same #define?

Dark Photon
12-20-2009, 07:26 AM
Is it also normal that in order to make use of glMapBuffer() I would have to include the same #define?
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.