This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.4
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2016-01-27 08:29:51 +0000, Holger Rapp wrote:

Widelands is having a peculiar issue around OpenGL initialization. On one windows 10 (could not select that in the OS list above, that is why it says Windows 8) system, we get an OpenGL 1.1 context even though we are requesting an OpenGL 2.1 context when using our daily builds from appveyor.

A version build on one of our devs computers running, but executing on the same computer gets a 2.1 context returned as requested. Since we use SDL for loading the GL library and creating a context, we assume it is a bug in SDL.

This is how we initialize our context:
http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/graphic/gl/initialize.cc#L40

This is the bug from the Widelands tracker with more information:
https://bugs.launchpad.net/bugs/1536377

This is the output in the failing case:

Graphics: OpenGL: Version "1.1.0"
Graphics: SDL_GL_RED_SIZE is 8
Graphics: SDL_GL_GREEN_SIZE is 8
Graphics: SDL_GL_BLUE_SIZE is 8
Graphics: SDL_GL_ALPHA_SIZE is 0
Graphics: SDL_GL_BUFFER_SIZE is 24
Graphics: SDL_GL_DOUBLEBUFFER is 1
Graphics: SDL_GL_DEPTH_SIZE is 16
Graphics: SDL_GL_STENCIL_SIZE is 8
Graphics: SDL_GL_ACCUM_RED_SIZE is 16
Graphics: SDL_GL_ACCUM_GREEN_SIZE is 16
Graphics: SDL_GL_ACCUM_BLUE_SIZE is 16
Graphics: SDL_GL_ACCUM_ALPHA_SIZE is 0
Graphics: SDL_GL_STEREO is 0
Graphics: SDL_GL_MULTISAMPLEBUFFERS is 0
Graphics: SDL_GL_MULTISAMPLESAMPLES is 0
Graphics: SDL_GL_ACCELERATED_VISUAL is 1
Graphics: SDL_GL_CONTEXT_MAJOR_VERSION is 2
Graphics: SDL_GL_CONTEXT_MINOR_VERSION is 1
Graphics: SDL_GL_CONTEXT_FLAGS is 0
Graphics: SDL_GL_CONTEXT_PROFILE_MASK is 2
Graphics: SDL_GL_SHARE_WITH_CURRENT_CONTEXT is 0
Graphics: SDL_GL_FRAMEBUFFER_SRGB_CAPABLE is 0

Any ideas?

On 2017-08-29 01:17:26 +0000, wrote:

how did you end up with an accumulation buffer? I would guess that the opengl driver is falling back to software rendering and only supporting v1.1.

On 2017-08-29 12:15:02 +0000, Holger Rapp wrote:

I am not sure what further information I can provide here.

The widelands version build on Appveyor show the bug while the versions build by our release engineer are working on the same machine. The differences in the build are documented in the attached Widelands bug.

It seems interesting that the driver sometimes creates a valid context and sometimes falls back to software rendering. Is that not something SDL should control?

On 2018-08-06 21:20:23 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.

On 2018-08-07 12:29:47 +0000, Holger Rapp wrote:

We see this problem still.

On 2018-08-07 15:39:14 +0000, Ryan C. Gordon wrote:

(In reply to Holger Rapp from comment # 4)

We see this problem still.

First: getting GL version 1.1.1 generally means you got Windows' default OpenGL implementation instead of your actual GPU's drivers.

It's extremely weird that this works for a local build and not a build from Appveyor. Looking at the Appveyor build logs, it looks like it's downloading a prebuilt SDL library from somewhere, which is either out of date or (more likely) built incorrectly in some way. Is there some way to track down the build logs for the libSDL.a you use?

(If you'd rather move this discussion over to the launchpad.net bug report, let me know.)

--ryan.

On 2018-08-07 15:40:28 +0000, Ryan C. Gordon wrote:

(In reply to Holger Rapp from comment # 0)

A version build on one of our devs computers running, but executing on the
same computer gets a 2.1 context returned as requested.

Also: where is that dev getting his libSDL from? Built himself, or the same location as appveyor?

--ryan.

On 2018-08-10 11:43:41 +0000, Holger Rapp wrote:

I am unsure. I think there is a higher likelihood to get answers if we move this discussion into the Widelands bug on launchpad. Is that feasible?