PDA

View Full Version : Starting opengl



mnfisher
07-06-2008, 02:05 PM
I'm probably going at this all wrong, but new to this, so don't be too hard - I'm just trying to start out using examples from OpenGLDistilled. I find that the gl.h with Visual C++ Express is old, and I cannot get samples to work. (Gl.h with Borland even older)

I seek a newer version - ATI's website instructs me to download an upto date version from opengl.org. Not easy to find here though? Can anyone point me to a recent version of gl.h glext.h and relevant libraries. I also tried using a version from a linux install (1.5)
Have struggled to get freeglut to compile both on windows and linux - failed, so gave up and just opened a native window with opengl support(success here) I wanted to try vertex buffers,
my first compilations give an unresolved reference to InitVert. All suggestions welcome

Many thanks
Martin

T101
07-06-2008, 10:38 PM
Odd that ATI would refer you to this site. I've never found those here either.

I think you should really be getting those headers from ATI, but you could try Mesa's headers.
Something compiled with the headers from one GL implementation should work with another GL implementation.
Of course with Windows you'll still have to use the extension mechanism to access a lot of functions, since the common dll only exposes OpenGL 1.1 functions.

V-man
07-06-2008, 11:08 PM
Something compiled with the headers from one GL implementation should work with another GL implementation.
GL implementations do not have headers. Compilers have headers.


I find that the gl.h with Visual C++ Express is old
So what if it is old? Everyone uses them. It exposes GL 1.1 functionality.


I cannot get samples to work
Post error messages given by your compiler.


my first compilations give an unresolved reference to InitVert. All suggestions welcome
Unresolved means InitVert is not defined. It needs to be defined so that the compiler can decide what to do.

mnfisher
07-06-2008, 11:37 PM
I'm still confused.. GetVersion(GL_VERSION) returns 2.1.7415Release. I thought this related to the version of opengl32.lib installed. I could use version 1.1 headers, but the book implies that use of glBegin()....glEnd() is deprecated in favour of using glMultiDrawElements() etc which are defined from with version >1.5. Presumably everyone doesn't still use the old headers?
Trying to get the sample code from the book to compile, I used gl.h and glext.h from a linux distro (Fedora9) - which does define these API calls. The linker gave the errors:

1>ogltest.obj : error LNK2001: unresolved external symbol __imp__glBufferData@16
1>ogltest.obj : error LNK2001: unresolved external symbol __imp__glBindBuffer@8
1>ogltest.obj : error LNK2001: unresolved external symbol __imp__glGenBuffers@8

so I need a newer version of opengl.lib and/or I need to link against another library file as well.
GL implementations do have headers - at least to be of any use - since these expose the programming interface to users..
So, the question stands. Where to download a recent version of gl.h (I have a recent glext.h - but is there an official repository) and the relevant libraries to link against (opengl.lib, glu.lib etc)

Thanks again
Martin

dletozeun
07-07-2008, 12:29 AM
The linker errors you get doesn't mean the gl header is too old. you have to get all extensions function call entry-points manually form the driver.
You can find more information here:

all about OpenGL extensions (http://www.opengl.org/resources/features/OGLextensions/)

or you can use some libraries that do it for you like glew.

dletozeun
07-07-2008, 12:54 AM
On Fedora you will have to check the extension string to find ARB_vertex_buffer_object:


extension.c:


PFNGLBUFFERDATAPROC glbufferData;

char *ext = (char*)glGetString( GL_EXTENSIONS );
if( strstr( ext, "ARB_vertex_buffer_object" ) == NULL )
{
cout<<"ARB_vertex_buffer_object extension is not supported"<<endl;
}
else
{
glBufferData = (PFNGLBUFFERDATAPROC)glXGetProcAddress(GLubyte*) "glBufferData");
}


extension.h


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

extern PFNGLBUFFERDATAPROC glbufferData;


And then do it for all VBO functions.

T101
07-07-2008, 01:59 AM
GL implementations do not have headers. Compilers have headers.
Sorry for nitpicking, but compilers use headers. Depending on your compiler it may or may not have the necessary headers installed by default.
The Visual C++ compiler probably has OpenGL headers installed by default, but updated headers (at least glext.h) can be installed.
E.g. in order to compile OpenGL stuff on Linux you can use the headers installed by the nVidia driver, or you can add one of the mesa...-devel packages. And I presume that if you have the ATI driver the Mesa headers are installed.

My point was that it should not matter which of those you use. I'm pretty certain you (V-man) know all that, but it might confuse newcomers.



the book implies that use of glBegin()....glEnd() is deprecated in favour of using glMultiDrawElements() etc

I'm not sure which book you're talking about, the 2.1 Red Book happily uses glBegin and glEnd in its examples.

Performance of the array functions is much better, but that does not mean you cannot use glBegin/glEnd anymore. Even if you at some point switch fully to arrays, direct mode is great for experimenting.

If and when GL3 drivers come available, GL2 support and therefore direct mode will be around for many years simply because the driver makers cannot afford to break compatibility with older applications.

As far as updated headers are concerned, you'll probably need to use headers suitable for the OS. At least as far as name mangling is concerned, you probably cannot use Linux OpenGL headers with Windows.
But I would again suggest that you go check out the Mesa site, since Mesa is available multiple platforms.

V-man
07-07-2008, 05:17 AM
'm still confused.. GetVersion(GL_VERSION) returns 2.1.7415Release. I thought this related to the version of opengl32.lib installed.

glGetString(GL_VERSION) returns 2.1.7415Release?
This is the GL version of your video cards own drivers, NOT opengl32.dll
opengl32.dll belongs to Windows and it is at GL 1.1 on Win98 to WinXP, GL 1.4 on Win Vista.

2.1.7415 means GL 2.1 and the rest is some driver version thing we don't care about.


On Fedora you will have to check the extension string to find ARB_vertex_buffer_object:


extension.c:


PFNGLBUFFERDATAPROC glbufferData;

char *ext = (char*)glGetString( GL_EXTENSIONS );
if( strstr( ext, "ARB_vertex_buffer_object" ) == NULL )
{
cout<<"ARB_vertex_buffer_object extension is not supported"<<endl;
}
else
{
glBufferData = (PFNGLBUFFERDATAPROC)glXGetProcAddress(GLubyte*) "glBufferData");
}


extension.h


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

extern PFNGLBUFFERDATAPROC glBufferData;


And then do it for all VBO functions.

That's bad idea. If GL_ARB_vertex_buffer_object is present you should use glBufferDataARB.
You can only use glBufferData if glGetString(GL_VERSION) returns 1.5 and above.

dletozeun
07-07-2008, 07:57 AM
You can only use glBufferData if glGetString(GL_VERSION) returns 1.5 and above.


Yes, it is necessary to check GL_VERSION too.
That is why I prefer use tools like glew to do it automatically.