Josh

139 is TEXTURE_BC4. The engine currently does not account for this format, but I just added this. The displacement map on the server does not use this format, and when I ran the example this format was never used. However, you might have an old copy of the texture in your local cache that uses BC4, maybe. You can delete the folder C:|ProgramData\Ultra Engine\WebCache to force the app to re-download the textures from the server.

No, it just loads data from a stream which may not have any file path associated with it at all.

Mark as solution when you feel it is resolved.

Do you mean OpenGL?

This makes sense. The button is being stored as part of the emitted event. You can clear the events in the main loop to get rid of them like this: //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { while (PeekEvent()) WaitEvent();// Clears event queue if (window->KeyDown(KEY_SPACE)) { Print(int(btn.use_count())); EmitEvent(EVENT_DATA, btn); Print(int(btn.use_count())); } world->Update(); world->Render(framebuffer); }

This file mimics the beginning of a Leadwerks MDL file. I added some more checks that prevent the loader from trying to load this as such.

The assert statements were removed entirely, and the error you got will now include the texture pixel format, which could tell us which texture is failing. I suspect it is the unsigned integer RGBA texture, and I think the problem has to do with texture completeness requirements prior to being used as a bindless texture.

Fixed. You may see more than one of these events emitted in the current build, but at least one will be.

0.9.5 Some window and graphics initialization fixes.

I did get the DestroyWindow error sorted out.

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?