Leadwerks Game Engine 5.0.2 is now available with new fixes and features for you to enjoy.

New enhanced timing features provide smooth stutter-free movement and make Leadwerks a great choice for use in twitch shooters and other fast-paced games. Before you we begin, let me point out that you don't have to do any of this. 75% of players use a screen refresh rate of 60 Hz, and if you don't specify any optional parameters in the world Update and Render methods, the engine will choose settings for you. This is only for people who want extra control over their game timing.

You can run the world update loop and the rendering loop at the same speed, perfectly synchronized, or you can render multiple frames for each world update, using interpolation on every object to smoothly display motion at high framerates, without overloading the main thread.

For example, if your game runs at 60 hz and the screen refresh rate is 60 hz, you can specify that one frame should be synchronized across both threads.

The world is updated at 60 Hz and the world Render method specifies that one frame should be synchronized:

If your screen has a refresh rate of 120 Hz, you can double the game update speed and render one frame per update, at a faster rate. The only drawback to this is your game code will only have 8 milliseconds to complete, instead of the full 16 milliseconds a 60 Hz loop would provide:

Here, we just increase the game update speed to 120 and use one synced frame:

There is another way to handle this. If your screen refresh rate is 120 Hz, you can still update the game 60 times per second, while rendering at twice the speed:

Here, the world is still updated at 60 Hz and the world Render method specifies that two frames should be drawn for each world update:

How is it possible for the game and rendering loops to run at different speeds? The renderer interpolates between the last two frames of data received to provide smooth motion. The image below provides a very exaggerated example for clarity. Both boxes are updating their rotation at just one update per second, but the renderer is using interpolation on the object on the left to provide the appearance of smooth motion.

For other screen refresh rates, you can divide the refresh rate by 60 to determine the closest value to 60 and use this for the world update frequency:

Here, the world update speed is 72 and the renderer draws two frames for every one update in the game loop:

The code below will calculate these values for you:

You can use more than just two synced frames. The code below will render four frames for every one update in the game loop, with perfectly smooth motion, when a 240 Hz display is in use:

Here we still use 60 Hz for the game update frequency, but with four frames drawn for each game update, proving smooth motion at 240 frames per second:

If the renderer is interpolating between the last two game updates, this introduces latency into the system. However, we discovered during our work with VR that not all latency matters. The only latency you can actually perceive is that which is connected to your body. In VR, this means the orientation of your headset and controllers. Our solution was to put all our VR code in the rendering thread, and always update the headset orientation right before a new frame is rendered.

For 3D games, especially shooters, mouse look latency is a significant problem. We noticed in Leadwerks 5.0 the mouse looking could sometimes feel "mushy" and wanted a solution to this. We found that using the new Microsoft GameInput[learn.microsoft.com] API, we could enable low-latency mouse looking behavior that could be called from any thread. The new Camera:SetMouseLook[www.leadwerks.com] command allows us to perform the mouse look updating in the rendering thread, right before a frame is drawn, just like we did with our VR implementation.

Of course, if you want the ultimate responsiveness you can just update the whole game at 240 Hz, but the variable-rate rendering feature allows games to run at a high framerate without being too demanding on the CPU.

These features combined provide strong support for fast-paced games, as well as high-frequency displays and VR headsets, with a difference you can feel whenever you play.

New collision testing features[www.leadwerks.com] allow you to test the intersection of two entities outside of the physics simulation. This can be used for improved object holding or custom player movement.

Although BC7 provides better quality texture compression, the editor now defaults to using DXT5, which compresses much faster and provides a more responsive user experience, especially when converting large batches of images into DDS format. You can switch to BC7 compression if you wish by changing the Material Generation > Compression format setting in the program options. The images below show a comparison of BC1 (DXT1) to BC7. Although DXT1 is lower quality compression than DXT5, both formats will have some similar artifacts.

BC7 does provide reduced artifacts, using the same storage space as DXT5, but at the cost of increased compression time. Many developers may prefer to have faster texture compression / conversion over slightly higher quality.

You can read more about texture compression formats here[www.reedbeta.com].

The latest update fixes more than 75 bugs that were identified since the launch of Leadwerks 5, providing a stable and smooth experience for new and experienced developers. A big thanks is due to the entire community for their help identifying important issues. The engine currently has a 97.7% bug closure rate for all reported issues.

We've also migrated our site to a new web hosting company, so the forum, blogs, and downloads system will load a lot faster now.

The following new commands have been added to the engine API:

• Display:GetRefreshRate

• Hmd:GetRefreshRate

• Camera:SetMouseLook

• Entity:CollisionTest

• Entity:SetPlayerSize

The latest update uses new technologies and techniques. Some modifications are needed to prepare your existing project for use with version 5.0.2.

Newton Game Dynamics is now compiled separately as a set of DLLs. This provides us with the ability to debug game physics without a game's source code, and provides faster engine build times, so we can get updates out to you more frequently. You can get these by opening the project manager (File > Project Manager) and pressing the sync button to update your project.

The following DLLs will be added to your project:

• newton.dll

• newton_d.dll

• dCustomJoints.dll

• dCustomJoints_d.dll

• dContainers.dll

• dContainers_d.dll

This cuts build times for the whole engine down to about three minutes.

In addition to the project update described above, C++ projects requires two additional actions. Ideally, you should apply these changes before updating the project in the project manager.

In the Visual Studio project settings, set Linker > System > Stack Reserve Size to 4194304. Make sure this is applied to both the Debug and Release configurations.

You must also add the Microsoft GameInput library via nuget. In Visual Studio, select the Tools > NuGet Package Manager > Manage Nuget Packages for Solution... menu item, search for "GameInput" and apply to the project.

If you ran the project update before performing this step, the interface will incorrectly show the package as installed. If this happens, press the uninstall button, then find and install the Microsoft GameInput library again. If the GameInput library is not installed in your project, you will get linking errors when you try to compile it.

New C++ projects created with Leadwerks 5.0.2 will be created with these settings enabled by default.

Thank you for your support as we continue on to the development of Leadwerks 5.1, which is planned to provide better performance and more optimizations aimed at low-end and older hardware, as well as new visual effects and tools.