It is now possible to compile shaders into a single self-contained file that can loaded by any Vulkan program, but it's not obvious how this is done. After poking around for a while I found all the pieces I needed to put this together.
Compiling
First, you need to compile each shader stage from a source code file into a precompiled SPIR-V file. There are several tools available to do this, but I prefer GLSlangValidator because it supports the Google #include extension. Put your vertex
I was going to write about my thoughts on Vulkan, about what I like and don't like, what could be improved, and what ramifications this has for developers and the industry. But it doesn't matter what I think. This is the way things are going, and I have no say in that. I can only respond to these big industry-wide changes and make it work to my advantage. Overall, Vulkan does help us, in both a technical and business sense. That's as much as I feel like explaining.
Beta subscribers ca
Vulkan gives us explicit control over the way data is handled in system and video memory. You can map a buffer into system memory, modify it, and then unmap it (giving it back to the GPU) but it is very slow to have a buffer that both the GPU and CPU can access. Instead, you can create a staging buffer that only the CPU can access, then use that to copy data into another buffer that can only be read by the GPU. Because the GPU buffer may be in-use at the time you want to copy data to it, it is b
I've now got the Vulkan renderer drawing multiple different models in one single pass. This is done by merging all mesh geometry into one single vertex and indice buffer and using indirect drawing. I implemented this originally in OpenGL and was able to translate the technique over to Vulkan. This can allow an entire scene to be drawn in just one or a few draw calls. This will make a tremendous improvement in performance in complex scenes like The Zone. In that scene in Leadwerks the slow step i
Using my box test of over 100,000 boxes, I can compare performance in the new engine using OpenGL and Vulkan side by side. The results are astounding.
Our new engine uses extensive multithreading to perform culling and rendering on separate threads, bringing down the time the GPU sits around waiting for the CPU to nearly zero.
Hardware: Nvidia GEForce GTX 1070 (notebook)
OpenGL: ~380 FPS
Vulkan 700+ FPS. FRAPS does not work with Vulkan, so the only FPS counter I have is
Following this tutorial, I have managed to add uniform buffers into my Vulkan graphics pipeline. Since each image in the swapchain has a different graphics pipeline object, and uniform buffers are tied to a pipeline, you end up uploading all the data three times every time it changes. OpenGL might be doing something like this under the hood, but I am not sure this is a good approach. There are three ways to get data to a shader in Vulkan. Push constants are synonymous with GLSL uniforms, althoug
The Vulkan graphics API is unbelievably complex. To create a render context, you must create a series of images for the front and back buffers (you can create three for triple-buffering). This is called a swap chain. Now, Vulkan operates on the principle of command buffers, which are a list of commands that get sent to the GPU. Guess what? The target image is part of the command buffer! So for each image in your swap chain, you need to maintain a separate command buffer If anything changes in y
One of the best points of Vulkan is how shaders are loaded from precompiled Spir-V files. This means GLSL shaders either work or they don't. Unlike OpenGL, there is no different outcome on Intel, AMD, or nVidia hardware. SPIR-V files can be compiled using a couple of different utilities. I favor LunarG's compiler because it supports #include directives.
Shader.vert:
#version 450
#extension GL_ARB_separate_shader_objects : enable
#include "VertexLayout.glsl"
layout(push_constant) unifo
In Vulkan all shader uniforms are packed into a single structure declared in a GLSL shader like this:
layout(push_constant) uniform pushBlock
{
vec4 color;
}
pushConstantsBlock;
You can add more values, but the shaders all need to use the same structure, and it needs to be declared exactly the same inside the program.
Like everything else in Vulkan, shaders are set inside a command buffer. But these shader values are likely to be constantly changing each frame, so how do you hand
While we have Leadwerks today to make our apps, Turbo is currently in development. To make my projects more long term, I decided to take a step back from my VR project and create a wrapper class that apps can use to more easily transfer to the new engine. Keep in-mind, this doesn't cover everything and I'm used the last beta from November for testing so things can change. Regardless, as long as that bridge is made, I can always go back and edit the Turbo stuff as more things come online. The go
I am surprised at how quickly Vulkan development is coming together. The API is ridiculously verbose, but at the same time it eliminates a lot of hidden states and implicit behavior that made OpenGL difficult to work with. I have vertex buffers working now. Vertices in the new engine will always use this layout:
struct VkVertex
{
float position[3];
float normal[3];
float texcoords0[2];
float texcoords1[2];
float tangent[3];
unsigned cha
When a window in Vulkan resizes you have to manually delete the about a dozen objects and then recreate them with the new size. It's unbelievably complicated. They've pushed all the driver complexity onto the application, in an effort to simplify the job of writing drivers. I can see the advantage to this, because OpenGL drivers in the past were always inconsistent, but it is still shocking how many little details they expose in Vulkan. Just resizing a window and swapping the screen buffer invol
Two days and 823 lines of code later, I present to you the Vulkan triangle of awesomeness, running in our engine:
Here are my thoughts on Vulkan:
It's ridiculously verbose. You have to specify every little detail of the rasterizer, there's a million classes to create, and every little variable has to be exactly right. There's really no reason for this because 90% of the code is just something you copy and paste.
Shaders can use GLSL, which seems very weird, but it makes thin
The latest design of my OpenGL renderer using bindless textures has some problems, and although these can be resolved, I think I have hit the limit on how useful an initial OpenGL implementation will be for the new engine. I decided it was time to dive into the Vulkan API. This is sort of scary, because I feel like it sets me back quite a lot, but at the same time the work I do with this will carry forward much better. A Vulkan-based renderer can run on Windows, Linux, Mac, iOS, Android, PS4, an
A new update for Leadwerks Game Engine 4.6 is available on the default branch. This fixes a physics bug that would cause boxes to float into the air after the player stepped on them.
Subscribers can now download my current revision of the Turbo Game Engine design document in the private forum here:
Here are a few excerpts:
The document is still evolving so expect changes and updates.
Luawerks has been updated to 1.2.8, making some small adjustments and fixes to the system. If you have previously purchased Luawerks, this update is available for free on the Leadwerks Marketplace.
Following changes include:
Fixed GUI code for Leadwerks Game Engine 4.6
Removed the feature "allowfullscreenfromeditor" as it was causing conflicts with fullscreen.
Added ignoreeditorwinsettings bool setting to force the game to ignore editor launch settings.
(Sorry f
My last NASA project is complete. There's a physics bug in Leadwerks 4.6 that will get resolved this weekend. Starting Monday I am going to focus on the new engine again and move us forward so we can release in 2020. I am really looking forward to getting back in the game.
Thought I'd show off what I've been working on this weekend. I have implemented procedural grass as found here at Outerra. There is still more work to be done on it but so far it looks promising.
The new game engine needs to roll out with some top-notch examples showing off what it can do. Here's what I want:
First-person shooter
Offroad racing game
Space shoot-em-up side-scroller.
Side-scoller platformer similar to the Contra Playstation game.
Now what I can use your help with is finding good example games on YouTube or Steam that I can start designing these samples around. Post your ideas below!
Leadwerks Game Engine 4.6 is now available on Steam! This free update adds Steam peer-to-peer networking, lobbies, voice chat, and more. A new multiplayer game template makes it easy to get started with your own multiplayer games, adding new depth and interactivity to the fun.
We've also added over 100 bug fixes, making this the most stable release ever to build your game on!
New classes:
Lobby
P2P
Voice
Other changes:
New parameters for bet
This is something I typed up for some colleagues and I thought it might be useful info for C++ programmers.
To create an object:
shared_ptr<TypeID> type = make_shared<TypeID>(constructor args…)
This is pretty verbose, so I always do this:
auto type = make_shared<TypeID>(constructor args…)
When all references to the shared pointer are gone, the object is instantly deleted. There’s no garbage collection pauses, and deletion is always instant:
auto thing = m
An update is available on the beta branch on Steam with a few bug fixes.
I'm going to release 4.6 with the current features because a lot of bugs have been fixed since 4.5 and we're overdue for an official release. 4.7 will add a new vehicle system, character crouching physics, and some other things, and will be out later this year.
.thumb.png.930e14f6185274fc318c83d22a72a188.png)
