View Full Version : my "glMapBuffer" does not return pointer?
akashiraffee
12-18-2009, 03: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, 03: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, 04:03 PM
Well, did you allocate the memory buffer with glBufferData first?
akashiraffee
12-18-2009, 04: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, 05: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, 05: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, 09: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, 11:46 AM
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, 04: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, 06: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.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.