Josh

I think getting integrated graphics to work will take longer and it is not currently supported, although we are a lot closer now than we were before.

Lunch has just finished. Now I am uploading...

This is interesting. There is some high-intensity code in the terrain materials building system. I was at one point going to move this to a compute shader because I thought it was too much for the CPU. However, once I had rewritten the algorithm to work with shaders, it was then running fast enough that I kept it on the CPU. (I actually had to write my own sorting code to make it work.) There are two assert statements in the algo that did not have any messages. Simple adding some text in the second argument to Assert was enough to slow down the code to a crawl, which is what you saw. This is not normally something you need to worry about, but the Assert statements were being called more than a million times. I will upload a new build after lunch. You are probably asleep right now.

Is the reported issue solved now?

I just posted an update that may solve initialization troubles on some GPUs.

I can sometimes make this issue appear, and sometimes it does not. I think what's going on is the WM_CREATE must be processed before the OpenGL context is created. A call to WaitEvent() or maybe just PeekEvent() before your first call to world::Render() will probably solve this problem: //CAUSES AN ISSUE WaitEvent(); loadingWorld->Render(framebuffer);

0.9.5 May fix some initialization errors. Windows are hidden and a message is printed if DestroyWindow fails for any reason.

For some reason your code is causing SetPixelFormat to fail in the context creation code. I don't have an explanation yet. You can add this code to your event evaluation to check if the renderer fails to initialize. It's a good idea to have this anyways because it will show the user if their GPU is unsupported: case EVENT_STARTRENDERER: if (ev.data == 0) { Print("Error: Renderer failed to initialize."); Notify("Renderer failed to initialize.", "Error", true); return 0; } break;

Hold on, I found something weird...

You should get rid of the call to LoadColorScheme, since that file is not included in the report, and it's not necessary.

Deleting the settings file in C:\ProgramData\Ultra Engine\settings.json might help.

It seems that your framebuffer size is changing if you move a window in between two screens with a different display scale, so you would need to reposition your 2D camera.

Is that the solution then?

The titlebars in your screenshots are a different size. It looks like the monitors are using a different display scale, which will give them a different framebuffer size.

This requires two monitors to test? Do I just move the window from one to another?

Maybe what is going on is wglCreateContextAttribsARB creates a child window on the rendering thread, then DestroyWindow on the main thread is unable to delete the child that was created on the rendering thread, but I need to investigate further. In the meantime I will just add a check that hides the window if DestroyWindow fails. That doesn't actually make sense, because this only occurs if windows are created in rapid succession. Otherwise it is fine...

Weird. Holding the space key will continuously generate new key hits because it's a different window each time. I have verified that the system is working correctly and DestroyWindow(hwnd) is actually being called on the old windows. It's indicating error ERROR_ACCESS_DENIED, but I am sure the function is being called from the main thread...

That may be the next step. Let's pick it back up tomorrow or later this week.

0.9.5 is available on the beta branch. The reported issue is likely resolved now but I can't verify it since I never saw it on any of my machines.

Okay, that is indeed a separate bug but it's pretty small, and can be avoided by setting one height value anywhere in the terrain.

0.9.5 Bug fixes, see forum for exact details.

No problems on my Nvidia 1080. New build is available.

The fix is available now.

Okay, I added some more error checking, so either the texture ID is invalid or it can't be turned into a bindless texture handle. Only you will be able to tell.