Jump to content
You might have seen this graphic comparing the size of the world in different games. I've played Fuel, and never reached the end of the world in that game. You can drive for a very long time on those roads.
We want to use the new engine for realistic simulations of air and ground movements. At normal cruising altitude of a commercial airliner, the pilot has a view range of about 400 kilometers. The image below shows that area (800 x 800 km). You can see the areas of the biggest games
I thought I would share my experience on this; if you're working on Multiplayer, you will need to protect your packets. The solution is simple, let's go through how we can achieve this by implementing what Valve calls "challenge codes". (Some reading on the topic from Valve here: https://developer.valvesoftware.com/wiki/Master_Server_Query_Protocol#Challenge_response).
Disclaimer: this doesn't cover other security techniques like authoritative server or encryption.
So, I've worked on B
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.
Texture loading plugins allow us to move some big libraries like FreeImage into separate optional plugins, and it also allows you to write plugins to load new texture and image formats.
To demonstrate the feature, I have added a working VTF plugin to the GMF2 SDK. This plugin will load Valve texture files used in Source Engine games like Half-Life 2 and Portal. Here are the results, showing a texture loaded directly from VTF format and also displayed in Nem’s nifty VTFEdit tool.
I wanted to work on something a bit easier before going back into voxel ray tracing, which is another difficult problem. "Something easier" was terrain, and it ended up consuming the entire month of August, but I think you will agree it was worthwhile.
In Leadwerks Game Engine, I used clipmaps to pre-render the terrain around the camera to a series of cascading textures. You can read about the implementation here:
This worked very well with the hardware we had available at the time, b
Multithreading is very useful for processes that can be split into a lot of parallel parts, like image and video processing. I wanted to speed up the normal updating for the new terrain system so I added a new thread creation function that accepts any function as the input, so I can use std::bind with it, the same way I have been easily using this to send instructions in between threads:
shared_ptr<Thread> CreateThread(std::function<void()> instruction);
The terrain update nor
The GMF2 data format gives us fine control to enable fast load times. Vertex and indice data is stored in the exact same format the GPU uses so everything is read straight into video memory. There are some other optimizations I have wanted to make for a long time, and our use of big CAD models makes this a perfect time to implement these improvements.
Precomputed BSP Trees
For raycast (pick) operations, a BSP structure needs to be constructed from the mesh data. In Leadwerks Engine thi
My work with the MD3 format and its funny short vertex positions made me think about vertex array sizes. (Interestingly, the Quake 2 MD2 format uses a single char for vertex positions!)
Smaller vertex formats run faster, so it made sense to look into this. Here was our vertex format before, weighing in at 72 bytes:
unsigned char color;
unsigned char boneweights;
unsigned char b
The GMF2 SDK has been updated with tangents and bounds calculation, object colors, and save-to-file functionality.
The GMF2 SDK is a lightweight engine-agnostic open-source toolkit for loading and saving of game models. The GMF2 format can work as a standalone file format or simply as a data format for import and export plugins. This gives us a protocol we can pull model data into and export model data from, and a format that loads large data much faster than alternative file formats.
So I've been researching snowboarding lately to get an idea of what animations and mechanics I need to create for my game. I have learned lots of interesting things since I've only seen snow once or twice in my entire life and have never even tried snowboarding or any other board sports (skateboarding, surfing, etc.) for that matter.
Snowboarding tricks are quite interesting as they are mostly derived from skateboarding. Snowboarding tricks pay homage to their equivalent skating tr
The GMF2 file format provides the fastest possible load times for 3D models. A preliminary specification and SDK for loading and saving files in the GMF2 file format is now available on GitHub here:
A Quake 3 MD3 model loader is included as an example.
Not a lot of people know about this, but back in 2001 Discreet (before the company was purchased by Autodesk) released a free version of 3ds max for modding games. Back then game file formats and tools were much more highly specialized than today, so each game required a "game pack" to customize the gmax interface to support that game. I think the idea was to charge the game developer money to add support for their game. Gmax supported several titles including Quake 3 Arena and Microsoft Flight
I wanted to get a working example of the plugin system together. One thing led to another, and...well, this is going to be a very different blog.
The first thing I had to do is figure out a way for plugins to communicate with the main program. I considered using a structure they both share in memory, but those always inevitably get out of sync when either the structure changes or there is a small difference between the compilers used for the program and DLL. This scared me so I we
I started to implement quads for tessellation, and at that point the shader system reached the point of being unmanageable. Rendering an object to a shadow map and to a color buffer are two different processes that require two different shaders. Turbo introduces an early Z-pass which can use another shader, and if variance shadow maps are not in use this can be a different shader from the shadow shader. Rendering with tessellation requires another set of shaders, with one different set for each
With tessellation now fully implemented, I was very curious to see how it would perform when applied to arbitrary models. With tessellation, vertices act like control points for a Bezier mesh that is subdivided dynamically in screen space. Could tessellation be used to add new details to any low-poly model?
Here is a low-res character model with a pointy head and obvious sharp edges all around his silhouette:
When tessellation is enabled, the sharp edges go away and the mes
Previously I talked about the technical details of hardware tessellation and what it took to make it truly useful. In this article I will talk about some of the implications of this feature and the more advanced ramifications of baking tessellation into Turbo Game Engine as a first-class feature in the
Although hardware tessellation has been around for a few years, we don't see it used in games that often. There are two big problems that need to be overcome.
We need a way to preven
Now that I have all the Vulkan knowledge I need, and most work is being done with GLSL shader code, development is moving faster. Before starting voxel ray tracing, another hard problem, I decided to work one some *relatively* easier things for a few days. I want tessellation to be an every day feature in the new engine, so I decided to work out a useful implementation of it.
While there are a ton of examples out there showing how to split a triangle up into smaller triangles, useful discus
There is always something new to learn, and when my native language is not English, there is a way of learning called brute force, this leads to two things, first, you learn, and second a high percentage is learning to do things wrong, of course not always.
Today I had a kind of Eureka, I actually discovered how to properly implement the sliding joints to create springs for a vehicle, the point here is to get to understand how this should work and I think I've achieved it. In the end I'm le
Shadow maps are now supported in the new Vulkan renderer, for point, spot, and box lights!
Our new forward renderer eliminates all the problems that deferred renderers have with transparency, so shadows and lighting works great with transparent surfaces. Transparent objects even receive lighting from their back face automatically!
There is some shadow acne, which I am not going to leave alone right now because I want to try some ideas to eliminate it completely, so you neve
I'm still spending hours of tests, changing and seeking properties to obtain the best balanced car driving experience possible.
It's something between the mass used, the joints values, and the smoothing force.
This until now the best I get with a car, which is even performing a salto jump at 2.30 and other somersault crashing at 3.15
The FPS are nice, I'm happy with this.
After about four days of trying to get render-to-texture working in Vulkan, I have everything working except...it doesn't work. No errors, no clue what is wrong, but the renderer is not even clearing the depth attachment, which is why the texture read shown here is flat red.
There's not much else to say right now. I will keep trying to find the magic combination of cryptic obscure settings it takes to make Vulkan do what I want.
This is very hard stuff, but once I have it working
Now that we have lights working in our clustered forward Vulkan renderer (same great technique the latest DOOM games are using) I am starting to implement shadow maps. The first issue that came up was managing render-to-texture when the texture might still be in use rendering the previous frame. At first I thought multiple shadowmaps would be needed per light, like a double-buffering system, but that would double the number of shadow textures and video memory. Instead, I created a simple object