Hi all,
I recently ran into some trouble trying to get GLEW working in SFML.
Currently the SFML libraries are static, and the GLEW library is dynamically linked- with a DLL in beside the .exe, is this correct?
The problem is that when I try and use any of the GL extensions I get an access violation error:
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "Test", sf::Style::Default, sf::ContextSettings(32));
glewExperimental = GL_TRUE;
GLenum glewErr = glewInit();
if (glewErr != GLEW_OK)
std::cout << "GLEW not OK...";
else
std::cout << "GLEW is OK...";
if (!GLEW_ARB_vertex_buffer_object)
{
std::cout << "Not supported...";
}
unsigned int temp = 0;
glGenBuffers(1,&temp); // Access violation reading '0x000...'
Visual C++ throws an access violation error at the glGenBuffers line.
Most similar problems I see online are because of omitting 'glewInit()', or 'glewExperimental = GL_TRUE'.
Is it possibly a problem with the way I have set up GLEW?
(glewInit returns GLEW_OK, and by using glGetString(GL_EXTENSIONS) [or something] I am sure that my drivers support VBOs, they are part of the standard anyway aren't they?)
Any help would be much appreciated,
thanks.
Okay, thanks for the reply :).
I reverted back to the static glew32s.lib library, and I moved glewInit() to the very top of main().
However, VC++2010 complains that:
1>sfml-graphics-s-d.lib(glew.obj) : error LNK2005: ___glewCopyTexSubImage3D already defined in glew32s.lib(glew.obj)
1>sfml-graphics-s-d.lib(glew.obj) : error LNK2005: ___glewDrawRangeElements already defined in glew32s.lib(glew.obj)
... (about a few hundred similar lines)
This is the problem I had with the static library before: SFML hides GLEW enough that we aren't allowed to use it, but not enough that we can run our own copy as well...?
What do you think?
Edit
I tried *not* linking and including the glew32s.lib library- I thought since SFML has included the GLEW library already it is pointless. This seems to work, and the duplicate object errors are not there- however glGenBuffers is still 0x00...
Also, now glewInit() is an unresolved external symbol. I think that maybe that SFML will do this to stop it being called twice, as it is called as part of the SFML load-up? However as I said glGenBuffers is still null...