cwindowsopengluwpmakeappx

OpenGL Reporting an old version when project packaged as a Windows `.appx` or `.msix` file

I'm making a video game written in C, which uses SDL and OpenGL to draw the graphics. The compiled version works fine on Linux and Android.

I compiled the Windows version, and that works fine as well, only as a standalone. I tried to package all the compiled files inside an .appx or .msix format, and I found out that OpenGL reports completely different version numbers when run as a packaged app.

I'm using the following code to get some OpenGL information:

printf("Vendor graphic card: %s\n", glGetString(GL_VENDOR));
printf("Renderer: %s\n", glGetString(GL_RENDERER));
printf("Version GL: %s\n", glGetString(GL_VERSION));
printf("Version GLSL: %s\n", glGetString(GL_SHADING_LANGUAGE_VERSION));

When I run the project as a standalone, I get the following information:

Vendor graphic card: Intel
Renderer: Intel(R) HD Graphics 2000
Version GL: 3.1.0 - Build 9.17.10.4459
Version GLSL: 1.40 - Intel Build 9.17.10.4459

This all looks correct, and the app behaves as expected. However I then packaged all the files into both an .appx file and an .msix file, and they both report the same results when run:

Vendor graphic card: Microsoft Corporation
Renderer: GDI Generic
Version GL: 1.1.0
Version GLSL: (null)

And needless to say, the first call I make to glCreateShader crashes.

For reference, I packaged all the files into .appx and .msix files using the following commands in PowerShell:

MakeAppx pack /d <my_file_directory> /p project.msix
SignTool sign /a /v /fd SHA256 /f mycert.pfx /p "mypassword" project.msix

Does anyone know what could be causing this? Happy to provide more information if needed.

Solution

  • Based on some research I've done, and comments I've gotten from other sites, here are my findings about this problem:

    OpenGL support on UWP seems to need a few tricks to make it behave right. The Microsoft Store (which uses .appx and .msix files) is translating OpenGL ES calls to Direct3D calls behind the scenes, which makes it more difficult to get accurate information.

    So the easiest path seems to be porting the project to Direct3D, which should resolve the issues mentioned in the question.