The design of Leadwerks 4 was meant to be flexible and easy to use. In Leadwerks 5, our foremost design goals are speed and scalability. In practical terms that means that some options are going to go away in order to give you bigger games that run faster.
I'm working out the new animation system. There are a few different ways to approach this. In situations like this I find it is best to start by deciding the desired outcome and then figuring out how to achieve that. So what do we want?
After observing the behavior of the previous test, I rearranged the threading architecture for even more massive performance gains. This build runs at speeds in excess of 400 FPS with 100,000 entities....on Intel integrated graphics!
I've had more luck with concurrency in design than parallelism. (Images below are taken from here.)
Splitting the octree recursion up into separate threads produced only modest gains. It's difficult to optimize because the sparse octree is unpredicta
I am proud to show off our first performance demonstration which proves that my idea for the Leadwerks 5 renderer works. To test the renderer I created 100,000 instanced boxes. The demo includes both regular and a mock VR mode that simulates single-pass stereoscopic rendering with a geometry shader.
The hardware I tested on is an Intel i7-4770R (for graphics too) which is a few years old.
Now this is not a perfect benchmark for several reasons. There is no frustum culling being perform
After working out a thread manager class that stores a stack of C++ command buffers, I've got a pretty nice proof of concept working. I can call functions in the game thread and the appropriate actions are pushed onto a command buffer that is then passed to the rendering thread when World::Render is called. The rendering thread is where all the (currently) OpenGL code is executed. When you create a context or load a shader, all it does is create the appropriate structure and send a request over
The Leadwerks 4 renderer was built for maximum flexibility. The Leadwerks 5 renderer is being built first and foremost for great graphics with maximum speed. This is the fundamental difference between the two designs. VR is the main driving force for this direction, but all games will benefit.
Multithreaded Design
Leadwerks 4 does make use of multithreading in some places but it is fairly simplistic. In Leadwerks 5 the entire architecture is based around separate threads, which is chal
When considering the script system in Leadwerks 5, I looked at alternatives including Squirrel, which is used by Valve in many games, but these gave me a deeper appreciation for the simplicity of Lua. There are only a handful of rules you need to learn to use the language, it’s fun to use, yet somehow it does everything you could ever need.
These were three big issues I had to solve. First, the Leadwerks 5 API makes extensive use of smart pointers, which our binding library tolua++ does not
Our implementation of Lua in Leadwerks 5 is shaping up to be a dream come true. Below are some of the great improvements that are being made.
Access STL Containers in Lua
You can access STL containers directly from Lua:
for n = 1, #entity.kids do
entity.kids[n]:Move(1,0,0)
end
while #entity.kids > 0 do
entity.kids[1]:SetParent(nil)
end
In fact, verbose commands like CountChildren() and GetChild() are no longer needed at all. On the C++ side you can use this:
for (int
The Leadwerks 5 API uses C++11 smart pointers for all complex objects the user interacts with. This design replaces the manual reference counting in Leadwerks 4 so that there is no Release() or AddRef() method anymore. To delete an object you just set all variables that reference that object to nullptr:
auto model = CreateBox();
model = nullptr; //poof!
In Lua this works the same way, with some caveats:
local window = CreateWindow()
local context = CreateContext(window)
local world =
My Gigabyte Brix pro lacks an audio in port and I was not able to find a USB microphone yesterday. However, I found a cheap webcam with audio support and have been using this to test voice recording, and it works great. Here is the final voice recording API:
bool Sound::StartRecording(const int frequency = 22050, const int format = Sound::Mono8, const int buffersize = 20480)
Sound* Sound::StopRecording()
bool Sound::StopRecording(Lobby* lobby)
lobby->SetVoiceFilter(const uint64 steamid, c
Previously I talked about a voice recording API done through Steamworks. However, OpenAL already has a simple recording API that handles this. The only thing the Steamworks API adds is compression (presumably OGG) to send the data.
I quickly implemented an OpenAL-based recording API, although I do not presently have any recording hardware device to test with. OGG compression can be added with the Ogg library that is already built into Leadwerks.
Here is my modified recording API:
s
Being able to communicate with a gaming headset or microphone is an important part of fast-paced multiplayer gaming. Therefore, Leadwerks 4.6 will feature easy to use voice recording features that allow you to talk to your teammates or taunt your opponents, in addition to a new peer-to-peer networking system.
The system is largely automated so that you only have to call a single command:
Voice::SetRecording(true)
Or in Leadwerks 5:
SetVoiceRecording(true)
In practical usage, y
Previously, I talked about the new peer-to-peer networking system that handles Nat punch-through and allows a sort of "floating" server that stays alive as long as at least one player is in the game.
The lobby system allows you to broadcast to other players that you have a game available to join. The name might be somewhat misleading, as it does not require players to hang out in a chatroom before starting the game. My implementation functions more like a standard game server list.
To
Leadwerks Game Engine 4.6 will feature a new peer-to-peer networking system that solves the NAT punch-through problem and provides an easy way to create a public list of game servers. Together with this and Leadwerks GUI which was released last year, we will soon have the tools to make a great deal of new types of games. Previously we have been focused on single-player games but the ability to create multiplayer games with fast reliable networking opens up a lot of new and fun possibilities.
A big bug fix update just came out for 4.5. Unless there are any major problems then I am going to go back to Europe for a while. I will be focusing on multiplayer features, specifically the P2P, lobby, and voice chat features in Steamworks, as well as converting lots of models to make them ready-to-use with Leadwerks Game Engine.
I am just going to bring my little Gigabyte Brix mini PC. If I need to I can have my big monster machines shipped to me overseas, but I'll start with this one and
I recently picked up an Oculus Rift (CV1) in order to improve our support for this headset. It was easy to make my changes, but having the actual hardware on hand was invaluable in this process, and our support for the Rift is now much better because of this. I have now tried a total of five different VR headsets:
HTC Vive
Valve's duct-taped prototype that was the basis of the HTC Vive.
Oculus Rift DK1
Oculus Rift DK2
Oculus Rift CV1
At one point Leadwe
A new build is available on the beta branch on Steam. This fixes a couple of issues.
Oculus view projection is fixed.
Added VR.AButton, VR.BButton, VR.GripAxis for compatibility with Oculus Touch controllers:
https://www.leadwerks.com/community/topic/17052-vive-and-oculus-controls/
Fixed terrain collision bug:
https://www.leadwerks.com/community/topic/16985-character-controller-falls-through-terrain/
An update is available on the beta branch on Steam.
Fixed missing fall damage: https://www.leadwerks.com/community/topic/17005-i-dont-get-fall-damage/
Fixed LoadAnimation bug: https://www.leadwerks.com/community/topic/16982-modelviewer-load-animation/
May have fixed VR player script and tracking on Oculus Rift.
If you have an Oculus Rift please try creating a new project from the VR template project and tell me your results. If there is still a problem I will go buy
I have Steam peer-to-peer networking commands implemented into Leadwerks 4.6. Here are the commands. Note this complex system has been boiled down to just three simple commands:
class P2P
{
public:
#ifdef LEADWERKS_5
static bool Send(uint64 steamid, const int messageid, shared_ptr<BankStream> data, const int channel = 0, const int flags = 0);
static bool Send(uint64 steamid, const int messageid, shared_ptr<Bank> data, const int channel = 0, const int flags = 0);
static shared_
Here is the second iteration of our VR robotic arm concept. This can be used for the safe planning of robotic motions and early detection of potential problems. VR gives us intuitive manual control with six degrees of freedom along with stereoscopic vision for superior spatial awareness.
I spent a few days setting up a server application and attempting to implement NAT punch through. You can read the details of my adventures here.
Here's what I think:
I can probably get it working.
There's a lot of weird hardware and configurations out there I can't realistically test.
There will always be a certain failure rate which translates into angry users who I can't help.
So I started to think about this backwards, by first asking what we want the user exp
This is a rough timeline of events I am planning in the new year. It is not complete, and may change, but this is just what I am thinking right now.
January 15: Release Leadwerks 5 Alpha Zero subscription
February 1: Launch Kickstarter campaign for development of Leadwerks 5 Alpha One
February 1: Game Tournament
March 3: Kickstarter campaign complete
April 1: Leadwerks 4.6 released (vehicles, NAT punch-through)
June 30: Summer Games Tournament
Jun
It's been an eventful year.
A new beautiful website has been rolled out, and our community software is updated to the latest version of Invision Power Board, which allowed us to move all file storage to Amazon S3 for basically free unlimited storage space for the site.
Documentation moved into a new easy to use system.
The Games Showcase was created.
We had a totally kick-*** Halloween Game Tournament.
Announced the development of Leadwerks 5, added unicode sup
Version 4.5 is updated on the beta branch on Steam.
Fixed small projection error in VR mode.
Added fog settings in editor and into map file format.
Fixed Workshop browser back button not working.
Added VR project template.
Added VR player script
Added friction to hinge joint script.
Added ball and slider joint scripts.
Joint scripts will now use the entity parent for the other joint connection (if it exists).
We've only got about 24
The final step to our VR teleporter mechanic is to make the beam arc. This allows us to climb up to areas above our head.
The trick to this is to take our single beam picking mechanic and split it up into a lot of little segments, for both the intersection test and the visual display. I decided to make a kind of simple physics simulation for this, rather than using bezier curves or another method. The basic idea is you have a starting position and a velocity. You move a point along tha
The next step is to put our scene into VR and look at everything. I'm about six feet tall and the player model seems the same height, so that all looks right. The controllers, as you can see below, are all working with full articulation of all controls. The teleport indicator looks good too.
Now we're going to start our VR player script. We start with a new script and initialize the VR environment in the Start() function. A camera is also created in code, and I deleted the camera