Question

I am trying to create a 3D environment simulator of my own design using OpenGL, however my design requires me to have pretty much direct control of the run-time loop.

I am trying to learn how to implement VBOs in OpenGL, but I’m having difficulty finding adequate resources. From my findings, just about everyone uses FreeGLUT or GLEW or GLFW or GL3.h in some way to get around some of the platform-specific issues.

While these options may be great, I simply don’t want to use other people’s packages for this code. I would like to figure out how to use VBOs using the standard, vanilla OpenGL that comes out of the box on most machines. I could use some help looking for tutorials for VBOs in OpenGL that don’t use any of these external packages.

…And before anyone suggests it, the NeHe lesson 45 about VBOs uses depreciated code (glaux) that doesn’t even compile anymore, so that’s not an option. :\

Edit: Maybe i wasn’t being clear, or I’m being trolled, whatever…the point of the question was to find examples, tutorials, or other resources that teach VBOs in OpenGL that DO NOT RELY ON THESE ADDITIONAL PACKAGES. Seriously people, telling me to “give up” or “just use GLEW”…that’s not helping.

Answer 1

The way you use VBOs is in no way different when using GLUT or GLFW and it doesn’t matter if you load the function pointers manually (why would you do this in the first place? That’s masochism, yes it can be done… but why should you?) or use a wrapper like GLEW.

I think you need your concepts right what GLUT, GLFW and GLEW actually are.

GLUT (old, Free… and Open…) and GLFW are frameworks: They create a window prepare it for attachment of OpenGL contexts, create an OpenGL context and then give control back to you (more or less). GLUT takes over the event loop. GLFW asks you for implementing a event loop. You can of course do the whole setup yourself. But if you do this, you need to have your feet firmly on the ground when it comes to he low level APIs of the underlaying operating and graphics systems. Better use a framework. You’re not limited to GLUT or GLFW, there are others too: Qt, GTK+, SDL, SMFL, FLTK, wxWidgets, Fox Toolkit to name a few.

GLEW is a extension and function pointer loader library, taking care of the (really) gruesome details. opengl32.dll or libGL.so expose only a very small subset of all the functions offered by later versions of OpenGL. All the advanced stuff must be dynamically loaded at runtime. That’s what GLEW is for, because doing it manually really sucks.

None of them has anything to do with VBOs at all! If you thought that, you had some serious misconception.

---

Update due to request:

So how do you load extensions manually. Well, this is really nasty. First you must define the required function pointers in your source code. To help you with that, the ARB released a header files called glext.h. In this you can find lines like those

typedef void (APIENTRYP PFNGLBINDBUFFERPROC) (GLenum target, GLuint buffer);
typedef void (APIENTRYP PFNGLDELETEBUFFERSPROC) (GLsizei n, const GLuint *buffers);
typedef void (APIENTRYP PFNGLGENBUFFERSPROC) (GLsizei n, GLuint *buffers);
typedef GLboolean (APIENTRYP PFNGLISBUFFERPROC) (GLuint buffer);
typedef void (APIENTRYP PFNGLBUFFERDATAPROC) (GLenum target, GLsizeiptr size, const GLvoid *data, GLenum usage);
typedef void (APIENTRYP PFNGLBUFFERSUBDATAPROC) (GLenum target, GLintptr offset, GLsizeiptr size, const GLvoid *data);
typedef void (APIENTRYP PFNGLGETBUFFERSUBDATAPROC) (GLenum target, GLintptr offset, GLsizeiptr size, GLvoid *data);
typedef GLvoid* (APIENTRYP PFNGLMAPBUFFERPROC) (GLenum target, GLenum access);
typedef GLboolean (APIENTRYP PFNGLUNMAPBUFFERPROC) (GLenum target);
typedef void (APIENTRYP PFNGLGETBUFFERPARAMETERIVPROC) (GLenum target, GLenum pname, GLint *params);
typedef void (APIENTRYP PFNGLGETBUFFERPOINTERVPROC) (GLenum target, GLenum pname, GLvoid* *params);

those provide you types for the function pointers. So you include glext.h into your extension loader module

#include "myextensionloader.h"

And then for every f***ing function you intend to use you define a function pointer variable. But here’s the important thing: Those variables are part of your program, thus you must limit them into your own namespace; you can’t just use names that may be present otherwise. So they won’t be called gl… but something like PROGRAMNAME_PRIVATE_gl….

PFNBINDBUFFERPROC myprogram_PRIVATE_glBindBuffer;
PFNDELETEBUFFERPROC myprogram_PRIVATE_glDeleteBuffer;

… and so on. You really want to do this with the huge set of functions later versions of OpenGL have?

Actually, that’s not even completely correct for the case of Windows, as OpenGL function pointers are tied to the OpenGL context active. Multiple OpenGL contexts in different threads being active at the same time => recipe for disaster. Those function pointer variables actually belong into thread local storage.

Then you add a function pointer loader, which for every OpenGL function required loads it

void load_extension_function_pointers()
{

#ifdef USE_WGL
#define GETGLPROCADDRESS(name) (wglGetProcAddress(name))
#else ifdef USE_GLX
#define GETGLPROCADDRESS(name) (glXGetProcAddress(name))
#endif

#define LOAD_POINTER(name) myprogram_PRIVATE_##name = GETGLPROCADDRESS(#name)

    LOAD_POINTER(glBindBuffer)
    LOAD_POINTER(glDeleteBuffer)
}

Anyway, now you want to make this available to other modules. So you have a header file myextensionloader.h which you use to include glext.h, supply your function pointer varaibles as externs to the rest of your program and have a large set of C preprocessor macros that pretty-name your private function names into OpenGL function names:

#pragma once
#ifndef MYEXTENSIONLOADER_H
#define MYEXTENSIONLOADER_H

#include <GL/gl.h>
#include <GL/glext.h>

extern PFNBINDBUFFERPROC myprogram_PRIVATE_glBindBuffer;
#define glBindBuffer myprogram_PRIVATE_glBindBuffer;
extern PFNDELETEBUFFERPROC myprogram_PRIVATE_glDeleteBuffer;
#define glDeleteBuffer myprogram_PRIVATE_glDeleteBuffer;

And this scheme still misses some details: In Windows the function pointers are actually tied to the active OpenGL context, so technically you need to somehow override wglMakeCurrent to update all the function pointers when the context is switched. And since different OpenGL contexts can be active in different threads those function pointers actually ought to be in thread local storage (TLS) to be correct. GLX is much more sane, but still you might be running on a machine with multiple X servers on different GPU vendors, so you’ve to cope with different libGL.so and libGLX.so and what can bite you there.

You really want to take care about all of this yourself? If you are the only user of that code, why? Really why? The process of writing all this is so tedious that the maintainers of GLEW never wrote any line of the actual GLEW library themself. What they did was writing a code generator that automatically produces the library source code from the specification files.