Jump to content

Josh

Staff
  • Posts

    22,895
  • Joined

  • Last visited

Everything posted by Josh

  1. Josh

    Thumbs

    This may be fixed in 0.9.5 now.
  2. Problem is resolved in 0.9.5, on the beta branch.
  3. I just checked and during the first render there are no cameras being used. I get a black screen until the program switched over to the main menu. I cannot find any cameras being created in loadingWorld. I think you want this: // LOADING loadingWorld = CreateWorld(); loadingUi = CreateInterface(loadingWorld, font, framebuffer->GetSize()); loadingUi->SetRenderLayers(2); loadingUi->root->SetColor(0.5f, 0.5f, 0.5f, 1.0f); float labelHeight = float(framebuffer->GetSize().y) * 0.2f; int centerX = float(framebuffer->GetSize().x) * 0.5f; int centerY = float(framebuffer->GetSize().y) * 0.5f; auto loadingLabel = CreateLabel("LOADING...", float(framebuffer->GetSize().x) * 0.05f, centerY - labelHeight * 0.5f, float(framebuffer->GetSize().x) * 0.95f, labelHeight, loadingUi->root, LABEL_CENTER | LABEL_MIDDLE); float fonstScale = labelHeight / 14.0f; loadingLabel->SetFontScale(fonstScale * 0.5f); loadingCamera = CreateCamera(loadingWorld, PROJECTION_ORTHOGRAPHIC); loadingCamera->SetPosition(float(framebuffer->GetSize().x) * 0.5f, float(framebuffer->GetSize().y) * 0.5f, 0); loadingCamera->SetRenderLayers(2); loadingCamera->SetClearMode(CLEAR_DEPTH); //CAUSES AN ISSUE loadingWorld->Render(framebuffer);
  4. I am mostly concerned at the prospect of the window client area changing size while rendering is happening on another thread. Will need to get out another monitor and test this some more...
  5. 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.
  6. No, it just loads data from a stream which may not have any file path associated with it at all.
  7. Mark as solution when you feel it is resolved.
  8. 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); }
  9. 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.
  10. 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.
  11. Fixed. You may see more than one of these events emitted in the current build, but at least one will be.
  12. 0.9.5 Some window and graphics initialization fixes.
  13. I did get the DestroyWindow error sorted out.
  14. 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.
  15. Lunch has just finished. Now I am uploading...
  16. 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.
  17. I just posted an update that may solve initialization troubles on some GPUs.
  18. 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);
  19. 0.9.5 May fix some initialization errors. Windows are hidden and a message is printed if DestroyWindow fails for any reason.
  20. 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;
×
×
  • Create New...