All Activity

Put it in a zip file and upload it somewhere I can download it from.

The problem is likely a driver bug related to bindless textures. I will file a report with AMD but I don't know how frequenly they update these drivers or if it is still supported.

So I can open the model and material editors now. But if I move around this map in editor at some point it freezes up and crashes. Whenever I start the program it defaults me to an untitled map and I have to reload my other map, which also freezes at a certain point even though it's just two box brushes and a player script. Also the materials are not reacting to lights at all.

Ok so I went to the Device Manager on my computer and clicked "Display adapters" then right-clicked to update the drivers there and it may have resolved the issue. I'll fiddle around with it and see if anything else happens.

It says AMD Radeon Vega 6.

You will need to find the driver that corresponds to the GPU you have. The name of your GPU will appear in the program console when the editor starts. I tried searching for your card but can't identify it without the exact name.

I have no idea. Looks like it was made around 2021-22 . I'm not tech savvy. Its an Aspire A515-46 AMD Ryzen 3 with Radeon Vega Mobile Gfx. What do I want? VGA drivers?

I have not heard of this problem before. I could only test it by getting the same computer as you. Are the drivers for your GPU discontinued? When were they last updated?

Ok I did that. It seems to have fixed that problem. Now the trouble is when I open the material or model editor it freezes up there. Is that just the AMD bugs?

This feature in Leadwerks 4.6 would be nice if it were added to Leadwerks 5.0.

AMD had some pretty bad driver bugs last year that would cause behavior like this. Make sure you have the latest drivers installed for your card: https://www.amd.com/en/support/download/drivers.html

Here is is: https://www.leadwerks.com/community/topic/61318-release-notes/page/37/#findComment-320732 Assuming your game is written in C++, I recommend these settings: world->Update(window->display->GetRefreshRate()); world->Render(framebuffer, true, 1); And multiply all your time-dependent values by world->GetSpeed().

What graphics card do you have?

5.0.2 beta Added Display:GetRefreshRate method. Added Hmd:GetRefreshRate method. Fixed player physics to work the same at any update frequency. Improved timing and thread sychronization. This is experimental. If you don't want your workflow interupted, switch to the default branch now. In this build, timing works differently. The third command argument for World:Render has been replaced with a new value, syncedframes: World::Render(framebuffer, bool vsync = true, int syncedframes = -1) This value allows you to specify how many frames the rendering thread should draw before it waits for a new update from the main thread. The max framerate value this command previously supported will no longer be used, because this value is now calculated from the world update frequency and number of synced frames. Emulating 5.0.1 Standard Behavior The standard behavior previous builds use is a 60 hz game loop, and the rendering thread is allowed to go as fast as it wants. This will work with any display or VR headset refresh rate: world->Update(60); world->Render(framebuffer, true, 0); Or if you want to test the maximum framerate set VSync to false: world->Update(60); world->Render(framebuffer, false, 0); Improved Synchronization at 60 hz If you set syncedframes to 1, and the world update rate is 60, then for every one iteration of the game loop, one frame will be rendered. The main and rendering threads will still be running at the same time, but they will be more closely synchronized, for lower-latency input: world->Update(60); world->Render(framebuffer, true, 1); However, on high-frequency displays this will give you a framerate lower than the max refresh rate. Competitive E-Sports Games If want to adjust the game speed to support any display with minimal latency, you can do this: world->Update(window->display->GetRefreshRate()); world->Render(framebuffer, true, 1); This is the best setting for minimal latency for twitch shooters written in C++. Note that if a frequency other than 60 is used, you will need to multiply all the time-dependent values in your code by world->GetSpeed(). Velocity does not need to be modulated with this, because it is already in units of distance over time. If you want your game to run at a speed faster than the screen refresh rate, you can set vsync to false: world->Update(200); world->Render(framebuffer, false, 1); I believe this is how the timing in the newer Doom games works, and it explains why the game cannot run at a framerate faster than 200. Anything higher than that would probably start to affect how physics and other game code works, causing erratic behavior. Tight Synchronization with Varying Game and Rendering Frequencies The problem with perfectly synced timing on high-frequency displays is it decreases the amount of time your code has to run in the main thread. At 60 hz your game code has 16.667 milliseconds to run. If the screen refresh rate is 240 hz, that only allows 4.16 milliseconds for your game code to run. If there are a lot of enemies with complex code or if the game is written with Lua, this will probably cause the game to slow down. You might also want to always make the game update at 60 hz so that you don't have to multiply everything by world->GetSpeed(). You can combine a higher rendering frequency with a lower game frequency, by specifying more than one synced frames: world->Update(60); world->Render(framebuffer, false, 2); This will update the game at 60 hz, but render the world at 120 hz, drawing two frames for every game loop. The previous two orientations of each entity will be interpolated, so you have smooth motion even though two frames are rendered for every one iteration of the game loop. If you wanted the game to render at 180 hz, you could set the third argument to 3. To support any display frequency with close synchronization of frames, you might wish to do something like this: float refreshrate = window->display->GetRefreshRate(); int syncedframes = Floor(refreshrate / 60.0f); int updatespeed = Round(refreshrate / syncedframes); world->Update(updatespeed); world->Render(framebuffer, true, syncedframes); The above code will give you these values: Display refresh rate: 90 hz Update speed: 90 Synced frames: 1 Display refresh rate: 120 hz Update speed: 60 Synced frames: 2 Display refresh rate: 144 hz Update speed: 72 Synced frames: 2 Display refresh rate: 240 hz Update speed: 60 Synced frames: 4 If you are rendering at a faster speed than the game loop, you may wish to use the Camera::SetMouseLook feature to handle camera looking in the rendering thread. This will give you low-latency camera movement, with a few caveats: The player movement will still be updating at a lower frequency and might feel slightly mushier, but since player movement has inertia anyways it might not be very noticable. The camera rotation will be fed back to the main loop, so it will always be a few milliseconds behind. This could matter in E-sports type hyper-competitive shooters, but probably doesn't matter for regular FPS games. On the other hand, someone with a 240 hz display is likely to also have a top-of-the-line CPU, so maybe it all balances out. It's up to you. Default Behavior If you don't understand any of this, or don't care, then you can just not specify any parameter, and the engine will choose settings for you based on the display refresh rate. For 75% of players this will be 60 hz, so if your game loop is running at 60 hz and vsync is enabled, the engine will choose 1 for the number of synced frames, otherwise it will be set to 0. Visualizing the Technique This code provides a dramatic example that shows how varying game and rendering frequencies works. Here the game updates at just one update per second, but the renderer displays smooth motion at 120 frames per second, using just the inputted information! (Don't actually do this in your own games, this is just for learning.) #include "Leadwerks.h" using namespace Leadwerks; int main(int argc, const char* argv[]) { auto displays = GetDisplays(); auto window = CreateWindow("Leadwerks", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); auto world = CreateWorld(); auto framebuffer = CreateFramebuffer(window); auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetPosition(0, 0, -2); auto light = CreateBoxLight(world); light->SetRotation(45, 35, 0); light->SetRange(-10, 10); light->SetColor(2); auto A = CreateBox(world); A->SetPosition(-1,0,0); A->SetColor(0, 0, 1); auto B = CreateBox(world); B->SetPosition(1, 0, 0); B->SetColor(0, 0, 1); while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { // The box on the left will show smoothed motion A->Turn(0, 0, 22.5); // The box on the right will show the true state of the game B->Turn(0, 0, 22.5); B->Sync(); // Game updates once per second world->Update(1); // Game renders 120 frames, evenly spaced, for every one game loop iteration world->Render(framebuffer, false, 120); } return 0; }

Note to self...

@JoshAwesome, thank you! I'll test it right away. Looking forward to the other stuff. Marry Christmas!

When i load in Leadwerks Game engine 5 on steam, create a project and when i click to start it it just closes the game. I don't wath to do???

How can I share the project with you? It's a test project started from the fps example and the project folder is to much big (3GB)

The whole computer locks up when I mouse hover over models. Had to restart several times. Also on the downloads page when I click a pic no option for downloads is appearing. It may work a few times but then stops showing up. Also, not sure if related but lights are not lighting up textures in scene, as if they're not working. I'm on an Acer vega 6, if that's important. Saw some other folks on AMD having issues. Any help appreciated. 5 looks awesome I wanna mess with it. Thanks.

I'll have some more stuff for you after Christmas. I did some work on the timing and found a way to run the logic and rendering thread in sync at any frequency. It feels like playing new Doom games at 200 FPS. I think you will like it.