Buffer Objects causes run-time AV

hi,

I 've strange issue, any call to buffer objects (e.g. glIsBuffer, glGenBuffers ) causes the access violation. I’ve glut 3.7.6 and glew -1.5.8 properly installed and required files are placed in the folder ( same as glut folder procedure for glew files ). One more weird thing is ctrl+space invokes the code completion and I can iterate through buffer functions glIsBuffer, glGenBuffers, glBindBuffer, etc… (is that a proof that glew loaded properly?) but codeinsight doesn’t give a hint about its arguments after putting the paranthesis "glGenBuffers( ". Seems that I’m refering to unallocated/unitialized objects, but couldn’t figured out what and where?

include <GL/glew.h>
#include <GL/wglew.h>
#include <GL/glut.h>

#define VERTICES 0
#define INDICES 1
#define NUM_BUFFERS 2
GLuint buffers[NUM_BUFFERS];

void init(void)
{
glGenBuffers(NUM_BUFFERS, buffers); // debugger fires AV 

// code omitted here 
}

Did you remember to call glewInit? And if so, is it after you’ve created your context?

No, even if add it, still the same error.
I played around with putting glewInit on possible places for a while w/o success.

I’m not literate about glut functionality where it initializes PFD, rendering context etcc… but I’ve even tried to put it in “display” function where it should be the last place, still the same error.

Code is :

#include <GL/glew.h>
#include <GL/wglew.h>
#include <GL/glut.h>

#define VERTICES 0
#define INDICES 1
#define NUM_BUFFERS 2
GLuint buffers[NUM_BUFFERS];

void display(void)
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

glColor3f(0,0,1);
glutSolidTeapot(0.5);

glutSwapBuffers();
}

void init(void)
{
glewInit();
glGenBuffers(NUM_BUFFERS, buffers); // debugger fires AV

glLightfv(GL_LIGHT0, GL_DIFFUSE, light_diffuse);
glLightfv(GL_LIGHT0, GL_POSITION, light_position);
glEnable(GL_LIGHT0);
glEnable(GL_LIGHTING);

glEnable(GL_DEPTH_TEST);
glEnable(GL_COLOR_MATERIAL);

/* Setup the view of the cube. /
glMatrixMode(GL_PROJECTION);
gluPerspective( /
field of view in degree / 40.0,
/
aspect ratio / 1.0,
/
Z near / 1.0, / Z far / 10.0);
glMatrixMode(GL_MODELVIEW);
gluLookAt(0.0, 0.0, 5.0, /
eye is at (0,0,5) /
0.0, 0.0, 0.0, /
center is at (0,0,0) /
0.0, 1.0, 0.); /
up is in positive Y direction */
}

int main(int argc, char **argv)
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
glutCreateWindow(“red 3D lighted cube”);
glutInitWindowPosition(300,300);
glutInitWindowSize(500,500);
glutDisplayFunc(display);
init();
glutMainLoop();
return 0;
}

http://www.opengl.org/wiki/FAQ#How_do_I_tell_what_version_of_OpenGL_I.27m_using.3F

Yeah, this. You generally can’t just assume that functionality is available on all hardware; you need to check for and confirm it first.

So at the very least add something like this to your init function:

if (!GLEW_ARB_vertex_buffer_object)
   throwBigScaryErrorFunction ();

So at the very least add something like this to your init function:

Code:if (!GLEW_ARB_vertex_buffer_object)
   throwBigScaryErrorFunction ();

It always enters that “throwBigScaryErrorFunction ()”, so that means I don’t have vertex buffer support in my hardware ?

It always enters that “throwBigScaryErrorFunction ()”, so that means I don’t have vertex buffer support in my hardware ?

Now, to be fair, ARB_vertex_buffer_object is not really an extension that needs to be exposed. The functionality has been core since about GL version 1.4 or at least 2.0. It’s possible (though not likely) that the core feature should be available.

That being said, according to the OpenGL extension viewer’s database, pretty much everything supports ARB_vertex_buffer_object. Intel chipsets, GeForce 2’s, cards that haven’t been produced for near on a decade, everything. So more than likely, you’re not getting an accelerated rendering context.

You seem to have needlessly ignored the sage advice V-man gave you in finding out what OpenGL version you’re getting. You should find out.

Thanks in advance,

version = “1.4.0 - Build 7.14.10.4926”
vendor = “Intel” (945/m chipset) AFAIR

I thought that I 've the latest driver installed and latest openGl version.

ARB_Vertex_Buffer_Objects was made core in version 1.5
I see your GL version is 1.4, so there is a good chance that VBOs are not suppoorted by the h/w.
Have you actually queries the list of supported extensions by the GL context your self, or have you just relied upon some 3rd party?

I would trust glew here, but if you still have a doubt, check extensions this way (like BionicBytes said):


glGetString(GL_EXTENSIONS);

If you cannot see GL_ARB_vertex_buffer_object, then definately, it is not supported (at least with this driver).

Returned by
extns = glGetString(GL_EXTENSIONS);

It seems that I’ve GL_ARB_vertex_buffer_object support but why it keeps crashing?

GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_multitexture GL_ARB_point_parameters GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_env_crossbar GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object[/b] GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_cull_vertex GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_lod_bias GL_EXT_texture_filter_anisotropic GL_EXT_texture3D GL_3DFX_texture_compression_FXT1 GL_IBM_texture_mirrored_repeat GL_NV_blend_square GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_WIN_swap_hint

Just tested some on an Intel 945 here.

You need to use the -ARB versions of the entry points with this part; i.e. glGenBuffersARB and friends.

Worth noting also that the 945 is a software T&L part and will be emulating VBOs in software; not much point in using VBOs with this one really.

that’s it thank you all,

Worth noting also that the 945 is a software T&L part and will be emulating VBOs in software; not much point in using VBOs with this one really.

Absolutely right, my aim is just to get familiar with buffer issue and to study the codes.