Okay, so I already know why I need GLEW, but only up to a point.
If I am using modern OpenGL stuff, probably from version 3.0 onwards, and/or am using the Core Profile, then GLEW is required as without it compilation produced error such as glGenVertexArrays
was not declared.
So GLEW does a bit of background work including the modern OpenGL functions we would like to use, probably.
Apart from that, does it do anything else? Also, how does it work.
As an example, does it improve cross-platform compilation? (Require less modifications to code if moving from Linux to Windows or OS X for example?
Does it also improved the "cross-platform-ness" of graphics hardware? For example, say we had two identical computers, including the OS. A program is compiled using OpenGL 4.3 commands on one system. If the other system has a graphics card or driver which only supports OpenGL 3.3, does GLEW help with that? (Compiling shaders for an older version of OpenGL, perhaps?)
So you can probably see I don't actually know what GLEW does or how it does it.
One last point; does anyone know how to use GLEW with GLFW? I might post that as a separate question actually.
It allows you to check at runtime which extensions are present and which functions may be used.
To answer the question "Which one should I use?" -- in any case you want to use GLEW (or an alternative, but GLEW works fine), but you most likely want to use both GLEW and GLFW since it makes your life easier.
If you are using an OpenGL extension loading library such as GLEW, the GLEW header should also be included before* the GLFW one. The GLEW header defines macros that disable any OpenGL header that the GLFW header includes and GLEW will work as expected.
GLFW and freeglut are alternative for us according to our need we can choose any one but GLEW is different from them which is used for run time loading of the OpenGL API.
GLEW isn't 'required', as you put it. You could use glcorearb.h header, or anything like that. However, if you link with some function - it must exist on target platform, or your program wouldn't launch. GLEW and others are exactly to handle that - you're not linking with GL functions directly, but instead getting function pointers after initialization phase. It allows you to check at runtime which extensions are present and which functions may be used.
The only thing it helps with portability is getting function pointers - it may be wglGetProcAddress/glxGetProcAddress and it's analog for apple OSes. So no, it's not a case. However, the variety of available GL extensions is.
GLEW requires no touch points with your preferred GL initialization library - just call glewInit after creating GL context.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With