Jump to content

Josh

Staff
  • Posts

    22,897
  • Joined

  • Last visited

Everything posted by Josh

  1. 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;
  2. You should get rid of the call to LoadColorScheme, since that file is not included in the report, and it's not necessary.
  3. Deleting the settings file in C:\ProgramData\Ultra Engine\settings.json might help.
  4. 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.
  5. 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.
  6. This requires two monitors to test? Do I just move the window from one to another?
  7. 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...
  8. 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...
  9. Here is that story I was talking about with Starfield: https://www.hardwaretimes.com/amd-helped-bethesda-fix-starfield-resulting-in-better-radeon-performance-dlss-wasnt-blocked-report/
  10. That may be the next step. Let's pick it back up tomorrow or later this week.
  11. 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.
  12. 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.
  13. 0.9.5 Bug fixes, see forum for exact details.
  14. No problems on my Nvidia 1080. New build is available.
  15. 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.
  16. Okay, I am adding some more debugging messages...
  17. Yes, that is what I needed. Please install GPU caps viewer: https://www.ozone3d.net/gpu_caps_viewer/ Check and see if your card support the GL_ARB_bindless_texture extension.
  18. Does VS show you what file the error is occurring in? It's not good for me to have a bunch of asserts with no clear error messages.
  19. Okay, I found the cause. New build incoming today.
  20. I don't get any error.
×
×
  • Create New...