It's interesting that when you become an expert on something, you're not sparing any effort to see how something works, but rather you're focusing on creating something. And so everything becomes easier.
At this point of learning there is a glimpse of a low idea of creating a game, but the secret of all this is to keep it simple and to be very clear that a game is a game, and not an exact simulation of the real world. For example anyone who has a low idea of the red planet, will understand
What's new
EAX audio effects for supported hardware.
Source class renamed to "Speaker".
Plane joint for 2D physics, so now you can make Angry Birds with Vulkan graphics.
Fixed DPI issues with fullscreen mode.
Added impact noise to barrels, fixed Lua collision function not being called.
Script functions now start with "Entity:" instead of "Script:", i.e. Entity:Update() instead of Script:Update().
Additionally, four examples can be run showing var
I've been doing some work on the sound system in Leadwerks 5 beta, and I added EAX effects in. If you have a dedicated sound card this can be used to add some nice reverb effects that make your sound environment sound a lot more real:
Here's the simplest usage:
auto fx = LoadSoundEffect("Sound/FX/sewerpipe.json");
auto listener = CreateListener(world);
listener->SetEffect(fx);
This will apply the effect to all mono sources. Stereo sources are assumed to be music or GUI n
Loading sounds in Leadwerks has always been straight forward. A sound file is loaded from the disk, and with the Source class emits the sound in 3D space. The sound entity also has a play function, but it's only really good for UI sounds. There is also Entity::EmitSound() which will play the sound at the entity's location. (You can also throw in a Source, but it'll auto release the object when it's done.)
While this is OK for small games, larger games in which sounds may change might mean y
An update for Leadwerks 5 is now available.
The Vulkan data transfer system has been revised and is now simpler but uses more memory. Data is likely to be quadruple-buffered, but it's a fairly small amount of data and this isn't a big concern.
I fixed a bad bug where multiple threads were accessing a global variable in the Mat4::GetQuaternion function. This fixes the object flashing glitch that was visible in previous builds.
The engine is updated to the latest version of Newton
Coming to the end of my prototype of a 3d game, and with background music by Hanz Zimmer ( Time ). I saw my progress in many aspects, always something to learn, always something to improve, I didn't intend to make a game, that has never been the goal.
Rather, the effort and dedication immeasurably, was to improve on something learned. And here I was with the powerful leadwerks engine, where his greatest power lay in making everything very easy.
About the project
The prototype i
The best way to test the new engine is to use it to make something. I am messing around with the beginnings of a new first-person shooter template. I'm telling everyone involved "We are remaking Doom, but a little differently" and it actually works really well. Everyone understand what it should look like, and there is no need to establish a new visual style. We can tell when we have it right, and when we have it wrong. And the original game gives us a sort of benchmark for quality and performan
An update is available for the Leadwerks 5 beta.
Shadow updating is fixed so the lights no longer turn black during the update whenever a shadow changes.
We're now using multiview to draw all six faces of a cube shadow map in one single pass! Point light shadow updates are something that used to be a considerable bottleneck in Leadwerks 4, and their performance impact is now very insignificant. Thanks to Sascha Williams for his excellent Vulkan examples.
Joints are finished, a new
Leadwerks 3 / 4 was aimed at beginners who were completely new to game development. Since we were the first game engine on Steam, this made a lot of sense at the time, and the decision resulted in a successful outcome. However, in the next engine we are taking a different approach. (This is a direct result of Steam Direct.)
Enterprise is a new market I am pursuing, and we have a lot of interest from aerospace and defense VR developers. The fact that I am American also helps here. There are
I'm happy to say the physics joint class in the new engine is completed. I made all the members that are not meant to be accessed private. One interesting part is the parent and child public members, which are constant pointers to private members. This should result in a read-only member in C++. A sol property is used to expose this to Lua in a read-only manner.
The upvector joint will align an object's Y axis to any vector you set, but still allow rotation around the axis. This is perfect
The following changes have been made to the GLTF model loader:
Correctly loaded rotations and orientations.
Mesh collision caching for faster loading.
Supports transforms with negative scale and correct face orientation.
Support for adjustable alpha cutoff value.
Support for KHR_materials_unlit extension (full bright materials).
This model from SketchFab was useful for testing because it uses so many features of the GLTF format:
https://sketchfab.com/
There are two aspects of GLTF files that have non-optimal loading speed. First, the vertex data is not stored in the same exact layout and format as our vertex structure. I found the difference in performance for this was pretty small, even for large models, so I was willing to let it go. Tangents can take a bit longer to build, but those are usually included in the model if they are needed.
The second issue is the triangle tree structure which is used for raycasting (the pick commands). I
A big update is now available for beta subscribers!
Multipass Rendering
You can use several cameras to increase the depth range or mix 2D and 3D graphics.
2D Graphics
As discussed earlier, 2D graphics are now supported using persistent 2D objects.
Depth Sorting
Multiple layers of transparency will now render in correct order, with lighting in each layer. Note that I used an empty script called "null.lua" to prevent the glass surfaces here from being collapsed at loa
Previously, we saw how the new renderer can combine multiple cameras and even multiple worlds in a single render to combine 3D and 2D graphics. During the process of implementing Z-sorting for multiple layers of transparency, I found that Vulkan does in fact respect rasterization order. That is, objects are in fact drawn in the same order you provide draw calls to a command buffer.
Furthermore, individual primitives (polygons) are also rendered in the order they are stored in the indice b
Previously I described how multiple cameras can be combined in the new renderer to create an unlimited depth buffer. That discussion lead into multi-world rendering and 2D drawing. Surprisingly, there is a lot of overlap in these features, and it makes sense to solve all of it at one time.
Old 2D rendering systems are designed around the idea of storing a hierarchy of state changes. The renderer would crawl through the hierarchy and perform commands as it went along, rendering all 2D elemen
Current generation graphics hardware only supports up to a 32-bit floating point depth buffer, and that isn't adequate for large-scale rendering because there isn't enough precision to make objects appear in the correct order and prevent z-fighting.
After trying out a few different approaches I found that the best way to support large-scale rendering is to allow the user to create several cameras. The first camera should have a range of 0.1-1000 meters, the second would use the same n
Still a lot of things left to do. Now that I have very large-scale rendering working, people want to fill it up with very big terrains. A special system will be required to handle this, which adds another layer to the terrain system. Also, I want to resume work on the voxel GI system, as I feel these results are much better than the performance penalty of ray-tracing. There are a few odds and ends like AI navigation and cascaded shadow maps to finish up.
I am planning to have the engine mor
I spent a whole week for learning UE4 with cpp, yep, UE4 is a great engine for sure, but I found out that my mind could not understand the way UE4 works easily. It is too complex and made me tired. Then I returned to my Leadwerks project and felt so familiar. Soooo... sweet, everything is simple as it is
It felt like I have had a long trip to UE city then return to my hometown. I miss Leadwerks indeed.
Last year, I thought I could only use Leadwerks with LUA and never touch its CPP sid
A new build is available on the beta branch on Steam.
Updated to Visual Studio 2019.
Updated to latest version of OpenVR and Steamworks SDK.
Fixed object tracking with seated VR mode. Note that the way seated VR works now is a little different, you need to use the VR orientation instead of just positioning the camera (see below).
Added VR:SetRotation() so you can rotate the world around in VR.
The VRPlayer script has rotation added to the left controller. Pres
If were a user of BlitzMax in the past, you will love these convenience commands in Turbo Engine:
int Notify(const std::wstring& title, const std::wstring& message, shared_ptr<Window> window = nullptr, const int icon = 0)
int Confirm(const std::wstring& title, const std::wstring& message, shared_ptr<Window> window = nullptr, const int icon = 0)
int Proceed(const std::wstring& title, const std::wstring& message, shared_ptr<Window> window = nullptr, co
A huge update is available for Turbo Engine Beta.
Hardware tessellation adds geometric detail to your models and smooths out sharp corners.
The new terrain system is live, with fast performance, displacement, and support for up to 255 material layers.
Plugins are now working, with sample code for loading MD3 models and VTF textures.
Shader families eliminate the need to specify a lot of different shaders in a material file.
Support for multiple monitors and be
New commands in Turbo Engine will add better support for multiple monitors. The new Display class lets you iterate through all your monitors:
for (int n = 0; n < CountDisplays(); ++n)
{
auto display = GetDisplay(n);
Print(display->GetPosition()); //monitor XY coordinates
Print(display->GetSize()); //monitor size
Print(display->GetScale()); //DPI scaling
}
The CreateWindow() function now takes a parameter for the monitor to create the window on / relative to.
auto displ
