View previous topic :: View next topic |
Author |
Message |
MM
Joined: 13 Jun 2006 Posts: 60
|
Posted: Sun Mar 22, 2009 6:09 pm Post subject: wrong version with glGetString(GL_VERSION) |
|
|
I must be doing something wrong again :/
The following code outputs:
1.1.0
Microsoft Corporation
11
Error: Access Violation
Code: |
// in main.d
static this()
{
DerelictGL.load();
DerelictSDL.load();
if (SDL_Init(SDL_INIT_EVERYTHING) < 0)
{
throw new Exception("Failed to initialize SDL: " ~ getSDLError());
}
init.SDLGLWindow();
writefln( toString(glGetString(GL_VERSION)));
writefln( toString(glGetString(GL_VENDOR)));
try
{
DerelictGL.loadVersions(GLVersion.Version20);
}
catch(SharedLibProcLoadException slple)
{
throw new Exception("OpenGL 2.0 failed to load ");
}
writefln(DerelictGL.availableVersion());
}
|
It doesn't even throw an exception ?:/
When I ask for my openGL version from within a different program it says:
2.1.8201 |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Sun Mar 22, 2009 7:33 pm Post subject: Re: wrong version with glGetString(GL_VERSION) |
|
|
MM wrote: |
It doesn't even throw an exception ?:/ |
That's working as intended. Internally, the gl loader checks to see which version is reported by the driver before attempting to load the version you requested. If an SLPLE is thrown during loading, loadVersions will catch it and compare the requested version against what the driver reported. The exception is rethrown if the driver reports that the requested version is available, but not otherwise.
In other words, when you request version 2.0, the exception will only be thrown if the driver reports a version of 2.0 or greater. In your case now, the driver is reporting version 1.1, meaning 2.0 is not available anyway. So the exception is never thrown. It's probably better, on reflection, that loadVersions should always throw, since the user is requesting a specific version. EDIT: I've updated the trunk with this enhancement.
As to your actual problem, it's obvious that the default Microsoft driver is being loaded here and not the one from your hardware vendor. This usually happens when the selected pixel format is not supported by the gfx card driver for hardware acceleration. What parameters are you passing to the SDL_GL_SetAttribute function in SDLGLWindow()?
Also, what's your graphics card? That may shed some light on the problem. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
MM
Joined: 13 Jun 2006 Posts: 60
|
Posted: Sun Mar 22, 2009 8:43 pm Post subject: |
|
|
I agree about the throwing
And good to know that glGetString(GL_VERSION) doesn't report a system value but a openGL program connection.
thanks!
This seemed to be the problem:
SDL_GL_SetAttribute(SDL_GL_ACCELERATED_VISUAL, 1);
> Guarantee hardware acceleration (0 or 1)
Don't know what it does exactly. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Mon Mar 23, 2009 4:45 am Post subject: |
|
|
MM wrote: | This seemed to be the problem:
SDL_GL_SetAttribute(SDL_GL_ACCELERATED_VISUAL, 1);
> Guarantee hardware acceleration (0 or 1)
Don't know what it does exactly. |
When passing 1, this is *supposed* to guarantee that the pixel format for the window is one that can be accelerated by the graphics hardware. Meaning, you should not be seeing "Microsoft" returned by GL_VENDOR, or "1.1" by GL_VERSION, but whatever is reported by your graphics card drivers instead. My understanding is that it should fail if an accelerated format isn't returned. It's something you may want to take up on the SDL mailing list for clarification. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
fraz
Joined: 19 May 2008 Posts: 6
|
Posted: Thu Mar 26, 2009 9:06 am Post subject: |
|
|
From the SDL API wiki entry for SDL_GL_SetAttribute:
Quote: | This function sets the OpenGL attribute attr to value. The requested attributes will take effect after a call to SDL_SetVideoMode. You should use SDL_GL_GetAttribute to check the values after a SDL_SetVideoMode call, since the values obtained can differ from the requested ones. |
|
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Thu Mar 26, 2009 9:58 pm Post subject: |
|
|
Thanks, fraz, but that's not the issue. It's the behavior of SDL_ACCELERATED_VISUAL that is the concern here. I've looked to the SDL source for an answer, but it's not clear at all why he is getting a non-accelerated pixel format. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
fraz
Joined: 19 May 2008 Posts: 6
|
Posted: Fri Mar 27, 2009 10:51 am Post subject: |
|
|
After reading the previous posting I had the impression it wasn't clear how that function is supposed to work. My apologies if I was mistaken.
My guess is as good as anyone's when it comes down to solving the issue. Keep in mind that SDL_ACCELERATED_VISUAL appeared in 1.2.10. In my experience Windows users often pick these precompiled 3rd party DLLs from the first archive the find. So, check the used version unless you've already done so. |
|
Back to top |
|
|
|