Therein lies the problem we’re all struggling with. Expect gl3 to do nothing to resolve this flaw of OpenGL.
The solution is to use d3d on windows, and have limited support on linux/osx through opengl and shoddy drivers. It would be an exercise in silliness to use GL on windows, unless you need quad buffered stereo and/or genlock support.
Today there are tons of famous application working with opengl on windows and I wish you could make the money their owner made doing the silly thing of using OpenGL on windows.
By the way the solution exist because other can do this. So please help me to find it.
The SolidWorks software will typically detect an unsupported graphics card and automatically enable “Software OpenGL” mode. This mode reduces the demands on the graphics hardware and driver, resulting in increased stability but decreased performance (slow/choppy).
This is exaclty what we want to achieve. I found many resources on how to understand what OpenGL implementation is used but not on detecting and switching to the more convenient.
Create a GL context, if the vendor string includes something like “intel” then discard this context, and recreate the window with a software context. I hope you understand that MS software GL implementation is practically non-usable in all meaningful scenarios though?
If that is really what you want to do (detect Intel) and run in software, I suggest getting Mesa from mesa3d.org and somehow shutdown your program, move that opengl32.dll into your folder, run your app.
At least you get GL 2.1 software renderer this way.
very few that run on wintel, and pretty much zero that use features from any recent gl revision.
if you don’t want to accept advice then that’s up to you, but at least thank me for replying to you, you ungrateful tosser.