I have a game that uses SDL2 and OpenGL 3.3 with Visual Studio. It runs fine on the computer that built it, but it did not work on other Windows computers.

Initially, it would complain about missing DLLs from the VC++ runtime. I solved the first issue by statically linking the runtime libraries into the EXE.

However, the second issue was that the program freezes right before it could call OpenGL functions to generate vertex buffer and vertex array objects. Of note, not all of the OpenGL functions freeze the program, since glClear appears to work.

I then noticed that some computers with dedicated graphics cards and up-to-date drivers can successfully play the game, but the computers with integrated graphics cards such as Intel HD 4000 still froze up in the same place. This is puzzling, since the specifications for Intel HD 4000 state that OpenGL 3.3 should be supported.

The computers I have tested with all managed to generate an OpenGL context with SDL2 and load OpenGL functions with GL3W without any errors, though some of the unsuccessful ones had a zero-bit depth buffer.

Does anyone know what might be causing the issue?

  • \$\begingroup\$ This is all a little vague. I'm not convinced that Intel or integrated graphics has anything to do with your problem. It sounds like you have some sort of memory stomper that's just affecting things differently depending on the computer configuration it's running on. Have you done static analysis on your source code? Have you run it with a memory watching tool? I recommend doing those things first. \$\endgroup\$ May 28, 2018 at 23:52
  • \$\begingroup\$ I rolled back your edit since it was no longer needed because you have added an answer about it. \$\endgroup\$
    – Vaillancourt
    May 29, 2018 at 2:49

1 Answer 1


After I gave my rendering code another look, I noticed that I was using glCreateVertexArrays and glCreateBuffers instead of glGenVertexArrays and glGenVertexBuffers.

While they do the same thing, glCreateVertexArrays and glCreateBuffers were introduced in OpenGL 4.5, which is why my program choked on hardware that did not support that version of OpenGL. Since I am targeting OpenGL 3.3, that is a problem.

After replacing those two function calls, my code runs on the Intel graphics cards just fine.

  • \$\begingroup\$ Yes, the HD4000 gpu is very limited, as you will discover. One other limitation is that it can have no more than two active texture units at any time \$\endgroup\$
    – Ian Young
    May 29, 2018 at 12:03
  • \$\begingroup\$ @IanYoung - sorry, but that's absolute nonsense. The HD 4000 supports full Direct3D 11 and OpenGL 4.0, has GL_MAX_TEXTURE_UNITS 8 and GL_MAX_TEXTURE_IMAGE_UNITS 16. It can also run Doom 3 at 60fps. Please don't comment unless you know what you're talking about. \$\endgroup\$ May 29, 2018 at 16:14
  • \$\begingroup\$ Sorry my mistake, I was thinking about the HD3000 hardware, in which the value of GL_MAX_TEXTURE_IMAGE_UNITS is 2. Thank you for pointing out my error. \$\endgroup\$
    – Ian Young
    May 30, 2018 at 8:15
  • \$\begingroup\$ @IanYoung - opengl.gpuinfo.org/displayreport.php?id=345 - Intel HD 3000 has 16 for GL_MAX_TEXTURE_IMAGE_UNITS. \$\endgroup\$ Oct 23, 2018 at 16:38
  • \$\begingroup\$ @MaximusMinimus That's not the value my laptop got. I could create up to 16 texture units, but I could not bind more than two per shader execution. \$\endgroup\$
    – Ian Young
    Oct 24, 2018 at 11:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .