An often-requested feature for terrain building commands in Leadwerks 5 is being implemented. Here is my script to create a terrain. This creates a 256 x 256 terrain with one terrain point every meter, and a maximum height of +/- 50 meters:
--Create terrain
local terrain = CreateTerrain(world,256,256)
terrain:SetScale(256,100,256)
Here is what it looks like:
A single material layer is then added to the terrain.
--Add a material layer
local mtl = LoadMaterial("Materials/Dirt
Here are some things I did in the last couple days to fix a computer that was basically unusable.
It seems that Superfetch was rebranded to "SysMain" in an update and automatically re-enabled. If your computer is grinding away either the CPU or disk usage while doing nothing, this is the culprit. Disable it in Windows services.
The XBox games bar is suspect. I recommend disabling it now that FRAPS supports Vulkan.
Some features in Visual Studio are making it unusably slow.
In
A new beta is uploaded with lots of new features and improvements. Things are really taking shape!
Animation is now supported and it's really fast. Two examples are included.
Package loader plugins now supported, VPK package loader for Source Engine games included with example.
Added localization example.
Shaders folder very neatly organized, now contains shader family files.
Config folder eliminated.
Engine headers cleaned up and organized.
Lots
I created a test of 1000 animated crawler models to see how the performance of Vulkan stacks up against our older OpenGL renderer. Here it is in OpenGL running at 37 FPS, which is pretty respectable considering how many animations are playing (and about 4 million polygons).
With Vulkan the same test yields a framerate of 66 FPS, 78% faster than the OpenGL version.
Here is a video of the characters animating. Each skeleton is its own unique animation system, there are no sha
It's been nearly a year since I made the decision to port our OpenGL renderer over to Vulkan, and it has been very difficult work, but we are getting back up to speed. I was able to get skinned animation working for the first time in Vulkan yesterday, using a slightly modified version of our original animation shader code.
The system works exactly the same as in Leadwerks 4, with a few differences:
Animation features are confined to the Model class only, and are no longer
Analytics is a feature I have long thought was a good candidate to be moved into a plugin.
It is an optional features that only some users care about.
It imports some pretty big third-party libraries into the engine.
It requires an extra DLL be distributed with your game.
It's a totally self-contained features that is easy to separate out from the rest of the engine.
I have uploaded my code for Analytics in Leadwerks here as a new empty Visual Studio project:
The addition of our plugin system makes the engine feel different. There is a stronger distinction between core and non-essential functionality. I removed a lot of third-party libraries from the project and am just focusing on graphics, physics, pathfinding, and other features that are core to the functioning of your game. Things like file importers terrain generation, etc. can be stored away in self-contained optional plugins, or can be part of the editor project, and do not need to reside in t
Leadwerks 4 supports compressed and encrypted game files in ZIP format, but there are many different custom package formats different games use. The plugin system in Leadwerks 5 allows us to create importers for these different package formats so we can access content directly from commercial games you have installed on your computer. The example below shows how to load a VTF texture from the game Half-Life 2 directly from the game's install files.
First we need to load some plugins to deal
I've restructured the plugin SDK for our new engine and created a new repository on Github here:
https://github.com/Leadwerks/PluginSDK
The GMF2 format will only be used as an internal data transfer protocol for model loader plugins. Our main supported file format will be GLTF.
As of now, the plugin system can be used to write texture loaders for different file formats, model loaders, or to modify behavior of particles in the new particle system. The FreeImage texture loader has been
The Leadwerks 5 beta will soon be updated with particle emitters and an example particle system plugin. Previously, I showed some impressive results with physically interactive particles that collide with and exert forces on the environment. I decided to use the plugin system for controlling particle behavior, as this offers the best performance and can be run on the physics thread.
A particle system plugin uses some predefined structures and functions to modify the behavior of particles w
I made some changes to the design of the particle system. I am less concerned with the exact behavior of particles as they move around and move interested right now in building a system with good performance and deep physics interactions. Although I want particle behavior to be customizable, I don't think scripts are the right tool for the job. C++ plugins are better suited for this for two reasons.
C++ is much faster, and particles are a system that will make heavy use of that.
L
I wanted to work on something a bit different, and this sure is different. I've got a framework of a new particle system worked out. What's really special about this system is the amount of interactivity the particles will allow.
Particle-world collisions.
Particle-particle collisions (repulsion)
Particle-particle cohesion (fluids with surface tension)
Instead of just being a visual effect, I want our new particles to be fully interactive with physics so that particl
Premake is multiplication project maker.Unlike CMake, it simply generates a project file for the given IDE giving you a clean result. You only need the one light weight executable and a lua script for this to work. I've spent today setting it up with Leadwerks. I haven't tested Linux yet, but it should work.
My premake5.lua file:
g_LeadwerksHeaderPath = "./Engine/Include"
g_LeadwerksLibPath = "./Engine/Libs"
function GlobalSettings()
-- Include Directories
includedirs
{
"%{prj.na
Putting all the pieces together, I was able to create a GUI with a sprite layer, attach it to a camera with a texture buffer render target, and render the GUI onto a texture applied to a 3D surface. Then I used the picked UV coords to convert to mouse coordinates and send user events to the GUI. Here is the result:
This can be used for GUIs rendered onto surfaces in your game, or for a user interface that can be interacted with in VR. This example will be included in the next beta upd
I have been working on 2D rendering off and on since October. Why am I putting so much effort into something that was fairly simple in Leadwerks 4? I have been designing a system in anticipation of some features I want to see in the GUI, namely VR support and in-game 3D user interfaces. These are both accomplished with 2D drawing performed on a texture. Our system of sprite layers, cameras, and sprites was necessary in order to provide enough control to accomplish this.
I now have 2D drawin
In Leadwerks 4, render-to-texture was accomplished with the SetRenderTarget command, which allowed a camera to draw directly to a specified texture, while hiding the underlying framebuffer object (FBO). In the new engine we have a bit more explicit handling of this behavior. This is largely in part due to the use of Vulkan's bindless design, which greatly improves the context-binding design of OpenGL. The Leadwerks "Buffer" class was never documented or officially supported because the underlyin
I think I've finally finished my approach in input for my project. This is the final result.
//========= Copyright Reep Softworks, All rights reserved. ============//
//
// Purpose:
//
//=====================================================================//
#include "stdafx.h"
#include "gamewindow.h"
#include "gameworld.h"
int main(int argc, const char* argv[])
{
App::ParseCommandLine(argc, argv);
auto window = CreateGameWindow("GameTemplate");
auto world = CreateGameWorld(window);
i
2019 was slow year for my gamedev hobby.
Forth community project really has some good original content, i will make sure it gets released in a form or another.
Still working on my game when i find the time.
Lurking around and reading about leadwerks 5 progress heh, go Josh!
Maybe we get another tournament after Le5 is release Somehow the tournament gives good motivation to make games.
Cheers to everyone and a good new year.
Some pulsating text examp
The GUIBlock structure now has an iVec4 "clipregion" member. This allows you to set a clipping region around a block to prevent it from drawing outside the region. The region will automatically be shrunk to show only the visible area of the widget, within the visible area of its parent. The purpose of this is to prevent text from overflowing outside of the widget. I found this necessary because the multi-line text area widget involves the dynamic creation of different persistent 2D elements, and
An update is available for Leadwerks Game Engine 5 beta. The GUI system is now working with support for the following items:
Panel
Button
Tabber
Label
Hyperlink
Text field (editable, single line)
Text area (multiline, read-only, allows text selection)
The GUI scripts use a system of "blocks". You can add a solid rectangle, a wire rectangle, (both support rounded corners) or a text block.
The drawing hierarchy is not yet respected, so
I'm back from I/ITSEC. This conference is basically like the military's version of GDC. VR applications built with Leadwerks took up about half of Northrop Grumman's booth. There were many interesting discussions about new technology and I received a very warm reception. I feel very positive about our new technology going forward.
I am currently reworking the text field widget script to work with our persistent 2D objects. This is long and boring but needs to be done. Not much else to
Here are some screenshots showing more complex interface items scaled at different resolutions. First, here is the interface at 100% scaling:
And here is the same interface at the same screen resolution, with the DPI scaling turned up to 150%:
The code to control this is sort of complex, and I don't care. GUI resolution independence is a complicated thing, so the goal should be to create a system that does what it is supposed to do reliably, not to make complicated things s
The prototype of a four-wheeled vehicle is completed, where the third person player can get on and off the vehicle by pressing the E key. To move the vehicle either forward or backward, is done with the keys W, and the key S, to brake with the space key. And the principle is the same as when driving the character, a third person camera goes behind the car orbiting 360 degrees.
I don't think the vehicle is that bad, but I'm absolutely sure it can be improved. The idea is that this expl
