hugoam/two

Failure to run any demos on Windows: GLFW error

Closed this issue · 9 comments

Unsure what to do about this error I'm seeing:

...
INFO: Init Gfx System
INFO: resource path: d:/Dev/toy/data/
INFO: resource path: d:/Dev/toy/data/examples/ex_blocks/
INFO: Creating GLFW context. GLFW version 3.3
ERROR: GLFW 65546: Cannot make current with a window that has no OpenGL or OpenGL ES context
ERROR: GLFW 65538: Cannot set swap interval without a current OpenGL or OpenGL ES context
GfxSystem: Native Handle = 004508AE
GfxSystem: bgfx::init
...

I have the latest drivers. In GlfwContext.cpp of mud, I see a check if MUD_RENDERER_BGFX is defined which then sets glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API). The GLFW documentation states

Windows without contexts must not be passed to glfwMakeContextCurrent

But only a few lines later, this exact thing happens.

Is this a bug?

Thanks!

These error messages are not critical in any way, so if you're having an issue running demos it's probably unrelated to these messages. (But I'll see about fixing them anyway).
It would be great if you could run the app in the debugger and tell me where it crashes with a stacktrace (and also paste the full console log into a gist).

I'm getting similar errors. Here's the actual exception it threw for me:
Exception thrown at 0x00007FF644E102AD in 00_cube_d.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

I cloned the most recent mud_samples, built vs2017 project files with GENie, built with vs2017, and then started 00_cube.

Here's my console output:
INFO: Init Gfx System
INFO: resource path: c:/Users/chaol/source/mud-sample/data/
INFO: Creating GLFW context. GLFW version 3.3
ERROR: GLFW 65546: Cannot make current with a window that has no OpenGL or OpenGL ES context
ERROR: GLFW 65538: Cannot set swap interval without a current OpenGL or OpenGL ES context
GfxSystem: Native Handle = 00000000001605AC
GfxSystem: bgfx::init
INFO: Loaded image c:/Users/chaol/source/mud-sample/data/textures/white.png of size 4 B in memory
INFO: Loaded image c:/Users/chaol/source/mud-sample/data/textures/black.png of size 4 B in memory
INFO: Loaded image c:/Users/chaol/source/mud-sample/data/textures/normal.png of size 4 B in memory
INFO: Initializing UiWindow: resource path c:/Users/chaol/source/mud-sample/data/
INFO: Loading Images in path c:/Users/chaol/source/mud-sample/data/interface/uisprites/
INFO: UiWindow :: resize 1600, 900

And then it's a few hundred lines of:
DEBUG: unpacking member Colour :: r
DEBUG: unpacking member Colour :: g
DEBUG: unpacking member Colour :: b
DEBUG: unpacking member Colour :: a
DEBUG: unpacking member Colour :: r
DEBUG: unpacking member Colour :: g
DEBUG: unpacking member Colour :: b
DEBUG: unpacking member Colour :: a
DEBUG: unpacking member vec4 :: a
etc. (I'm also not sure why it would need to unpack the same members hundreds of times over.)

Same result for other demos, but it doesn't throw the exception if I target Win32 instead of (and it actually works). Still has a similar console output, though. (Also, the UI is super small, but I have a 4k monitor...)

Is x64 supported? Is UI scaling supported?

Hi ! mud-sample is outdated (it points to a very old version of mud). If any docs advise to build that one first I should update it, because you should try the mud repository directly.
x64 is supported, please let me know of any issues you encounter building and running the mud repository directly.

Also I've never tried it on a 4k monitor. Scaling is supported so it should be quick task to add support for it, but I'm not really sure what's the correct way to handle it, so if you have any input on this topic I'm all ears.

Thanks for the quick reply!
I got mud-sample from the main README, under the 'building' section.
As for scaling, I found this for Windows, and I'm sure there's something similar for Linux and other operating systems.

Hm. Am I using GENie wrong?

$ mud/bin/windows/genie vs2017
Building configurations...
Running action 'vs2017'...
Done. Generated 0/0 projects.

You have to call GENie from inside the folder of the project that you want to build that has a scripts/ folder.
So to build mud you need to call bin/windows/genie vs2017 from inside mud folder and not mud/bin/windows/genie vs2017 from top level folder. GENie always looks for a scripts/ folder, so since there is probably none in the parent folder, it doesn't generate anything.

I updated the build instructions so that mud-sample is not mentioned anymore.

I tried that first, but forgot to clone the submodules.
It works beautifully now, thank you! All of the issues I had are solved.