SFML community forums
Help => Window => Topic started by: mercurio7891 on January 29, 2011, 04:27:54 pm
-
hi, I have a nvidia 8600 which can support opengl 3.3, however no matter what value i put as the value for the major, minor parameters in ContextSettings, it always create a opengl2.0 context instead.
Is there something I am missing out?
regards
-
How do you know that it's a 2.0 context?
-
After creating the window, I use window_.GetSettings() and check the version from there
-
I don't know if GetSettings calls this internally - but:
glGetString(GL_VERSION);
might give you another answer.
-
GetSettings gives you what was used to create the context, so if it says 2.0 it is 2.0. If you get that, it means that the extensions needed to create a 3.0 context were not found or didn't work. Are you sure that your driver supports it?
-
Yes my driver support it, I am using a nvidia 8600GT which support opengl 3.3. I have use the GPU caps viewer tool and have run their opengl 3.3 demo
http://www.ozone3d.net/gpu_caps_viewer/
-
Maybe you can debug a little bit inside SFML and see what's wrong? The relevant code is at the end of the Create function in src/SFML/Window/Linux/GlxContext.cpp.
-
Hi, Laurent, just wondering, did you update on the context creation part some time while ago??
This is because the current snap shot that I have is about 1-2 week ago, and I was thinking of confirming with you before I tinker around the source.
The link to the 2.0 snap shot seems down, so I can't really check it.
p.s I also found that the Antialiasing settings is not setting right, and I am running SFML on windows 7
regards
-
I haven't worked on this part for a long time, you can safely work with the revision that you have.
-
Hi, Laurent,
I think the problem is because there is no existing rendering context before the usage wglGetProcAddress. Since I think wglGetProcAddress requires an existing context before it can be used.
regards
-
There is an existing internal rendering context up even before you create a window.
If what you say was true, how come I get a 4.0.10151 Compability Profile context just fine? :)
-
I think the exisiting internal rendering context only apply if you create on the main thread. When I create my window on the main thread, it didn't have any problems. The problem only appear when I change all the window creation to run from a separate thread.
-
forgot to set the thread as the active one for the window? Don't know if it matters.
-
the way I got around it was to create a dummy context on the stack just before it create the actual context.
GlContext* GlContext::New(const WindowImpl* owner, unsigned int bitsPerPixel, const ContextSettings& settings)
{
//I added this line
ContextType dummyContext(&referenceContext);
ContextType* context = new ContextType(&referenceContext, owner, bitsPerPixel, settings);
// Enable antialiasing if needed
if (context->GetSettings().AntialiasingLevel > 0)
glEnable(GL_MULTISAMPLE_ARB);
return context;
}
and I also modified the code for selecting the version context to create, because although my card supports 3.3 if I chose 4.0, it would fail and jump to 2.0 instead :(
regards
-
Just wondering, Laurent, is it safe to comment out this line:
WglContext::WglContext(WglContext* shared) :
myWindow (NULL),
myDeviceContext(NULL),
myContext (NULL),
myOwnsWindow (true)
{
// Creating a dummy window is mandatory: we could create a memory DC but then
// its pixel format wouldn't match the regular contexts' format, and thus
// wglShareLists would always fail. Too bad...
// Create a dummy window (disabled and hidden)
myWindow = CreateWindowA("STATIC", "", WS_POPUP | WS_DISABLED, 0, 0, 1, 1, NULL, NULL, GetModuleHandle(NULL), NULL);
ShowWindow(myWindow, SW_HIDE);
myDeviceContext = GetDC(myWindow);
// Create the context
if (myDeviceContext)
CreateContext(shared, VideoMode::GetDesktopMode().BitsPerPixel, ContextSettings(0, 0, 0));
// Activate the context
//SetActive(true); <<<<----- is it safe to comment out this line?
}
I am not sure if other part of SFML relies on this behavior or uses this variant of the constructor that takes in a WglContext.
Currently the only one I am seeing that uses it is the defaultContext, so I am not very sure. If we comment it out, we can use the default context to set it as the current context before creating any window. something like:
GlContext* GlContext::New(const WindowImpl* owner, unsigned int bitsPerPixel, const ContextSettings& settings)
{
//Now we can use the default context that was created globally.
defaultContext.SetActive(true);
ContextType* context = new ContextType(&referenceContext, owner, bitsPerPixel, settings);
// Enable antialiasing if needed
if (context->GetSettings().AntialiasingLevel > 0)
glEnable(GL_MULTISAMPLE_ARB);
return context;
}
The reason I was asking if it was ok to comment out the SetActive in the constructor was because the default context is still active on the main thread and can't be used on other threads.
regards
-
I think the exisiting internal rendering context only apply if you create on the main thread. When I create my window on the main thread, it didn't have any problems. The problem only appear when I change all the window creation to run from a separate thread.
Yes. In other threads you need to have a dummy context before you can execute OpenGL stuff. However, I agree that creating a window shouldn't require this. This is going to be fixed soon in SFML 2 anyway.
I also modified the code for selecting the version context to create, because although my card supports 3.3 if I chose 4.0, it would fail and jump to 2.0 instead
Really? This is supposed to be fixed. What did you do?
Just wondering, Laurent, is it safe to comment out this line
I don't know, this line changed so many times. I activated it back a few months ago, for a good reason, but I don't remember why.
But like I said, everything will soon be fixed in SFML 2 ;)
-
I also modified the code for selecting the version context to create, because although my card supports 3.3 if I chose 4.0, it would fail and jump to 2.0 instead
Really? This is supposed to be fixed. What did you do?
I created a const array (doesn't matter if it is global or not) to check the version something along the line of
//the elements in the array represent the maximum minor version
//for e.g index [1] have 5 because the max opengl for 1.x is 1.5
//the element stored in the 0th index is the highest opengl major version
//in this case it is 4
const unsigned int minor_ver[] = {4, 5, 1, 3, 1};
//set the version to the highest valid one before looping in case user request for invalid versions
//e.g if user request version 13.8 we drop to the highest valid ones.
mySettings.MajorVersion = (mySettings.MajorVersion > minor_ver[0]) ? minor_ver[0] : mySettings.MajorVersion;
mySettings.MinorVersion = (mySettings.MinorVersion > minor_ver[mySettings.MajorVersion]) ? minor_ver[mySettings.MajorVersion] : mySettings.MinorVersion;
while (!myContext && mySettings.MajorVersion >= 3)
{
//...... creating of the context etc .....
if (!myContext)
{
mySettings.MinorVersion = (mySettings.MinorVersion > 0) ?
mySettings.MinorVersion - 1 : minor_ver[--mySettings.MajorVersion];
}
}
not sure if this is the best way to go about doing it
edited: change "Settings" to "mySettings" and change typo errors
-
Oh, I just realized that the current code assumes that 3 is the maximum major version.
Doesn't changing this line in the original code
mySettings.MajorVersion = 2;
...to this
mySettings.MajorVersion--;
...solve the problem?
-
it would work too, but it would loop redundant times. For e.g if the user put 10.10, it would loop 60 times before hitting a valid profile. Or if the user request for major version 3, minor version 888, it would end up looping 885 times before hitting the 3.3 profile.
-
Yep, but I don't think this is a problem. And this way I don't have to update the code every time a new minor version of OpenGL is released.
-
okie :)
btw when you say the context creation on multiple thread will be fixed in sfml2, does it refer to the official release of sfml2, or the current snapshot is fixed already??
:D
-
It will be fixed soon (before the official release) but it's not done yet, I'm working on it.
-
I fixed the context creation thing but I can't test it, can you confirm that it's working?
-
Hi, Laurent, I can't seems to download the latest snapshot from the website.
http://www.sfml-dev.org/download.php
The links doesn't seems to work. Is there a way to get the latest source files??
regards
-
Have you tried with a SVN client directly? Maybe it's just the HTTP access that is down.
-
hi, both method didn't work for me. When I tried to access it using the http link to get the snap shot it gives the error
Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error.
when using tortoise SVN, it says the remote host forcibly close the connection.
regards
-
From https://sourceforge.net/blog/update-sourceforgenet-attack/
Non CVS SCM data
We are still working on validating SVN, Hg, Bzr, and Git data on the main sourceforge.net SCM servers. These servers weren’t compromised, but the SCM data was accessible to the attacker. At this time we don’t have any evidence of tampering with SCM data. We will publish the full results of our validation work when the work is complete.
We have also redesigned the platform for these services, and will be pushing out updated configurations and improved security controls. We expect the updates to this service and the results of this validation work to ship later this week. ViewVC (web-based SCM access) will be brought online as we ship the updated SCM servers.
So I think we have to wait a little bit more.
But : for me the svn command line client works just fine.
-
hi, SVN is up and working again. :) I tried the new snap shot. The context is sort of working however I can create a 3.3 and 3.2 context but when creating a 3.0 or 3.1 context, it would fail. However if I am to remove the attribute pair:
WGL_CONTEXT_PROFILE_MASK_ARB
WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB
it would work.
The creation of context from a separate thread still doesn't seems to work :(
P.S: I am not sure if this is intended, but if the creation of a 3.0 context fail, the return value from ContextSettings shows that the context was created with a 2.9 version. Maybe it would be better to report a 2.1 version or 2.0 version :)
regards
-
However if I am to remove the attribute pair:
WGL_CONTEXT_PROFILE_MASK_ARB
WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB
it would work.
Indeed, this stuff seems to be new to OpenGL 3.2. But it seems that the 1.x were deprecated in 3.0. So what happens in 3.0 and 3.1?
P.S: I am not sure if this is intended, but if the creation of a 3.0 context fail, the return value from ContextSettings shows that the context was created with a 2.9 version. Maybe it would be better to report a 2.1 version or 2.0 version
Ah, this is true :)
-
However if I am to remove the attribute pair:
WGL_CONTEXT_PROFILE_MASK_ARB
WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB
it would work.
Indeed, this stuff seems to be new to OpenGL 3.2. But it seems that the 1.x were deprecated in 3.0. So what happens in 3.0 and 3.1?
P.S: I am not sure if this is intended, but if the creation of a 3.0 context fail, the return value from ContextSettings shows that the context was created with a 2.9 version. Maybe it would be better to report a 2.1 version or 2.0 version
Ah, this is true :)
3.0 deprecated features, but did not remove any. 3.1/3.2 actually removes them (and deprecates other features). In 3.2 the concept of different profiles was introduced, to allow using removed features when specifying a compatiblity profile.
So, if you specify 3.0, there is no need to use a compatibility profile because all parts of the 1.x standard are still part of the standard (just deprecated, not removed!)
-
Ok, that's what I thought. Thanks for clarifying it. But what happens in 3.1 contexts? Deprecated functions are removed, but there's no compatibility profile yet, so what?
-
Ok, that's what I thought. Thanks for clarifying it. But what happens in 3.1 contexts? Deprecated functions are removed, but there's no compatibility profile yet, so what?
If I'm not mistaken, you are quite plainly out of luck (SOL) if you have a system which only supports 3.1 and want to use GL 1.x functions. I presume this is why they introduced the concept of profiles in 3.2 (should have thought of it earlier...). For SFML this means that to be technically correct you would have to do the following:- If the user requests 3.2+ with compatibility profile, and 3.2 is not available, ask for 3.0 (without setting the compatibility profile bit and mask), since 3.0 supports all 1.x functionality, but 3.1 does not.
- If the user requests 3.2+ without compatibility profile, you have to go to 3.1, again without setting the bit and mask. In this case, the lack of 1.x support should not matter (otherwise a compatibility profile would have been requested)
- When directly requesting 3.1 or 3.0 ignore the compatibility setting, as it wouldn't be valid (or maybe jump to 3.0 when 3.1 is selected with compatiblity)
It's ugly, but I don't think there is any clean way around this. The cleanest solution would probably be to combine mercurios array solution with a hardcoded exception when 3.2 fails and for 3.0 and 3.1 (as they don't support the mask and bit)
Or you could simply decide that you ignore this, as pretty much every graphics card that supports 3.0 also supports 3.1 through 3.3 (except, according to wikipedia the Intel sandy bridge 2000 and 3000 which only support 3.0). Personally though, I think this would be a bad, as you do know that there is a potential problem, and it is not that hard to solve.
-
In fact the compatibility bit is set internally by SFML, because I need the deprecated functions. So I must disable 3.1 contexts, that's it.
-
In fact the compatibility bit is set internally by SFML, because I need the deprecated functions. So I must disable 3.1 contexts, that's it.
Oh, ok, that is certainly simpler. Are you still using the begin/end drawing?
-
Are you still using the begin/end drawing?
For now yes, but I'd like to change it for SFML 2.
-
I am not sure, but I thought that the purpose of the forward compatibility bit is a stop gap measure by the opengl team, to allow code to still work with the old API.
However in future, all vendors would eventually drop support for the old functions. In such cases when calling with the compatibility bit set, it would allow a user to use the old functions, but it probably wouldn't work, as the card and drivers would no longer support them.
I am not 100% sure about this though.
Maybe in future, when Laurent upgrade the internal opengl code, we can ignore the compatibility bit in the 3.0++ versions?? and if user require the old functions, they can still request for a 2.0 version. Anyway if a user request a 3.0 version, it would mean they would be making changes to support a 3.0 version, and since they are making changes, it would be highly likely that they would change all code to support it rather than mixing 3.0 with 2.0 context.
It would be analogous to a person who is using DX9, but only upgrade half the program to run in DX10, normally a person would probably upgrade the whole program to run fully in DX10, and not in a manner when half the code uses DX10, and half uses DX9. :)
regards
-
I am not sure, but I thought that the purpose of the forward compatibility bit is a stop gap measure by the opengl team, to allow code to still work with the old API.
Forward compatible would mean without the removed functions, "compatibility profile" would mean with the removed functions still available (backward compatible).
However in future, all vendors would eventually drop support for the old functions. In such cases when calling with the compatibility bit set, it would allow a user to use the old functions, but it probably wouldn't work, as the card and drivers would no longer support them.
I am not 100% sure about this though.
That may be the plan, but large vendors like nVidia already stated that they would continue supporting all OpenGL features for all new cards.
Maybe in future, when Laurent upgrade the internal opengl code, we can ignore the compatibility bit in the 3.0++ versions?? and if user require the old functions, they can still request for a 2.0 version. Anyway if a user request a 3.0 version, it would mean they would be making changes to support a 3.0 version, and since they are making changes, it would be highly likely that they would change all code to support it rather than mixing 3.0 with 2.0 context.
What SFML would need is different versions of the rendering code, one for 1.x to 3.0 (as 3.0 still includes all 1.x features!) And one for 3.1+ as the 3.1+ code would not work with GL versions 1.x through 2.x. But I believe a more flexible rendering backend is in planning anyways since it is needed for GLES as well.