Stride Game Engine

Investigating SPIR-V for the shader system - Part 3

Wed, 24 Dec 2025 00:00:00 +0000

In this blog post, we will focus on how the new SDSL parser has been implemented through writing a prototype expression parser as an example. We will see how this can be possible without sacrificing performance and allocating the least amount of memory possible. And finally see how this improved on the current shader parser system in Stride.

If you're interested in the other parts of this blog series :

Part 1 An introduction to the project
Part 2 we parse and assemble some SPIR-V

Table of Contents:

So many things happened since the the last blog post but none were written in a blog post format, fortunately for me, with the holidays I have time to tell more about it.

Preface 🔗

Last time we went through SPIR-V and how to parse/assemble SPIR-V using C#, this time we'll see how the new SDSL parser was built from the ground up. I'll go through the implementation of a small parser to illustrate the design chosen for SDSL.

We're also keeping the same principles that this project started with :

Fast
Low heap allocation
Easy to update/modify

This post will show much more code, most of it will serve as an example, it won't always compile and might need some tweeking but can be used as a base to understand how the new SDSL parser works.

Why not using a library ? 🔗

Why should we ? 🤔

SDSL is not going to change much and we're only maintaining one language so we can write a simple parser that will only work for SDSL.

Parsing a programming language is easy, the difficult part comes after parsing a language.

I've experimented twice with very powerful libraries, they were easy to use and would have us maintain fewer lines of code by sacrificing on speed and heap allocation.

The third experiment with parsing SDSL was with a handmade recursive descent parser, it was the easiest and fastest to implement and apparently used in major compiler frontends like clang.

At the time, I hadn't had the chance of finding a proper (read idiot proof) explanation of how to implement a recurisve descent parser but I'd like to mention Kay Lack's video which is the clearest explanation I could ever found on this subject. I recommend you give a watch to have a better understanding of what will be written.

The 3rd experiment 🔗

It started as an expression/statement parser to compare with the current parser. In our case statements are what takes the most processing in SDSL, a low hanging fruit that we can reach fast and benchark against our current shader system. It ended up working so well it became the main parser for SDSL !

To avoid allocation, we will avoid creating classes as much as we can except for the abstract syntax tree (AST).

The tree 🔗

We'll define some basic nodes for our AST, the first will be an abstract node and we'll derive everything from it.

// This struct will retain data of which part of text a node in our AST will represent
public record struct TextLocation(string Text, Range Range);

// Each node will have to store location
public abstract class ASTNode(TextLocation location)
{
    TextLocation Location { get; set; } = location;
}

// Expressions are values or a combinations of them with 
public abstract class Expression(TextLocation location) : ASTNode(location);

// Literals will contain the basic values we'll be dealing with in expressions
public abstract class Literal(TextLocation location) : Expression(location);

// Such as :

public class IntegerLiteral(long value, TextLocation location) : Literal(location);
public class FloatLiteral(double value, TextLocation location) : Literal(location);

// And others but this will be enough, I'm also leaving implementation details out for simplicity

// We'll first focus on binary operations, but there are unary and ternary operations too

public enum Operators 
{
    None,
    Multiply,
    Divide,
    Moderand,
    Add,
    Subtract,
    LeftShift,
    RightShift,
    //...

}


public class BinaryExpression(Expression left, Operator operator, Expression right, TextLocation location) : Expression(location);

Scanning code 🔗

For our parser we need a construct that will keep track of the position of the parser in the text. Then we'll need to define our rules which, when matched, will advance our position in the text and when not, will reset the position. For that we create a scanner object with two parameters, the code being scanned and the position we're at.

Our parser rules will be written as plain function, they don't need to be abstracted any other ways as functions are reusable enough and we don't allocate anything on the heap by calling a function.

We should still be mindful of the limitations of recursion!

public ref struct Scanner(string code)
{
    public string Code { get; } = code;
    public int Position { get; set; } = 0;

    // Sometimes we'd like to peek one or more characters to reject rules early
    public int Peek() => (int)Code[Position];
    public ReadOnlySpan<char> Peek(int size) => Code[Position..(Position+size)];

    public bool Match(string matchString, bool caseSensitive)
    {
        // The implementation is fairly straightforward :) 
    }
}

Building blocks 🔗

For our parser, the rules will be functions returning a boolean, taking as parameters the scanner and an out reference to a node of the tree.

Here's an example for the integer parser :

// A utility function that checks if the char is a digit with a specific value or in a range

bool IsDigitValue(char c, int value)
    => char.IsDigit(c) && (c - '0' == value);

bool IsDigitRange(char c, Range range);


bool ParseIntegerLiteral(ref Scanner scanner, out IntegerLiteral literal)
{
    // We keep track of the position before we match anything
    // We can also create copies of the struct instead by storing it in different variables
    // but I prefer copying the least amount of data possible
    var start = scanner.Position;
    // If we get a zero, that's our value :D, integer literals never start with a zero
    if(IsDigitValue(scanner.Peek(), 0))
    {
        scanner.Position += 1;

        literal = new(0, new((int)(scanner.Peek() - '0'), new(scanner.Code, position..scanner.Position)));
        return true;
    }
    // We keep scanning until there is no digits
    else if(char.IsDigit(scanner.Peek()))
    {
        while(char.IsDigit(scanner.Peek()))
            scanner.Position += 1;

        literal = new(0, new(int.Parse(scanner.Code[position..scanner.Position]), new(scanner.Code, position..scanner.Position)));
        return true;
    }
    // If we don't match any digit then we have to go back in the starting position
    // This is not necessary here so we can omit this line of code
    // In some cases this line of code will prove very relevant
    scanner.Position = start;

    // In some cases we never allocate the node in the heap because we haven't matched our rules
    // This is perfect for reducing allocation in our case
    literal = null!;
    return false;
}

We can derive this integer parser into a float parser quite easily, each language has its own rules of writing floating point numbers and it's up to the author of the language to decide which one is best.

Abstractions 🔗

After implementing the floating point parser we can abstract both those parsers into one encompassing everything very simply.

bool ParseNumberLiteral(ref Scanner scanner, out NumberLiteral number)
{
    var start = scanner.Position;
    if(ParseIntegerLiteral(ref scanner, out var integerLiteral))
    {
        number = (NumberLiteral)integerLiteral;
        return true;
    }
    else if(ParseFloatLiteral(ref scanner, out var floatLiteral))
    {
        number = (NumberLiteral)floatLiteral;
        return true;
    }
    // Same as before :)
    scanner.Position = start;
    number = null!;
    return false;
}

We can even go one step higher and use this number parser to create our first binary operation parser :



// A utility function that resets the position. We can modify it to catch errors
bool ExitParser<TNode>(ref Scanner scanner, out TNode node, int position) where TNode : ASTNode;

// A utility function that looks ahead by skipping some white space.
// Looking ahead is something that happens quite often when parsing SDSL.

bool FollowedByAny(ref Scanner scanner, string chars, out char value, bool withSpaces = false, bool advance = false);


bool Spaces(ref Scanner scanner, int min = 0)
{
    var start = scanner.Position;
    while(char.IsWhiteSpace(scanner.Peek()))
        scanner.Position += 1;
    if(scanner.Position - start >= min)
        return true;
    else
    {
        scanner.Position = start;
        return false;
    }
}

bool Mul(ref Scanner scanner, out Expression expression)
{
    // Mulitplicative expressions can be stringed together, so we should use a loop
    char op = '\0';
    expression = null!;
    var position = scanner.Position;
    do
    {
        Spaces(ref scanner, 0);
        // If we have reached an operator and have already parsed a first expression
        if (op != '\0' && expression is not null)
        {
            // We nest the multiplications by creating a binary expression containing the binary expression we just finished parsing
            if (ParseNumberLiteral(ref scanner, out var number))
                expression = new BinaryExpression(expression, op.ToOperator(), number, scanner[position..scanner.Position]);
            else return ExitParser(ref scanner, out expression, position);
        }
        // In the case we haven't reached an operator
        else if (expression is null && op == '\0')
        {
            // Our number becomes our result expression
            if (ParseNumberLiteral(ref scanner, result, out var number))
                expression = number;
            else return ExitParser(ref scanner, out expression, position);
        }
    }
    // We keep parsing until we don't see any multiplicative operators
    while (FollowedByAny(ref scanner, "*/%", out op, withSpaces: true, advance: true));
    if (expression is not null)
        return true;
    else return ExitParser(ref scanner, result, out expression, position, orError);
}

We can also write the addition/subtraction parser, following the operator precedence :

bool Add(ref Scanner scanner, out Expression expression)
{
    char op = '\0';
    expression = null!;
    var position = scanner.Position;
    do
    {
        Spaces(ref scanner, 0);
        if (op != '\0' && expression is not null)
        {
            if (Add(ref scanner, out var mul))
                expression = new BinaryExpression(expression, op.ToOperator(), mul, scanner[position..scanner.Position]);
            else return ExitParser(ref scanner, out expression, position);
        }
        else if (expression is null && op == '\0')
        {
            if (Mul(ref scanner, result, out var prefix))
                expression = prefix;
            else return ExitParser(ref scanner, out expression, position);
        }
    }
    while (FollowedByAny(ref scanner, "+-", out op, withSpaces: true, advance: true));
    if (expression is not null)
        return true;
    else return ExitParser(ref scanner, result, out expression, position, orError);
}

The sharpest ones will notice I'm not using recursion for everything, i'm using a while loop. This is a small optimisation called precedence climbing to avoid to many recursions when parsing long and complex expressions.

And that's the gist of it! The rest is about adding all the other elements of the language. For SDSL that was about parsing a subset of HLSL, add the SDSL extra features and digging through all of the source code to find any quirks of the language and make sure we can handle them.

In the future SDSL will be less reliant on HLSL syntax and follow one more similar to C# to avoid any confusion when switching between the two languages.

Benchmarks 🔗

It wouldn't mean anything without benchmarks, so let's have a typical SDSL shader to benchmark for.

namespace MyNameSpace
{
    shader Parent 
    {

        struct MyStruct {
            int a;
        };

        stream int a;

        stage abstract void DoSomething();

        void Method()
        {
            int a = 0;
            float4 buffer = float4(1,3, float2(1,2));
            float4x4 a = float4x4(
                float4(1,2,3,4),
                float4(1,2,3,4),
                float4(1,2,3,4),
                float4(1,2,3,4)
            );
            for(;;)
            {
                if(i == 5)
                {
                    Print(i);
                }
            }
            int b = (a - 10 / 3 ) * 32 +( streams.color.Normalize() + 2);
            if(a == 2)
            {
            }
        }
    };
}

After some text crunching we get these numbers!

DRUM ROLL 🥁 ...

AMD Ryzen 7 3700X 3.60GHz, 1 CPU, 16 logical and 8 physical cores
.NET SDK 10.0.101
  [Host]     : .NET 10.0.1 (10.0.1, 10.0.125.57005), X64 RyuJIT x86-64-v3
  DefaultJob : .NET 10.0.1 (10.0.1, 10.0.125.57005), X64 RyuJIT x86-64-v3

| Method         | Mean     | Error    | StdDev   | Gen0    | Gen1   | Allocated |
|--------------- |---------:|---------:|---------:|--------:|-------:|----------:|
| ParseShaderOld | 151.3 us | 1.490 us |  1.16 us | 22.2168 | 5.1270 | 183.17 KB |
| ParseShaderNew | 32.28 us | 0.295 us | 0.276 us |  1.6479 |        |  13.78 KB |

We run 5 times faster and allocate 20 times less memory than before. Objects allocated are not promotted to Gen1.

That's exciting news to me! We could theoritically parse 4 more shaders while in a single core without worrying too much about GC pauses. This will surely improve startup times for the Stride engine!

Conclusions 🔗

Let's check our goals again ...

✅ Fast
5x faster allows me to stamp that parser with ✨Blazingly fast🚀
✅ Low heap allocation
20x less allocation is going to help us a lot, especially during runtime compilation
✅ Easy to update/modify
Going the functional way has only made it easier to make changes. We also own all our parsing code, nothing is hidden behind API which is great!

I could leave with a very nonchalant "Code speaks for itself" but I have to convince you that writing a handmade parser for your programming language is almost always the best decision you could make, there are many ways to write one but recursive descent parsers can be a very helpful start until you have a very specific need for your language.

I'm excited to show more of SDSL's new compiler progress and writing that parser was a huge endeavor, espcially going through two different implementations before settling to what it is now.

In the next blog post we'll see how bridging the parser with the SPIR-V assembler was done, hopefully with an example of a working version of the compiler.

Thanks for reading!

Announcing Stride 4.3

Fri, 14 Nov 2025 00:00:00 +0000

Stride 4.3 brings .NET 10 and C# 14, Bepu Physics, Vulkan compute shaders, custom assets, cross-platform build strides, mesh buffer helpers, Rider/VSCode support, and performance and stability fixes.

Table of Contents:

Download and Upgrade 🔗

You can download the Stride 4.3 Installer today. Release notes are available here.

Make sure you read the guide to update Stride and projects properly.

What's new in this release 🔗

Stride 4.3 includes numerous enhancements and improvements. Here’s what to expect:

.NET 10 Integration: Stride 4.3 is now fully aligned with .NET 10, harnessing its performance improvements and efficiency gains for game development. This means faster execution times, reduced memory footprint, and access to the latest C# features, making your development smoother and more efficient. Learn more
C# 14 Features: With C# 14, Stride users can write cleaner, more concise code thanks to new language features. These improvements reduce boilerplate and enhance readability. Introducing C# 14

What has changed since Stride 4.2 🔗

Bepu physics integration 🔗

Adding support for Bepu Physics, a ridiculously fast physics engine written entirely in C#.

Having both a game and physics engine in the same ecosystem reduces the cost of maintaining and improving it, the overhead that we may incur when communicating between the two APIs, and the barrier to entry for contributors.

Bullet is still the default physics engine, and we welcome any contribution towards it, but our efforts will be focused on Bepu from now.

The integration is effectively done, with Bepu's feature set now being slightly ahead of Bullet's. Have a look at this page if you want to migrate to Bepu.

Vulkan compute shader support 🔗

The Vulkan graphics backend has been modified to support compute shaders, and the shader compiler has also been modified to support compute shader generation for GLSL.

User-defined Assets 🔗

Introducing Custom Assets, a way to define and store data which can be referenced across multiple components, scenes and through other assets.

The asset compiler also gives you the ability to build more complex systems like custom file importers.

Ongoing efforts to build projects from Linux and Apple desktops 🔗

Stride can build games on Windows targeting the different devices we support, but building directly on those platforms was not supported until now.

We've introduced a couple of changes to improve on that front:

Replacing our custom C++/CLI FBX importer with Assimp
Fixing the asset compiler to run on all desktop OSes
Many build-system refactors to move toward fully cross-platform development
Building VHACD for Linux
Adjust FreeImage and DirectXTex for all platforms

Some work is still required on this front, but simpler projects can now be built on those platforms.

Efficient API to manipulate meshes 🔗

Vertex buffers do not have a standardized layout, each mesh may have its own specific layout and data type it uses for its vertices. Some have blend weights, or tangents, while others only have positions - they may also use different data types, for example Half4 positions, 4byte color ...

We added in two helpers in VertexBufferHelper and IndexBufferHelper to provide a standardized way to read and write to those buffers.

Open project with Rider and VSCode from the GameStudio 🔗

While any IDE can open and build Stride projects, the editor button to open said project only had special handling for Visual Studio. Jklawreszuk added support for Rider and VSCode.

Interface processor 🔗

Stride has a component processors, a user-defined class which can collect and process all components of a given type in the running game. It is also known as the System part of the ECS acronym.

The new flexible processing system provides more type safety, and the ability to process components by their interfaces. You could, for example, implement a custom update callback any component could receive through this API.

And more minor changes 🔗

Fixes 🔗

Although there have been many fixes, we'd like to point some of them out:

Major performance improvements, particularly for graphics and UI
Multiple fixes improving Vulkan, OpenGL, games under Linux and OpenXR stability
And fixes for edge cases when reloading assemblies in the game studio

Also good to know 🔗

We are already hard at work on a bunch of ongoing projects for version 4.4 and beyond:

Continuing work to allow for building games from other platforms
Converting our Windows-only GameStudio to cross-platform through Avalonia
We welcome anyone willing to contribute to this project over Here - just have to make sure to add a comment to one of the unassigned issues you want to work on
Improvements to shader compilation, reducing in-game hangs while building shader permutations. Here
More work on D3d12 and Vulkan as we slowly transition away from D3d11

Funding and Resource Allocation 🔗

Call for Skilled Developers 🔗

We are actively seeking skilled developers with experience in C#, the .NET ecosystem, mobile, XR, rendering, and game development. If you have these skills or know someone who does, we encourage you to get involved. There are opportunities to contribute to critical areas of Stride's development, supported by available funds.

Join Us on This Journey 🔗

We’re always excited to welcome new contributors to the Stride family. Whether it’s through code contributions, spreading the word, or donations, every bit helps us grow stronger. If you’ve got skills in .NET, Android, and iOS development, there’s a special place for you here. Support us on OpenCollective.

Links 🔗

GitHub: https://github.com/stride3d/stride
Website: https://stride3d.net/
Documentation: https://doc.stride3d.net/latest/en/manual/
Twitter: https://twitter.com/stridedotnet
YouTube: https://www.youtube.com/@Stride3D
Stride Community Toolkit: https://stride3d.github.io/stride-community-toolkit/index.html

Acknowledgements 🔗

We extend our heartfelt gratitude for all the hard work and donations we have received. Your generous contributions significantly aid in the continuous development and enhancement of the Stride community and projects. Thank you for your support and belief in our collective efforts.

In particular, we want to thank these donors:

Long-time Stride supporters 🔗

VVVV🥇

Gold Striders 🔗

This article was co-authored by Eideren.

A Look Inside Distant Worlds 2: Developing with the Stride Engine

Wed, 09 Apr 2025 00:00:00 +0000

Distant Worlds 2, the sequel to the acclaimed 4X strategy game Distant Worlds: Universe, was developed by Code Force and published by Slitherine. In this blog post, the developers answer key questions from the Stride community, offering insights into their experience using the Stride engine to bring their ambitious galaxy-spanning strategy game to life.

Table of Contents:

Intro 🔗

Our Stride community has been eager to learn more about the development of Distant Worlds 2. We reached out to the developers at Code Force to hear about their experience using the Stride engine to create this ambitious 4X strategy game.

We're incredibly grateful to the team for their generosity with both time and expertise. The depth and breadth of information they've shared, spanning everything from engine selection to performance optimization is impressive. Their willingness to provide such comprehensive insights is truly appreciated by the Stride community.

Some questions were answered by the team collectively, while others were addressed individually by team members: Elliot, the Lead Developer; Kevin, the Lead Artist; and Alex, the 3D Artist.

Buckle up and enjoy the ride, you're about to dive into a rich technical deep-dive and maybe learn something new along the way!

Engine and General Development 🔗

Why did you choose Xenko/Stride over other alternatives for Distant Worlds 2? 🔗

Our requirements for the DW2 game engine were:

Full support for all features of C#/.NET
High quality rendering, also allowing for the use of custom shaders
Good asset pipeline support

Stride handles all of these areas very well.

One of Stride’s major strengths is how it integrates with .NET: it is nearly completely written in C# itself, and it stays up-to-date with .NET version releases.

You are not locked into any specific approach to writing code. You have full access to all parts of the .NET environment. You don’t have to use scripting tied to a specific custom version of .NET.

Instead you can simply make your own implementation of the Game class, overriding the Update and Draw methods from the base class. That’s the basic approach we took with DW2. We use Stride in two main ways for DW2:

Rendering engine, using PBR models and materials with the scene/entity system
Content/Asset bundling, using the Stride Game Studio to package assets for loading into the game

Beyond that we write all of our code as a standard .NET application with classes, structs, etc. We don’t use any scripts.

Additionally, because Stride is open-source, if you find an issue you can always fix it yourself. You can also figure out how things work by examining the source itself. Then, if required, modify things to work the way you want.

Stride also has great rendering with PBR materials. And it has a very nice shader model that allows you to write your own custom shaders.

How much modification was needed to adapt the engine for your needs? How difficult was this process for the developers involved? 🔗

We started experimenting with Stride back when it was called Paradox, around version 1.2. So there wasn’t much documentation back then. We had to just figure things out by examining the source. Documentation improved as the engine progressed through the 1.x versions, and became Xenko.

A key requirement for DW2 was to mix entity-level rendering for units (ships and bases) with custom shaders for the larger galactic environment.

Most of the DW2 environment uses custom procedural shaders to render things like planet surfaces, stars, nebulae and other items (see this article for details).

However for the unit-level rendering we wanted to use Stride’s PBR materials and the scene/entity system. The artists would build space ship models and materials which we would load into a scene.

We achieved this by separating out the custom shader rendering into pre- and post-scene rendering in the Game.Draw cycle. So we built our own rendering classes that inherited from SceneRendererBase and inserted them into the GraphicsCompositor.

This also allowed us to have rendering layers that excluded the post-processing effects (bloom, lens flare, etc). This was especially useful for the user interface.

There may be a better way to do all of this in Stride now, but that’s what worked for us.

We noticed references to both Xenko and Stride in the build. Are there specific reasons older files were retained during the transition? 🔗

Any remaining Xenko files are just a holdover from our development history. We should probably remove them 🙂.

How frequently do you update the engine for your project? 🔗

Initially we had some small custom changes to better support our pre- and post-scene rendering mentioned above.

When we went more heavily multi-threaded we made some updates in some areas of Stride to better handle this.

And whenever we want to move forward in .NET versions we have updated Stride to whatever version we were moving into (5, 6, 7, 8).

And as Stride itself progressed we have periodically pulled in some of those changes.
Stride’s approach to .NET has been a big plus. It’s quite amazing that we could move Stride to a new version of .NET ourselves.

Did you create issues on the Stride GitHub repository? 🔗

We have not done that. Much of our changes are very specific to Distant Worlds.

What were some notable technical hurdles in using Stride, and how did you overcome them? 🔗

Early on, the lack of documentation made progress slower. But this has improved a lot over time.

We worked quite a bit on getting Stride to handle heavily multi-threaded scenarios. We had to make some areas more robust and defensive, particularly around null-checking and iteration of lists.

User Interface 🔗

Which library did you use for UI elements in Distant Worlds 2? 🔗

What led you to choose the current UI solution over others? 🔗

Were there any features you found lacking in Stride for UI, and how did you address these gaps? 🔗

We initially tried out the built-in user interface elements of Xenko. But for various reasons we decided to instead build our own user interface system.

So for UI rendering we took the SpriteBatch class and built some basic controls: buttons, panels, textboxes, etc.

The input side is just reading keypresses and mouse actions from the InputManager class.

From there we added more functionality as we needed it.

Near the start of development it’s often hard to know exactly what you’ll need in the user interface. You have to tweak and extend things as you go. So it is important to have deep control over all parts of the user interface. For us that meant writing our own UI system.

I think this happens quite frequently in games, because they often have very unique and specific UI requirements. So it’s important to have full control over how the UI works, which might mean writing it yourself.

For DW2 we also had a requirement that the user interface be completely scalable. This was a major weakness of DW1, where the UI was fixed-size. So in DW1, as screen resolution increased, all the text became smaller and harder to read.

With DW2, building our own UI system allowed us to bake scaling into everything. So you can change UI scale in DW2 from the game settings and everything just automatically resizes and repositions, regardless of resolution.

How is the research screen (e.g., item order, dependencies) created? Are these elements procedurally generated, or are they manually crafted? 🔗

How did you create the research graph, including arrows and other visual elements? 🔗

The Research screen is custom-rendered. Most of the data in DW2 is heavily moddable, and the tech trees are a big part of this. So the rendering for research projects has to be data-driven.

We use some SpriteBatch helper classes to draw the lines and arrows between projects. The projects themselves use some basic textures for the main body.

Artists and Asset Creation 🔗

How did the artists find the asset creation process when working with Stride? 🔗

Elliot: DW2 uses lots of ship and base models with all of their associated textures. We utilize all the standard material features like Diffuse maps, Normal maps, Metalness maps, Emissive maps, Ambient Occlusion and Gloss maps.

So the artists use Stride Game Studio to simply bundle all the assets together before handing them over to the development side to use in-game.

Kevin: It works well and is easy and intuitive. I like that there's multiple ways to do the same thing (i.e. clicking and dragging or using the 'click to add' interface for assigned textures for instance)

Alex: The workflow is a lot like Unity or Unreal. It’s pretty simple for making PBR 3D models. The material creation is flexible and easy to pick up if you know Unity. It feels smooth and straightforward overall. I found it quick to get started with and the tools don’t get in your way.

What are their thoughts on the physically-based rendering (PBR) pipeline in Stride? 🔗

Elliot: It’s very nice and produces great looking scenes. It’s pretty easy to understand.

Kevin: Works great and again is easy to use. The only issue is there is a marked difference between my editing software (Substance Painter), Stride's asset preview, and in game. Though at least those last 2 items aren't the engine's fault.

Alex: I’d say the artists thought it was pretty good. It works well and everything looks just fine in the game. There’s not much to add really. No problems to complain about that we know of. It just does the job nicely!

Did you encounter any challenges or limitations with shaders, and how did you address them? 🔗

Elliot: Initially we had to figure out how we were going to mix our custom procedural environment shaders with the Stride PBR material rendering. But once we had settled on our approach to this, most things were pretty smooth.

Early on, it took a bit of digging into the Stride code to figure out what we needed to do with PipelineStates, EffectInstances and other items. We ended up much as described in the Stride documentation here: Low-level API.

Kevin: Plenty. Some of it was learning a new engine and some of it was a lack of certain features. A huge bonus for artists would be to be able to have a node-based editor for shader effects. Right now (at least on our current version) things like animated UVs has to be done manually.

Alex: When it comes to challenges or limitations with shaders in Stride, I’d say we didn’t run into much. The default shaders were solid and covered all our project needs so far. We haven’t tried adding custom ones yet though. I did give it a shot once using an example shader but it didn’t go well. The editor crashed and I was left scratching my head. I might revisit it later and hope for better luck. From that one try, it felt like adding a custom shader would take way more effort than you’d expect. Maybe I missed something simple but I wish it was less frustrating to bring a custom one into the project.

Level Design and Prefabs 🔗

How was the level creation process using Stride for your team? 🔗

DW2 doesn’t use levels in the normal sense. The galaxy is an open-world and is entirely procedurally generated. So we manage view changes and the transition between locations and scenes in code, adding and removing items as needed.

Was the Prefab system easy to use for level designers, and did it meet your expectations? 🔗

We use Stride Prefabs mainly for particle effects. We instantiate particle effect Prefabs for various in-game effects, like weapons fire, hyperdrive effects, explosions, etc.

These work well, allowing our effects artist to create things as he likes them, then package them together as a Prefab in Game Studio.

In code we can then use these effects pretty easily, supplying their in-game world transform to scale and position them where they need to be.

Did the component system in Stride prove to be intuitive for designers? 🔗

DW2 is probably not a typical game, so we only use the scene/entity system inside the game code itself, dynamically creating and updating scenes as needed.

Stride Game Studio is really just an asset bundling tool for us.

DLC and Content Expansion 🔗

Could you briefly outline the steps involved in creating a DLC for Distant Worlds 2? 🔗

DW2 DLCs typically involve adding one or more new alien factions into the game.

Each faction has new game features unique to them. They likely also have their own unique government type, which also has new features. So there is a lot of code to support this.

From the art side each new faction involves around 25-30 new ship and base models, each with their own full set of materials and textures.

Ship models in DW2 are quite detailed, with individual meshes for various parts of the ship, e.g. engines, weapon mounts, hangar bays, sensor dishes, etc.

So the models are created as super-sets with all of the meshes that might be used. Then the player can design their own ships using the in-game ship editor. As they add or remove components to the ship, the game enables or disables appropriate meshes.

These models and textures are packaged together into faction-specific Stride bundle files inside Game Studio. We then load these bundles in-game for the new factions and can then show their ships and bases in scenes.

Additionally we also have animated characters for each new faction. These are implemented as 2D texture atlases that are animated using Spine. In-game we can play appropriate mood-based animations for the characters.

How do you detect whether a DLC is installed or not for a player? 🔗

Each distribution platform has their own mechanism for this. So whether it’s Steam, GOG or something else, we use their inbuilt features to check this. Then we can load the appropriate bundle files with all of the models and textures for that DLC.

Performance and Optimization 🔗

Source: Steam - Distant Worlds 2 - Screenshots by Shrikebe

The game achieves impressive performance, especially during large-scale fleet battles. How did you manage to optimize for several simultaneous battles, each with many ships and fighters? 🔗

Performance optimization has been an ongoing consideration throughout development. As we add new game features we periodically need to profile and improve performance in slow areas.

Large galaxies can have a huge number of individual units and factions, all of which can have extensive logic that needs processing at some minimum level of frequency. We have test games that have more than 250,000 ships, fighters and bases. Individual locations/scenes might have over 3000 units in a single battle.

Most of DWs performance demands are on the logic side, i.e. we are CPU-bound. So there have been 3 basic approaches we have used to improve logic performance:

Improve specific algorithms, i.e. find faster ways of calculating something
Cache the outputs of expensive operations as much as possible and only update them periodically
Use multi-threading to parallelize processing across all CPU cores. This requires very good locking, especially when iterating lists. It also requires a lot of defensive coding to check for null references which would never occur in single-threaded situations.

Rendering in DW2 does not generally encounter performance issues in the same way as the game logic does. However there are some optimizations:

In large scenes we may exclude drawing for small meshes in models as the view zooms out, thus reducing the total number of draw calls
We use instancing in a number of areas to handle elements with a high draw count, for example the stars in the galaxy view are drawn using instancing

Early on we made the decision to optimize the way weapons are rendered to minimize draw calls. So all weapon blasts in a scene are drawn in a single draw call using a custom shader that handles all of the different textures and animations for all the various weapon types.

The rendering is wrapped into a single vertex buffer with camera-facing billboards for each weapon blast. The shader determines what to draw using a number of texture arrays that allow various rendering features, e.g. flipbook animations, scrolling beams, etc.

This places some definite constraints on what we can render. We can’t just go crazy with expensive particle effects. But it has huge benefits for performance.

Weapon trails are handled in a similar way, where a single vertex buffer contains all of the trail particles, and is rendered with a single draw call per frame.

AI and Game Systems 🔗

Source: Steam - Distant Worlds 2 - Screenshots by VoiD

Did you require any kind of editor extensions? How did you implement them? 🔗

Our use of the Stride Game Studio is really just as a tool to bundle assets into the game. So we didn’t need this.

Which serialization method did you use for saving games? Was it a database, YAML, or a mix? 🔗

The static source data for the game entities is mostly just XML files. Things like planet and star definitions, ship components, alien races, government types, research projects, etc.

We have some internal tools for editing these files. And we also have auto-generated schema for most of these data types.

For saving and loading games we use low-level binary serialization. So .NET BinaryReader and BinaryWriter with streams. This requires hand-coding all of the serialization, but has big payoffs in performance.

This also allows easier version management as you add new data to the game. You can have conditional loading of new values based on game version.

What AI libraries did you use? What techniques were used for AI, such as for fleet formations, battle decisions, or engage/retreat behaviors? How was diplomacy handled? 🔗

All game logic is custom written for each system. We don’t have any 3rd-party AI libraries.

Logic happens at 3 main levels:

galaxy-wide logic that affects everyone
faction-wide logic where each faction makes high-level plans to explore, expand and conquer
unit-level logic where each ship decides what mission to select to advance their factions goals

We try to make each entity have sufficient logic to carry out it’s normal tasks and to also be able to respond to unexpected events in a reasonably intelligent manner. So the units can be given missions from a faction-level AI or manually by the player, but they can also assign themselves missions that make sense for the current situation.

This kind of logic forms the bulk of the code in the game. So this logic really IS Distant Worlds.

In addition we have an extensive advisor system that can provide suggestions on what to do next. These advisors are deeply integrated with the faction- and unit-level logic. When you switch an area of the game to ‘advisor-mode’ then you will get periodic suggestions in that area that you can either approve or reject.

So for Colonization you will get suggestions about which planets to colonize. Approving the advisor suggestion will build a new colony ship and send it off to claim the new planet as a colony for your faction.

If you instead had the Colonization area fully-automated (no advisor suggestions) then the game logic would simply carry out whatever it thought was best, automatically establishing new colonies.

You can fine-tune how each area of game logic works, even when it is fully-automated. These policy settings tweak precisely how the automated decisions are made, allowing you better control over things. This ‘intelligent automation’ is a key feature of Distant Worlds that allows it to scale very large while still being manageable for the player.

The game logic (including the advisors) is constantly being developed and improved. With the very open game style of Distant Worlds, there are endless unexpected situations that can prove challenging for the game logic to handle. So we are always extending the game logic to handle new things.

Future Use and Recommendations 🔗

What types of projects do you think the Stride engine is perfectly suited for? 🔗

For us, the key strength of Stride is it’s deep integration with the .NET ecosystem, providing easy access to all of its tools and features. This has meant that we can build a standard .NET executable that simply uses Stride for rendering. That flexibility is great.

Are you planning to use Stride in the future, beyond maintaining Distant Worlds 2? 🔗

We currently have a development roadmap laid out for the next 12-18 months, with no end in sight after that. So Distant Worlds 2 will be keeping us busy for the foreseeable future 🙂. Stride will continue to be a core part of that work.

How can the Stride engine be improved to help the modding community? 🔗

Each game no doubt has its own unique requirements. But Distant Worlds modders mostly encounter Stride when packaging up assets to use in the game. This typically means creating a new Stride project that just contains static art assets (textures, models, etc). The goal is to generate a Stride bundle file that can then be loaded in the game.

So any improvements to bundle creation and updating are always welcome.

One small pain-point that still exists is renaming the bundle files.

In Stride Game Studio, the normal build process generates the bundle with the name “default.bundle”. This is ok if you put all of your assets in a single project. But when your game gets bigger, that is not viable.

In Distant Worlds we load many different bundles. The models for each faction are contained in their own bundle. We currently have 14 factions, so that means 14 different bundles. We also have other bundles for other parts of the game. Each of these bundles must have different names.

There is currently no way to change the bundle name directly from within Game Studio (that I know of). Instead you have to hand-edit the YAML in the *.sdpkg files, changing the bundle name and adding the appropriate Selectors.

That may sound fairly simple, but it can still be an extra hurdle for modders. Having bundle-renaming built into the Game Studio would make this much easier.

Conclusion 🔗

The journey through Distant Worlds 2's development offers valuable insights into what's possible with the Stride engine. Code Force's experience demonstrates how Stride's deep integration with .NET creates a flexible foundation for ambitious projects, allowing developers to focus on crafting unique gameplay experiences rather than wrestling with engine limitations.

What stands out most is how the team leveraged Stride's strengths—particularly its rendering capabilities and open-source nature—while developing custom solutions where needed. Their approach to performance optimization, particularly for large-scale battles involving thousands of units, provides practical lessons for developers working on similarly complex simulations.

We'd like to extend our sincere thanks to the Code Force team for sharing their expertise and experiences so candidly. Their willingness to detail both successes and challenges offers invaluable knowledge to the Stride community and game developers at large.

For those inspired by what you've seen here, we encourage you to explore Stride for your own projects. Whether you're developing strategy games like Distant Worlds 2 or something entirely different, Stride's combination of powerful rendering, C# integration, and flexible architecture provides a solid foundation for bringing your vision to life.

If you're already using Stride for your projects, we'd love to hear about your experiences in our GitHub discussion or on our Discord server. Your stories and insights help strengthen our growing community of developers.

Links 🔗

Steam: Distant Worlds 2 on Steam
DW2 Forum: Matrix Games Forum
DW2 Discord: Distant Worlds 2 Discord
YouTube: Slitherine Games on YouTube
GitHub Stride DW2 Discussion: GitHub Discussions
Kevin: You can find him on our Stride Discord server as @KevinC
Elliot: You can find him on DW2 Discord server as @elliot_333

Investigating SPIR-V for the shader system - Part 2

Wed, 20 Nov 2024 00:00:00 +0000

In this second part we're going to dive deeper in how the current SDSL compiler works and how we are improving on it for the SPIR-V compiler. This will be a sort of personal log book of my research on the subject.

If you're interested in the other parts of this blog series :

Part 1 An introduction to the project
Part 3 we write a new parser for SDSL

Table of Contents:

In the last blog post, we briefly saw why SPIR-V was an interesting shader format for our new shader compiler. After a year of research on this subject I'm coming back with ideas and implementations!

Preface 🔗

Rewriting the shader system is a complicated task in itself. As you may already know, Stride was initially a commercial product that was open-sourced not long ago, and some of the original devs left. This has led to a difficulty gathering information on the inner working of the engine.

Fortunately we still have some of the original team members helping and answering questions, and the source code is well written and easy to understand, this has helped a lot of contributors to be able to fix issues quite fast.

As for me, I started this project with no prior knowledge of how compilers worked and a very faint idea of how shaders works. I've learned some things and am trying my best, so if you have any ideas, improvements and criticism, I'll be happy to discuss it on our Discord server or in a GitHub discussion. 😊

The code related should be available in the SDSL repository of Stride. Hopefully it'll be merged in the Stride repository itself in the future!

Also credit to Felicia Salomone/@phaelicis for the art!

How it works currently 🔗

There are two components to SDSL :

The effect system
The shader mixin system

The effect system sits at a higher level than the shader mixins. It drives the creation of shader permutations through mixin operations of shader mixins.

A shader mixin is a building block for shaders in Stride, they are mixed and merged together to produce one final shader that will be used in rendering pipelines. Mixins is another way to reuse code without going through an inheritance hierarchy, there are many ways to go about it and SDSL has very specific kind of rules.

A quick example for this :

// Let's define two shader mixins with different fields and simple method
shader MixinA
{
    int a;
    void Foo()
    {
        int bar = a + 3;
    }
}
shader MixinB
{
    float b;
    void Foo()
    {
        float bar2 = b * 0.5f;
    }
}
// And one that is going to inherit our two first shaders
shader MixinC : MixinA, MixinB
{
    float c;
}

The inheritance is going to reuse the code present in the mixins and mix them together using a set of rules.

In this case the MixinC will internally look like :

shader MixinC : MixinA, MixinB
{
    // MixinC fields from MixinA and MixinB are copied as is
    int a;
    float b;
    float c;
  
    // Methods are merged together, statements appear in order of apparition of mixins.
    void Foo()
    {
        int bar = a + 3;
        float bar2 = b * 0.5f;
    }
}

This system makes it surprisingly easy to add shaders to material parts, say you want to add a shader to compute the emissive component of a material, just create a CustomAwesomeEmissiveMixin, inherit Texturing, ComputeColor, implement the float4 ComputeColor() method, ✨woopdeedoo✨ Stride will automatically generate a new permutation of our material shader by adding in the emissive mixin!

The way it's implemented comes from a very simple idea :

Generate syntax trees representing the SDSL code
Mix syntax trees together
Convert tree into HLSL code
If GLSL is needed, convert HLSL to GLSL

But this has some issues regarding performance :

Mixing tree structures together to generate new permutations involves a lot of deep cloning/defensive copies.
Extracting information from text is slower than extracting it from compact binary data
The garbage collector is going to be stressed and have some stutters due to allocations needed by cloning/defensive copies and parsing data.

It's important to note that these issues are only about shader permutation generation so far.

The idea for SPIR-V 🔗

Dealing with tree structure is very rarely the fastest option, especially when using programming languages with managed memory. That's why we want to rewrite Stride's shader system, remove the need to process trees and instead focus on dealing with buffers since computers are faster at processing them.

What is SPIR-V? How could it help? 🤔

Let's check the official specification as of today, to understand what it is :

SPIR-V is a simple binary intermediate language for graphical shaders and compute kernels. A SPIR-V module contains multiple entry points with potentially shared functions in the entry point’s call trees. Each function contains a control-flow graph (CFG) of basic blocks, with optional instructions to express structured control flow. Load/store instructions are used to access declared variables, which includes all input/output (IO). Intermediate results bypassing load/store use static single-assignment (SSA) representation. Data objects are represented logically, with hierarchical type information: There is no flattening of aggregates or assignment to physical register banks, etc. Selectable addressing models establish whether general pointer operations may be used, or if memory access is purely logical.

Okay great, what about the goals for it :

SPIR-V has the following goals:

Provide a simple binary intermediate language for all functionality appearing in Khronos shaders/kernels.

Have a concise, transparent, self-contained specification (sections Specification and Binary Form).

Map easily to other intermediate languages.

Be the form passed by a client API into a driver to set shaders/kernels.

Support multiple execution environments, specified by client APIs.

Can be targeted by new front ends for novel high-level languages.

Allow the first steps of compilation and reflection to be done offline.

Be low-level enough to require a reverse-engineering step to reconstruct source code.

Improve portability by enabling shared tools to generate or operate on it.

Reduce compile time during application run time. (Eliminating most of the compile time during application run time is not a goal of this intermediate language. Target-specific register allocation and scheduling are still expected to take significant time.)

Allow some optimizations to be done offline.

WAIT! But, what if... we could extend the spec...

SPIR-V can be extended by multiple vendors or parties simultaneously:

Using the OpExtension instruction to add semantics, which are described in an extension specification.

Reserving (registering) ranges of the token values, as described further below.

Aided by instruction skipping, also further described below.

WOW! Now we're cooking! 🍽️

Here's the main idea :

We extend the SPIR-V specification with our own instruction set, telling Stride how to mix SPIR-V files together
We produce partial SPIR-V bytecode for those mixins, since mixins only contain partial code
We mix-in together those partial SPIR-V files at runtime, or offline

Using SPIR-V is not going to be any faster than using GLSL or HLSL, those languages already have very performant compilers, but for SDSL, it would be a game changer. The tree structure manipulation we have is suboptimal and .NET is faster at manipulating buffers anyway, but using SPIR-V would make sure we process only binary buffers. Additionally, it allow us to potentially make all shader front-end processing offline, we would effectively skip the whole front-end written in C# at runtime, huge win for us. Now we just need an...

Implementation 🔗

The easy way 🔗

The first instinct I had was to lookup for some libraries to generate SPIR-V bytecode with some constraints :

It should give us the ability to extend SPIR-V to support our mixin system
It should be easy to integrate in the engine and easy to package with games, the new shader compiler should not add more complexity to the engine
The libraries should be a native, with which we can easily generate bindings, or written in C#
If written in C# it should be AOT compatible, for potential future console support.
It should also run fast, or use the recommended practices for high performance

The first solution I've considered was LLVM, there was an ongoing work to add SPIR-V generation, this seemed like a neat idea but was nowhere near read and not sure if LLVM is fast enough to be used at runtime without creating stutters.

Shaderc and SPIR-V Tools have some SPIR-V generation capabilities to some degrees but from C# it would be hard to extend the SPIR-V specification. It has great support nonetheless, and our friends over at Silk.NET have some bindings for these tools.

Another one was the Nintendo Switch emulator Ryujinx, written in C#, it can generate SPIR-V on the fly to translate/compile the console's shaders. They have generated C# code based on the SPIR-V headers and specification and are using it to assemble some SPIR-V modules.

I decided to start from this Ryujinx code and made a little proof of concept by writing a little tool that takes the output of Stride's parser and convert it into shader modules. It only supported a very tiny subset of SDSL but it was enough to prove the compiler can be made, and to remind me that I do not know SDSL nor SPIR-V that well, and the Ryujinx code was not exactly suited for Stride. But then, the most intrusive thought a dev can have just crept in my mind...

"I should rewrite it from scratch..." 🔗

And make sure it fits our needs, the constraints i've listed in the previous section.

I decided to follow some core tenets and make sure I don't over-engineer anything for the sake of winning a few microseconds. First, as we're going to read, write and copy a lot, data should then be stored in a compact way using buffers and value types. This would improve enumeration of instructions and possibly garbage collection. We are also going to deal with a lot of small buffers, so pooling those buffers is going to be important to avoid stressing the garbage collector. Finally we should make sure SPIR-V data is arranged in ways that would benefit the compiler's performance.

But most importantly, keep it as simple as possible.

Buffers and instructions 🔗

According to the specification, instructions are made out of words/integers, they have a variable size and the size of the instruction is written in the high 16 bits of the first word.

Instructions would be represented as slices of this buffer and to access those instructions we would need to iterate through this buffer.

IT'S CODING TIME!

// A RefInstruction will hold a Span and some cool methods and tools to extract information from this instruction. 
// We could also create an Instruction struct containing a Memory<int> and doing the same...
public ref struct RefInstruction(Span<int> words)
{
    public Span<int> Words { get; } = words;
    // ...
}

// A buffer class to represent our SPIR-V buffer, disposable because we're using MemoryOwner from the high performance community toolkit
public class SpirvBuffer : IDisposable
{
    // This will represent words and we'll extract instructions from it by taking Span<int> slices
    public MemoryOwner<int> Words { get; }
  
    public Enumerator GetEnumerator() => new(this);

    // An enumerator for our instructions
    public ref struct Enumerator(SpirvBuffer buffer)
    {
        int position = 0;

        public RefInstruction Current => new(buffer.Words.Span.Slice(position, buffer.Words.Span[position] >> 16));

        public bool MoveNext()
        {
            // A simple advance, we read the size in the high bits, and just skip words based on this size.
            position += buffer.Words.Span[position] >> 16;
            return position < buffer.Words.Length;
        }
    }

    public void Dispose() => Words.Dispose();
}

Instructions can have a variable number of operands and each operands can be one or multiple words. The simplest way to extract operand information from this slice is to generate C# source code with information on how to parse each instructions based on its type and size.

And with just that, we can parse SPIR-V and even write our own SPIR-V disassembly tool!

Generation 🔗

Now that we can load SPIR-V and parse it, the next step is to be able to write instructions. Fortunately for us, the SPIR-V headers repository provide a C# file containing all the enums and constants needed for instructions operands and some JSON files describing instructions and their operands as well as if the operands are optional or have to be passed as an array of values. With a few more, we can generate methods to add or insert instruction in a buffer!

Here's an excerpt from the current unified core grammar of SPIR-V and its corresponding generated C# code :

{
      "opname" : "OpFAdd",
      "class"  : "Arithmetic",
      "opcode" : 129,
      "operands" : [
        { "kind" : "IdResultType" },
        { "kind" : "IdResult" },
        { "kind" : "IdRef",        "name" : "'Operand 1'" },
        { "kind" : "IdRef",        "name" : "'Operand 2'" }
      ],
      "version": "1.0"
}

And here's a function we can generate from it :

public static Instruction AddOpFAdd(this SpirvBuffer buffer, IdResultType resultType, IdRef operand1, IdRef operand2)
{
    // Extend the buffer and put the data needed
    int size = 1 + ComputeSize(resultType, operand1, operand2)
    buffer.Add(size << 16 | (int)Op.OpFAdd);
    buffer.Add(resultType);
    buffer.Add(operand1);
    buffer.Add(operand2);
}

After going through the core and the glsl grammar, we end up with a library that can both parse and assembler SPIR-V.

Extending SPIR-V 🔗

This one was the easiest step as we've already made a source generator that generates the necessary C# code from json files, we just need an additional JSON grammar file made for SDSL and the generator will generate code to add custom instructions, there's really nothing else to it!

What was left is creating a little tool that can read those extensions and pre-process many SPIR-V together to generate a valid SPIR-V module that can be consumed by Vulkan, OpenGL, WGPU and soon DirectX 12. I have made a prototype that works quite well but can be improved in the future, it's not a complicated task, it just takes time and efforts.

Finally we can make sure we can generate SPIR-V mixins from the AST generated by the current Stride shader system. This should be easy, right? RIGHT?

The Irony 🔗

The current shader parser was made for the specific use case of mixin abstract trees. Modifying the code would be a huge endeavor as I would have to dive into what's existing and try my best to understand what i can change without breaking anything, worse than that, the parser was written with Irony, a very good C# library to help anyone parse things in an LALR fashion, but with a lacking documentation and, in my personal opinion, has an "easy to write, hard to read" kind of API.

CppNet is another library that Stride uses to preprocess SDSL code. It works like a C/C++ preprocessor, depending values given to the compiler, it will enable or disable some parts of the code. It's quite useful when you need target specific code, but it defeats the purpose of having a whole mixin system and would invalidate already compiled SPIR-V mixins.

While it might be smarter and easier to continue using those libraries and just patch our new shiny SPIR-V assembler, rewriting the front-end seems like a necessary step if we want to embrace the newer .NET APIs for better performance. We just need to know how much performance we could squeeze from it... 🤔

But that's for another blog post, so much happened since last year and this blog post is getting long. 😀

Conclusions 🔗

Writing this SPIR-V library was very fun, I've learned a lot about SPIR-V and some of the possible use cases for it in the context of Stride. As you might have imagined, this was the easy part of this shader system rewrite. In the next installment we'll see the little adventure I went through to make the most of our shader front-end!

Thank you for reading!

Open Worlds: An Introduction to Free and Open-Source Game Engines

Thu, 14 Mar 2024 00:00:00 +0000

With so many free and open-source game engines out there, where do you even start?

Table of Contents:

Introduction 🔗

The party is over. The era of companies offering their products and services at unsustainably low prices is coming to a close. Growing pressure from shareholders to transition from maximizing growth to maximizing revenue has pushed many commercial software companies to reevaluate their business models. In other words, introduce price increases and new fees. Those dependent on their software must now decide between accepting the increased financial burden or switching to alternatives. The video game industry is no exception to this changing tide as major game engine developers explore new ways to monetize their users. It raises a lot of questions for the community. How will we, as developers, manage these rising costs? Just as importantly, considering the immense impact licensing changes can have on developers, should Epic and Unity continue having a disproportionate influence on the game development landscape? While there is never a good time to wrestle with these questions, the rise of free and open-source game engines over the past decade gives independent game developers an opportunity to evaluate where free and open-source software can have a role in their next project.

Before we dive in 🔗

I want to make this clear from the start: I will not be doing a head-to-head comparison of free and open-source game engines. The summaries of each engine discussed will not be exhaustive nor specifically highlight exclusive features. This is a celebration of the hard work of the game development community. I want to use this as a platform to get you excited about free and open-source game development and consider options beyond proprietary engines like Unity, Unreal, and GameMaker.

If I tried to cover every feature of every modern free and open-source engine, this wouldn’t be a single article but an entire book series. For that reason, I identified notable features and characteristics of some handpicked engines I thought would be worth sharing. While reading this, keep in mind that no engine is one-size-fits-all, and, as I’ll explain later, picking an engine is about choosing the right tool for you. With that out of the way, let’s start!

What is FOSS and why should I use a FOSS game engine? 🔗

As the name suggests, free and open-source software (FOSS) includes two notable characteristics: it is free (libre) and its source code is available. You can use free (or libre) software for any purpose at your sole discretion. You will most commonly hear something like: “free as in speech, not free as in beer.” It may be available at no cost, but even more importantly, the user has complete control over the software. The open-source aspect of FOSS describes how everyone has access to the code that makes up the software.

Using a FOSS game engine provides several advantages. First, no licensing fees. While contributors always appreciate donations, none of the notable FOSS game engines expect or require upfront payment, subscriptions, or ongoing royalties. FOSS engines also provide independence from a single organization. If changes to a FOSS engine’s terms upset the community, the engine’s license allows developers to stick to the version with the most favorable terms and even fork off the project if they choose.

The community guides the development and growth of their FOSS game engine of choice. Many FOSS game engines have active and passionate communities that share their knowledge, advocate for their engine, and help newcomers. These vibrant and dedicated communities serve as a potent learning resource when working solo or as a small team. Some community members even contribute to their engine, improving it for everyone.

FOSS game engines allow anyone to modify the engine to fit their needs. For example, if the engine lacks a specific feature, has a persistent bug, or needs quality-of-life improvements, anyone can update it as necessary. They can even take the additional step of contributing the changes to the project for everyone’s benefit. One of the greatest strengths of FOSS game engines lies in their communities and a willingness for everyone to work towards a collective good.

What FOSS game engines are available today? 🔗

Although FOSS game engines have existed for decades, the past several years have seen an explosion in the number of game engines available, as well as contributors, money, and resources dedicated to them. It would be impossible to cover all the FOSS game engines available now. In fact, if you have a passion for a particular language or framework, more likely than not, someone built a game engine with it.

This post will focus on some of the more notable modern FOSS game engines: Bevy, Godot, Open 3D Engine, and (of course) Stride. However, this is not an exhaustive list. As I mentioned before, there are more engines out there than I could ever cover in a single blog post. Many skilled and dedicated folks have put serious time and effort into making game engines and shared them with the world. I encourage you to use this post as a starting point and look at what each community offers.

Bevy 🔗

Written in Rust, Supported Languages: Rust
Platforms:
- Development (Code Only): Windows, Mac, Linux
- Build Targets: Windows, Mac, Linux, iOS, Android, Web

As the most popular Rust-based game engine, Bevy offers a rich code-only development environment (an editor is coming in the future) capable of running on all major operating systems (Windows, Mac, and Linux). At the heart of Bevy’s vision for game development lies the Entity Component System (ECS) paradigm. While there are other resources available that can explain the benefits of ECS better, in a nutshell, ECS breaks down the code into three core pillars: entities, components, and systems. Entities are composed of components that can interact with each other using systems. For example, the player character could be an entity with a health component that tracks the player character’s health bar. An enemy character could also use that health component for the same purpose. ECS encourages modularity and reusability by enabling developers to create components applicable to distinct entities. While other game engines can approximate a similar system, Bevy makes this part of its core design ethos.

As established with Bevy’s use of ECS, the engine’s developers care deeply about modularity. The engine’s plugin system accentuates their commitment to that principle in every part of Bevy. Developers can organize the game’s systems into discrete plugins. An example of this is organizing all the UI code into a UI plugin. From there, developers can slot the plugin into the game’s initialization step. The plugin system helps organize the code and encourages modularity by allowing developers to add or remove the plugin based on their needs. This paradigm even applies to the engine’s core features, as they are all organized into plugins. It becomes trivial to activate or deactivate any part of the engine—including rendering, audio playback, and event loops—as the developer sees fit.

Asset libraries provide a wealth of resources that empower developers to learn the tools quickly and get their game to a playable state. The community assembled a library of assets available on the official website for everyone to use and share. Bevy’s library includes tutorials, plugins, and templates that address subjects like physics, networking, and input management. Even entire games and applications are available in the asset library to either build on or use as a reference while learning the engine. Bevy’s structure encourages developers to use any of the resources from this library freely as part of the building blocks that will make up their game. In conjunction with Rust’s package manager, there is a strong emphasis on modularity at every level of the engine.

Godot 🔗

Written in C++, Supported Languages: GDScript, C#
Platforms:
- Development: Windows, Mac, Linux, Android (Experimental), Web
- Target: Windows, Mac, Linux, iOS, Android, Web

Godot has the largest and most active community among all the modern FOSS game engines available to date. As the drama around Unity has unfolded, you have likely heard mentions of Godot on more than a few occasions. It is not without merit, as Godot encourages developers to shape the engine around their needs. Coming in at only 40 MB, the engine includes a lightweight, multi-platform editor capable of running on any major operating system (Windows, Mac, and Linux). In fact, you can even use a web-based or Android version of the editor, albeit with some constraints. Godot can meet developers on whatever platform works best for them.

GDScript is Godot’s primary programming language. While the prospect of learning an engine-specific language may turn you off at first, don’t fret! It shares a lot of commonalities with Python and Godot provides detailed documentation on how to use the language. Assuming you already have some experience with object-oriented programming, it won’t take long to get going with GDScript. You can even use C# for scripting if that is more up your alley, as it’s the other language officially supported by Godot. That said, if you would still like to write some code in another language entirely, Godot provides the means to use alternative programming languages by way of GDExtension.

Theoretically, GDExtension supports any programming language that can interact with its C-based API. While Godot officially supports scripting in GDScript and C#, GDExtension allows the community to introduce new language bindings to Godot’s development ecosystem, including Rust, Go, Swift, and Haxe. Not all language bindings are feature-complete, but many are in active development. With that in mind, committing to one language for an entire project is unnecessary, as GDExtension languages can work alongside GDScript. This means developers can, for example, even use GDScript with other languages like Rust in the same project.

Work in an editor long enough and you will probably want to tinker with it. For those interested in creating utilities and tools, as is common practice when using Unity or Unreal Engine, Godot provides the option to customize the editor to your liking. You don’t need to write in C++ and re-compile Godot to create plugins. Because the editor runs on Godot itself, it is possible to tune or extend the editor with GDScript, Godot’s scripting language, by simply appending @tool to the top of the file. Writing a plugin becomes as easy as writing code for your game.

Open 3D Engine 🔗

Written in C++, Supported Languages: C++, Lua
Platforms:
- Development: Windows, Linux
- Target: Windows, Mac, Linux, iOS, Android

Open 3D Engine’s origins trace back to Amazon’s foray into game development. Amazon licensed Crytek’s CryEngine 3 and then used it as the foundation for their own game engine: Amazon Lumberyard. In the following years, Amazon offered Lumberyard for free to the community with specific terms requiring games built with Lumberyard use Amazon Web Services for their online features. By 2021, Amazon overhauled Lumberyard, rewrote 95% of the code, rebranded it as Open 3D Engine (O3DE), and placed it under the supervision of The Linux Foundation. Now, O3DE is available as a free and open-source engine under dual Apache and MIT Licenses for everyone, with no strings attached.

Only a few game engines offer visual scripting out of the box, and O3DE is one of them. O3DE supports both C++ and Lua for scripting, but for folks less inclined to write code, there is also Script Canvas, OD3E’s visual scripting environment. Visual scripting provides a way to write game logic without needing to write code in C++ or Lua. It presents programming concepts like functions, variables, and events as nodes that can be strung together in a graph. Script Canvas also allows developers to write custom nodes either in C++ or within Script Canvas itself to better fit their workflow. Fortunately, anything written using O3DE’s visual scripting system will not incur any serious performance hits, as the engine ultimately converts the graphs into Lua scripts.

O3DE modularizes its engine by breaking down major components into plugins called Gems. This is the paradigm through which O3DE manages all its features and plugins. For example, it is possible to swap out features like the physics engine, allowing developers to choose between PhysX 4, PhysX 5, or another solution entirely, custom or commercial. The modularity afforded by O3DE through Gems allows developers to add and remove components of the engine with relative ease–using as many or as few of the features as they want and in whatever combination best fits their needs.

With the Atom Renderer, the engine’s rendering system, O3DE strives to provide an advanced renderer that is also exceptionally customizable. The Render Pipeline Interface (RPI) and Rendering Hardware Interface (RHI) constitute the primary channels for working with Atom. The RPI provides the tools necessary for customizing the rendering pipeline and implementing higher-level graphical features, such as split screen or additional rendering passes. Meanwhile, the RHI abstracts access to the GPU’s functionality, allowing developers to write lower-level graphics logic without needing to target specific graphics APIs like DirectX or Vulkan. In short, the rendering stack provides incredible flexibility to developers.

Stride 🔗

Written in C#, Supported Languages: C#, F#, Visual Basic
Platforms:
- Development: Windows
- Target: Windows, Mac, Linux, iOS, Android

Stride began life as Xenko (and before that, Paradox): Silicon Studio’s premium game engine. After several years of providing Stride to the public through a subscription-based model, Silicon Studio released the engine’s source code and editor freely to the community under the MIT license. Among the higher profile FOSS game engines available, it is unique because Silicon Studio completely wrote it in C# from top to bottom. There is no delineation between the language used for the core engine and the language you would write with day-to-day while working on the game. It becomes much easier to override or change any inherent engine behavior when coding in the same language. No need to develop an interop system to interface with the engine’s core logic. With that said, the code-only version of Stride supports any language that is part of the .NET family (C#, F#, and Visual Basic), providing some flexibility in language choice.

The engine offers a pure .NET experience that includes many of the advantages inherent to the framework, like hot reloading. At the time of writing, Stride runs on .NET 8 (the latest version of the framework) and supports C# 12. Because the engine closely follows the .NET update schedule, you often get the most modern and up-to-date implementation of C#. You can seamlessly incorporate almost any C#-based library or tool available through NuGet, GitHub, and other platforms into Stride, enhancing your workflow. Stride is modular enough that sections of Stride are available as standalone NuGet packages. The engine provides the ability to tailor-make your game development experience.

The engine does its best to ensure it does not become a technical bottleneck for your game. A lot of processing within Stride is multithreaded. This means it allows logic to run on multiple threads of execution concurrently. The engine even implements a custom thread pool to maximize engine performance. As a result, Stride takes full advantage of the hardware it is running on, providing players with faster and smoother experiences. All the tools Stride uses to support multi-threading under the hood are also accessible to developers. Nothing is out of reach. An entire library exists within the engine focused on multi-threading that anyone can leverage in their projects. Used with features like the upcoming Bepu physics integration, it becomes possible to have tens of thousands of physics-based objects concurrently in a scene with little effort. Stride provides the space to explore multi-threading and have fun with it.

What engine should you pick? And other closing thoughts 🔗

There is no one right answer. Don’t trust anyone claiming otherwise. Here is the truth: the answer lies in whichever you enjoy using the most. Game development is a process. It requires a healthy level of commitment and discipline. Anyone can do it, but you need to put in the effort. The better your tools fit with your way of working and thinking, the more likely you’ll commit to your project and put in your full effort.

All these engines are free and include active communities ready to help new folks. Pick whichever engines strike your fancy and try them. Maybe one of them has that one specific feature that hits just right. Maybe another has a community you love hanging out with or the engine integrates well with a tool you’re using already. Whatever the case, it’s a matter of taste and what works best for you.

Wanting to know if an engine can make a specific type of game is asking the wrong question. People make games in Excel. You can make just about any game in any engine. It’s not always a trivial task, but you can do it. Instead, ask yourself which tools you enjoy using the most.

When you settle on an engine, remember this: your engine is not your identity. Your tools are a means to creating something, not a core pillar of your very being. I cannot stress this enough. Your tools do not define you. This may sound obvious, but I have seen many, many folks make their engine of choice a centerpiece of who they are and become unnecessarily hostile toward other engine communities. Please don’t do that.

You are not simply a Bevy developer, Godot developer, O3DE developer, Stride developer, or whatever else. You are a game developer. So don’t get hung up on which engine you should pick. Choose the engine that resonates with you the most, and you’ll quickly learn skills you can apply anywhere. Make creating something rewarding in and of itself. If you enjoy working in your environment, you will enjoy the act of development. Once you manage that, creating anything, game or otherwise, will feel immensely satisfying in its own right. Be curious and have fun.

Acknowledgments 🔗

This article was only possible with the input of contributors and users involved in these game engines. I appreciate all the folks who were kind and patient enough to fact-check me and provide their feedback, including Vaclav Elias, Joreyk, Doprez, Judah Perez, Clay John, Adam Scott, Fredia Huya-Kouadio, Pāvels Nadtočajevs, as well as the Open 3D Foundation and Open 3D Engine contributors.

Last but not least, thank you to Ed (Meltted) for creating the featured image.

Announcing Stride 4.2

Tue, 06 Feb 2024 00:00:00 +0000

Stride contributors are thrilled to announce the release of Stride 4.2, now fully compatible with .NET 8 and leveraging the latest enhancements in C# 12. This release brings significant improvements in performance, stability, and developer experience.

Table of Contents:

A massive thank you to the open-source Stride community for your dedicated contributions. This release saw over 75 contributions from more than 22 amazing contributors, each playing a crucial role in making Stride 4.2 a reality.

Download and Upgrade 🔗

You can download the Stride 4.2 Installer today. Release notes are available here.

Make sure you read the guide to update Stride and projects properly.

Unity Licensing Model Impact: A Catalyst for Change 🔗

The game development world has seen quite a stir with recent changes in Unity's licensing model. These shifts have led many in our community to rethink their choice of development tools. Stride 4.2 steps up in this scenario as a solid, C#-based alternative, offering a familiar yet distinct approach for game developers.

Stride's Rising Popularity 🔗

It's been an exciting time for us. We've noticed more and more developers giving Stride a try, a trend clearly reflected in our growing user numbers. During the crazy Unity days, we were number 3 in the popularity rankings, just after Godot and Bevy. Also a big shoutout to gamefromscratch for his video "Stride For Unity Developers", which definitely helped.

The Heartbeat of Stride: Our Community 🔗

What really makes Stride tick is you – the community. Your feedback, contributions, and ideas have been the driving force behind Stride 4.2. It’s your hands-on experience and insights that have helped shape this release, making Stride not just a tool but a community achievement.

Addressing the Pace of Updates in Stride 🔗

Let's talk about how often Stride gets updated. We know it's something on your mind, and that is why we want to explain the dynamics that influence it.

The People Behind Stride 🔗

Stride is maintained by a group of passionate developers, much like yourself, who contribute in their free time. This means our pace might not match that of other engines backed by full-time teams. Luckily we still have the original creator and lead of Stride among us to tackle tricky issues and infrastructure.

Facing the Realities: Funding and Resources 🔗

Here’s the deal: our funding levels shape how much we can do. We’re grateful for every bit of support we receive, but we’re still on our way to having a full-time development force. This financial reality does affect how fast we can roll out updates. Although we might not be the fastest out there, we focus on making each update meaningful.

Funding and Resource Allocation 🔗

Challenges in Distribution 🔗

The pace at which we distribute funds is often perceived as slow. However, this is not from a lack of willingness but rather the challenge of finding the right talent for the tasks. Nonetheless, we are actively funding projects at this moment, focusing on enhancements in XR, introducing morph target capabilities for 3D models (aka Blendshapes), and updating the bindings for the Assimp 3D importer to Silk.NET.

Call for Skilled Developers 🔗

Join Us on This Journey 🔗

The Impact of Your Support 🔗

We believe that every donation has a substantial impact, perhaps more so than in some other projects. Why? Because C# as a language offers high productivity, and the Stride codebase has a great architecture. This means that every dime you contribute goes a long way.

Imagine how much we could do if Stride got as much financial support as other big engines. With C#'s easy productivity and Stride's well-organized code, your donations could help us improve much faster. It's not just about keeping the lights on; your support can take Stride to new heights!

Looking Ahead 🔗

With your support, we’re optimistic about picking up the pace. Our goal is to bring you new features and improvements more regularly, making Stride even better with each release.

What's New in Stride 4.2 🔗

Stride 4.2 includes numerous enhancements and improvements. Here’s what to expect:

.NET 8 Integration: Stride 4.2 is now fully aligned with .NET 8, harnessing its performance improvements and efficiency gains for game development. This means faster execution times, reduced memory footprint, and access to the latest C# features, making your development smoother and more efficient. Learn more
C# 12 Features: With C# 12, Stride users can write cleaner, more concise code thanks to new language features. These improvements reduce boilerplate and enhance readability. Discover C# 12
Changed Assimp Binding to Silk.Net.Assimp: This update transitions the asset compiler's binding from C++/CLR to Silk.Net.Assimp, a move that not only simplifies the codebase but also paves the way for asset compilation on non-Windows systems, broadening Stride's accessibility. See the pull request
Migration NET6+ and More gettextnet#2: Stride's commitment to staying current with .NET versions continues, ensuring compatibility and leveraging the stability and features of the latest .NET environment across all aspects of the engine. Check out the update
Enable Multiple Profiler Consumers and Add a Timeline/Tracing Profiler: This enhancement introduces a profiler with chrome://tracing output format, significantly improving the debugging and performance tuning process by allowing for a more granular analysis of game performance. Explore the feature
Feature: Add Support for F# and VB Project Types: Stride now welcomes developers using F# and Visual Basic, offering support for code-only projects in these languages. This opens up Stride to a broader audience. Learn about F# and VB support
Stride Diagnostics Analyzer: This new tool provides immediate feedback within your IDE, identifying potential compatibility issues with Stride's serialization system. It's about making your development process smoother and helping you catch and resolve issues faster. Discover how it works, the docs page and here is the pull request.
OpenVR Handle Custom Resolution Specified by the User Through VR Settings: Enhancing VR development, this update allows developers to specify custom resolutions for VR projects, optimizing performance and visual quality for various VR devices. See the details
Editor Enhancements:
- Dynamic Snapping for Selected Objects: This feature introduces dynamic snapping while transforming objects, improving precision and workflow efficiency within the Stride Editor. Dynamic snapping PR
- Animation Stack Selection for FBX Imports: Stride now allows you to select specific animations from a stack when importing FBX files, giving you more control over the assets you bring into your projects. Learn more
- Automatic Asset Copying to Resources Directory: To streamline asset management, the editor can now automatically copy imported assets to the project's Resources directory, ensuring your assets are always where they need to be. See how it works

Fixes 🔗

Although there have been many fixes, we'd like to point some of them out:

See the full list in the Release Notes.

Exciting Development in Stride Physics 🔗

Stride 4.2's release isn't just about what's in the box; it's also about what it enables for the future. A standout development in this context is the integration of a new physics package in Stride.

Introducing Bepu Physics in Stride 🔗

Our Discord community is buzzing with the news of Bepu physics, a project initiated by our user Nicogo1705.

BepuPhysics v2 is a high-performance, multi-threaded physics library, written entirely in C#. Its compatibility with Stride's C# ecosystem offers the perfect alternative to the Bullet 3D physics engine, which relies on C++ Interop.

With additional support from Doprez and Eideren, the efforts in integrating Bepu physics have already shown impressive results, especially in editor compatibility and performance. As you can see in this video, running on almost 10 year old hardware (yes, cube fountain included):

Nicogo's YouTube channel features some more demo videos.

GitHub: Nicogo1705/Stride.BepuPhysics

Future Prospects and Disclaimer 🔗

Currently an independent package, Bepu physics is charting a course towards deeper integration within Stride. While it stands as a potential future replacement for Bullet physics, the package is still evolving. Future updates may necessitate adjustments to projects using its current version. We encourage users to stay updated and adaptable as we continue refining Bepu physics with the community's support. The pull request can be found here: [Physics] Bepu integration

Also good to know 🔗

Although not directly tied to Release 4.2, we have some more big things going on.

For instance to our website and documentation. We also had another community meeting to address all those new members.

And last but not least:

Cross-Platform Evolution: The Stride Editor and Avalonia 🔗

One of the most ambitious projects for Stride to date has started: The porting of the entire Stride Editor from WPF to Avalonia, a cross-platform C# UI library. This significant endeavor, undertaken by Kryptos-FR, a former Stride developer.

Currently, the project is in the early stages but it not only anticipates making the editor compatible with Linux and MacOS but also aligns with the long-standing community desire for broader platform support and enhanced editor functionality, including a robust plugin system.

More details in this pull request: Cross-platform editor rewrite - prototype

Links 🔗

GitHub: https://github.com/stride3d/stride
Website: https://stride3d.net/
Documentation: https://doc.stride3d.net/latest/en/manual/
Twitter: https://twitter.com/stridedotnet
YouTube: https://www.youtube.com/@Stride3D

Acknowledgements 🔗

In particular we want to thank these donors:

Long time Stride supporters 🔗

VVVV🥇

Platinum Striders 🔗

Happenstance Games🏆

Gold Striders 🔗

This article was co-authored by Aggror Jorn and Tebjan Halm.

Investigating SPIR-V for the shader system - Part 1

Fri, 10 Nov 2023 00:00:00 +0000

In this first part of a new series of blog posts, we will learn more about Stride's shader system, its limitations and how to make it better thanks to a very useful shader language called SPIR-V. This will be the first step in implementing a new and better shader system.

If you're interested in the other parts of this blog series :

Part 2 we parse and assemble some SPIR-V
Part 3 we write a new parser for SDSL

Table of Contents:

The Stride engine has a powerful shader system, helping users build very complex shaders thanks to its language features like composition and inheritance, and its C# integration through the very powerful material system.

What are shaders? 🔗

Simply put, they are typically snippets of code that are run on the GPU, mostly written in C-like languages like GLSL and HLSL.

When a game has to render on the screen, it starts by preparing the data on the GPU and then sends shaders with commands. The GPU then executes those commands and if everything goes well, the game ends with a lovely picture drawn on the screen. This single call of a GPU is called a draw call.

It can be simplified to this view. There is a first stage called Vertex stage which is meant to compute vertices and make sure they are transformed into data that can be rasterized by your GPU, and a final stage called Pixel stage or Fragment stage that takes the rasterized output of the rasterizer and computes color for each pixel on the screen based on which triangles they belong to.

In both stages, you can provide textures/images and data through buffers, this can help give more details to your rendering, or help you compute more complicated things.

Rendering in game engines 🔗

Drawing a single mesh is simple, one buffer of vertices, maybe some textures, do a draw call and ✨ marvel at the screen ✨. Repeat it many times and you get a video, very useful to make video games 👾.

In game engines, objects being drawn the same ways are grouped into materials. A material can be seen as a recipe for drawing a mesh with ingredients like shader code, textures, vertices and other informations.

Having many different materials implies creating many shader source code, and depending if you use forward or deferred shading, you might need to reuse code from one file to another leading to lots of duplicate code 👩‍💻👨‍💻.

To solve this problem, all game engines have developed shader systems that help create permutations of shader code depending on the material you're using. It helps reuse code you've already written, which speeds up development and gives you the power to organize your code in more manageable ways.

A good example of that are shader graphs from Unity or the material editor in Unreal, whenever you add a block/function to the graph, it reuses shader code already written, to create a new permutation.

How does it work in Stride? 🔗

Stride has its own shader language called SDSL which stands for StriDe Shader Language.

SDSL uses a very smart system of composition and inheritance, similar to object oriented programming. You can learn more about it through the manual.

The many problems shader systems are facing 🔗

To create permutations you need to be aware of the many limitations you will face while writing code for GPU.

GPUs are all different 🔗

As obvious as it sounds, it needs to be reminded. Whenever you write code for your GPU you have to be aware that it will not work for all other GPUs.

10 years ago, two languages were the most used for writing shader code: HLSL and GLSL. In the case of OpenGL, GPU vendors would provide you with their own GLSL compilers to work for their GPUs through different drivers. A valid code for one compiler would be a syntax error for another. It was a big mess 💩, but a manageable one!

Stride was created during this period and it was designed to run on a wide variety of devices 🎮 🕹️ 💻 🖥️.

The solution chosen for creating code permutations that could work on many different machine was transpilation. Text would be parsed in abstract syntax trees and the text would be translated from one language to another by manipulating those trees. To have a better idea of how abstract syntax tree work, this playlist of videos will definitely help.

Drivers are not all the same 🔗

Drivers can be seen as a front-end API to use the GPU. They have different paradigm and logic which may result in your shader code needing to be different across different drivers.

Here's a table of which language is supported by which machine depending on the driver used. I chose the most used machines for gaming.

Note that some APIs are tied to the machine you're developing for, adding more complexity to the shader system, needing to handle GPUs that have very specific features. Vulkan and OpenGL can be used on Mac and iOS but OpenGL is deprecated and Vulkan run on MoltenVK, a Vulkan implementation on top of Metal.

	Direct3D	Vulkan	OpenGL	Metal	PSGL	NVN
Windows/XBox	HLSL	HLSL/GLSL	GLSL
Linux		HLSL/GLSL	GLSL
Mac/iOS		HLSL/GLSL	GLSL	MSL
Android		HLSL/GLSL	GLSL
Playstation 4/5					PSSL
Nintendo Switch		HLSL/GLSL	GLSL			?

Performance Cost 🔗

Managed languages like C# are well known to be slower with string objects since they treat them as immutable. On top of that, tree structures, especially the one used for shader compilation in Stride, tend to perform very slowly and are prone to be slow and work against the GC.

Why investigating SPIR-V? 🔗

Three things happened in the past 10 years:

Vulkan was released with a new kind of bytecode shader language called SPIR-V
.NET Core introduced a new high-performance feature for operating on slices of array (something that C# is way better at than processing string objects), namely Span<T>
Most importantly, tools like SPIRV-Cross and Naga were created as a means to translate shaders through SPIR-V

It was clear for everyone that we had to investigate how we could compile SDSL to SPIR-V and use all those very performant tools to transpile SDSL to other languages.

SDSL is a very peculiar language and shifting from processing tree structures to processing segments of byte code is a great endeavor, especially for an engine.

The following parts of this series of blog posts will focus on how such a system can be created, thanks to the many new C# and .NET features that came out since the release of .NET Core.

Summary 🔗

Embracing SPIR-V for Stride's shader system will hopefully empower us with a better control over the shader language but also improve performance for shader compilation 💪💪.

Thank you for reading!

A closer look: Diagnostic Analyzers with Roslyn

Mon, 23 Oct 2023 00:00:00 +0000

Let's take a closer look at the DiagnosticAnalyzer feature added in Stride.Core.CompilerServices. This feature offers real-time code analysis in your IDE, enhancing your workflow.

Table of Contents:

Stride continues to evolve, adding new utilities and features every week. This blog post will cover the newly added DiagnosticAnalyzer feature in Stride.Core.CompilerServices.

What is a `DiagnosticAnalyzer`? 🔗

A DiagnosticAnalyzer is a feature from Roslyn that scans your code while you are typing in your IDE. C# also utilizes this feature; every time you see a warning or red squiggly lines in your IDE, a DiagnosticAnalyzer gets triggered. Analyzers are offline tools used by the compiler to assist programmers. They are not used to collect telemetry on how Stride is being used.

What does it do? 🔗

The new Diagnostics primarily focus on Serialization. These analyzers generate warnings for code that is incompatible with Stride's Serialization Rules of Thumb.

Each error code follows this format: STRDIAGXXX, where 'X' represents a numerical digit. Clicking on these error codes will open a help page that explains in depth why the DiagnosticAnalyzer was triggered and how to resolve the warning. You can find these error code pages here.

Example 🔗

In this example, we'll delve into a common scenario where the DiagnosticAnalyzer spots issues related to Stride's serialization rules. We have a Dictionary property named Name within a class Example. We've also adorned the Name property with [DataMember] and [DataMemberIgnore] attributes which are contradictory, and this is where the DiagnosticAnalyzer steps in to provide valuable feedback.

public class Example
{
    [DataMember]
    [DataMemberIgnore]
    public Dictionary<Example, int> Name { private get; set; }
}

Upon compiling, the DiagnosticAnalyzer flags three diagnostic warnings related to the attributes and the property's accessibility:

STRDIAG000: There is an Attribute Contradiction on 'Name' Member. [DataMemberIgnore] Attribute on a [DataMember] is not supported. Except if it has also [DataMemberUpdatable] Attribute.
STRDIAG009: The member 'Name' implements IDictionary<T,K> with an unsupported type for the key. Only primitive types ( like int,float,.. ) are supported or string or enums as the Dictionary Key in asset serialization. When used in other contexts the warning may not apply and can be suppressed.
STRDIAG004: The property 'Name' with [DataMember] does not have an accessible getter which is required for serialization. A public/internal/internal protected getter is expected.

The following image demonstrates how these warnings are displayed in Visual Studio:

These warnings provide immediate feedback, aiding the developer in adhering to Stride's serialization rules. The DiagnosticAnalyzer not only pinpoints the issues but also suggests the necessary adjustments to align the code with Stride's standards. For instance, it suggests the removal of the [DataMemberIgnore] attribute or the addition of a [DataMemberUpdatable] attribute to resolve the attribute contradiction on the Name member. It also highlights the requirement for an accessible getter for serialization, and informs about the supported types for the Dictionary key in asset serialization.

Why use it? 🔗

This real-time feedback is invaluable, making the coding process smoother and less error-prone, and ensuring that the codebase remains compliant with Stride's serialization standards.

This feature aims to minimize those "Why is my property not showing up in the Game Studio?" moments. It's often unclear why certain properties don't appear in the editor. These analyzers are designed to clarify such situations, aiding your development process in Stride.

Current State 🔗

The pull request (PR) to introduce these analyzers has been merged. However, there hasn't been a release that includes them yet. If you're eager to test them out, you can build the engine from the source. Otherwise, you'll have to wait for the next release of Stride's NuGet packages.

For Engine Developers 🔗

Adding new analyzers to the Stride engine is straightforward. However, be aware that Visual Studio (VS) has a bug caused by .NET, which makes VS load Roslyn only once at startup. To work around this, compile Stride.Core.CompilerServices and restart VS after adding a new analyzer.

Summary 🔗

This is a new quality-of-life feature that simplifies development in Stride by providing immediate feedback on coding issues.

Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

Community Meeting October 2023

Sat, 07 Oct 2023 00:00:00 +0000

On October 7th, a community meeting was held addressing new user influx, planning the release of Stride 4.2, contingent on the .NET 8 launch.

Summary 🔗

During this almost 3 hour long session we talked about the following: improving domain knowledge, access rights, and documentation, transferring the Stride Community Toolkit to the official repository, and community-driven initiatives like a new demo project and extending tutorials. Significant attention was given to a substantial editor rewrite from WPF to Avalonia for enhanced cross-platform support, opening it up for community contributions.

Table of Contents:

Short summary of Contributor meeting 🔗

A few weeks prior to the community meeting, we held a contributor meeting. This was mostly to address the recent instream of many new users. Since we suddenly got an abundance of user feedback we took and planned some steps.

Inventorizing domain knowledge and access rights.
- This overview will be posted soon on GitHub.
Moving the Stride Community Toolkit to the official Stride repositories.
Investigating nightly/weekly/monthly builds and releases.
- The idea of having more frequent releases was discussed to provide users with the latest PRs and fixes, whilst also having more publicity.
- Concerns were raised about the potential impact on development velocity and the need for stabilization phases. As soon as the new build system (arranged by Xen) is up and running, we can decide on how often we make an official (minor) release. More on this later this year.
Updating contributors' documentation.
- Next to the official documentation/tutorials, we also have various wiki pages per repository. Especially the documentation for Contributors and building from source, needs some love. Aggror is going to make an initial pull request for this.
Planning and creating videos for contributors.
Adjusting the strategy with OpenCollective Projects: here we came to the consensus that we required more feedback which we would gather during the community meeting.

Release of 4.2 🔗

Stride 4.2 is around the corner, but when exactly?

For 4.2 we are waiting for the official release of .NET 8 which is to be release on November 14, 2023.
- Since we want to release a version for .NET 6 and .NET 8, our goal is to release within a few days after the release of .NET 8.
Prior to the official release we will have a release candidate. This will be announced when it is available.
At the moment there is 1 open bug and 1 open pull request for a feature. Other than that, the build is locked for features. Only bug fixes would be allowed in
The open pull request for Silk.NET. will be moved to 4.3 to ensure stability.
For more info on the final items.

Open Collective 🔗

Next we discussed the use of Open Collective for donations and funding specific projects.
Although not mentioned in the meeting, our current funding is 12,992.34 USD.

Up until this point it has been quite a challenge finding the right developers for existing Projects. The most recent successfully funded Project was the Bug bounty for Vulkan fullscreen.
There have been several suggestions to make funding more attractive, such as increasing compensation and investing in areas like documentation, marketing, and design next to coding Projects.
Every project should have a referencing GitHub ticket that contains as much detail as possible for the deliverables.
There are currently two talks ongoing for specific development. Once we have confirmation we will communicate this with the community.

New projects 🔗

We will add several new Projects to the Open Collective. This will give members a clear view on 'targets' that we like to see funded.

Extending tutorials. Both written and video tutorials
- New tutorial set for a small 3D (platformer) game
- Contributor tutorials
Demo scene 2024 (more on this below)
Stride editor Avalonia (more on this below)

New Demo project 🔗

We want to have a new demo sample project that demonstrates Strides capabilities. Members who want to help out, can add to the discussion here.

Community Toolkit 🔗

There is a new initiative called the Stride Community Toolkit, aimed at aggregating common features, helpers, and extensions to streamline Stride development. It allows community members to test and enhance tools and propose their integration into the engine. This project has come to fruition with the combined effort of several users, and specifically the repositories off dfkeenan and VaclavElias.

Stride Plugins 🔗

A topic talked about for several years now and it's quite an important one. Plugins allow you, for one, extend the editor with new functionality without having to build the engine from source. Ideally you want to go to some (NuGet) store and click -> install this awesome extension/plugin for Stride.

If you want to contribute to the discussion on how to do this technically.

We can divide plugin support into 2 categories:

Asset plugins: these would be purely models, textures, prefabs, components
For this Manio143 is taking the lead.
Editor plugins: this category currently is not viable because of the dependency to another large topic: the need to rewrite the editor to a new library, replacing WPF.

Since we are short on development time here, we need to take into account that it will be a while before we can see the first results of this.

Stride UI Rewrite 🔗

The Stride editor is built with WPF and therefore only works on Windows. WPF isn’t really being developed anymore and on top of that we want to start supporting the editor on Linux. We can only do so by rewriting the editor to another UI framework.

Just like the Plugin topic, the Editor rewrite is a big topic. Probably the biggest topic of them all. The editor rewrite has been discussed in great lengths on both Discord and GitHub in the past few years. People have shared their ideas on which framework to use (Avalonia, MAUI, Uno etc), made some prototypes, even ported the Stride launcher. But we never really ‘actively’ made this an official item since it would take a full time developer many months to work on this task.

Members have been asking if they can help out with the rewrite, but up until this point, there wasn't really an official starting point. We also don’t want to waste the prototype/knowledge already collected. That is why we will soon have an official GitHub branch in the Stride repository where all Editor UI rewrites are taking place. We are fully aware that this might take a long time and a lot of effort from multiple people, but we have to start somewhere. We also anticipate that we can use some of the OpenCollective funding for this.

So regardless of time/developer power: we have landed on using the Avalonia UI framework to rewrite the editor. Aggror will set up a GitHub topic summarizing how people can contribute to this UI rewrite branch and inventorize how we can split this massive task into subtasks.. More details on this will follow later this year.

Acknowledgements 🔗

We extend our heartfelt gratitude for all the recent donations that have been made. Your generous contributions significantly aid in the continuous development and enhancement of the Stride community and projects. Thank you for your support and belief in our collective efforts.

In particular we want to thanks these donors:

Long time Stride supporters 🔗

VVVV🥇

Platinum Striders 🔗

Happenstance Games🏆

Gold Striders 🔗

A closer look: Setting private members in the editor

Thu, 21 Sep 2023 00:00:00 +0000

Let's take a closer look at why currently you can't set private members of scripts and components in the Stride Editor and explore the options to change that in the future.

Table of Contents:

It has been an amazing week for Stride and our Discord is booming with new people who want to learn more about the engine and maybe port some games from Unity. One of the questions that has been asked a few times was why we can't set private members on scripts in the editor. I thought it's a good opportunity to dive a little deeper into the technical reasons and engine architecture to explain the current limitation and explore the options to change it in the future.

What is public and what is private 🔗

Let's run through a quick reminder. In C# members are annotated with access modifiers
such as public, protected or private. The modifier describes the access objects of other classes will have when accessing the members. It allows us to control the API surface of an object by hiding away certain aspects of its state to allow the inner implementation to be changed without affecting other parts of code that would only interact with the publicly visible members.

To understand it better read this analogy.

When designing systems we will often decide to make certain things public (maybe even use an interface to further describe the public API regardless of the class holding the methods) and keep most things private. This allows us to prevent accidental mistakes when another part of the systems makes changes to some delicate state.

However, with a more Data Oriented approach we can find ourselves creating classes which hold mainly data. In many Entity Component System implementations the components are just data bags that systems read and update. With this kind of approach there's rarely need for private members, although sometimes the internal visibility is used for data on a component that is exclusively managed by its default system.

Moreover, component's public properties are often not just modified at design time, but also at runtime. Think about the Transform component and how it's public properties are modified to move the entities around, or how changing the velocity on a Physics component affects how quickly the simulation will move it around on the next step.

Design vs runtime access 🔗

We can talk about components in two contexts: setting the properties during level design in the editor and setting them at runtime while the game is running. We would generally expect in both cases that we can modify the properties of the component and they will be picked up by the processing system.

With the introduction of Scripts, however, which are components containing logic, we get into a bit of a pickle. Yes, the script should be able to have private state and a public API for other components to interact with it. What if we want to restrict some data so that it can only be set once during initialization? Ideally the editor would not be constrained to modify the property during design, but once we hit the runtime it should be allowed to change.

Editor runs your code directly 🔗

In Stride when you create a script in your project and open the project in the editor, the project will be compiled, the DLL loaded into memory of the editor, and when you add the script to an entity it will actually create a new instance of your script class. Same as at runtime.

It won't run the script Update method, but if you have any logic in your property getters and setters those will be invoked at design time. This can give you enormous flexibility. But it also means that however you want your script to behave at runtime when it comes to properties the same will be enforced at design time.

The editor uses reflection to access properties and fields on your script. It technically could modify private fields on the object instance it holds during design. But this needs to survive saving the project to disk.

Serialization 🔗

Stride uses YAML for design time serialization of Assets. The assets can have a different form from the actual Content they are compiled to by the AssetCompiler. This is used for example by Audio or Model assets which at design time just hold a reference to your media files, but once compiled actually hold the bits of your media in a format that's easy to consume by Stride's runtime.

For components and scripts rather than having a second class for each component and doing compilation from design to runtime representation, those classes are the same in both scenarios. This simplifies things but it means that serialization constraints need to be applied equally.

While YAML is very flexible and the serializer currently uses reflection to set the properties, the runtime serialization is done using a custom binary serializer system. When you compile your game project, after C# compiler has done its job, the build system runs the AssemblyProcessor over your code to generate efficient serializer classes that do not use reflection to access members on the objects they deserialize.

Access modifiers are enforced by the CLR, which means it's not possible to generate code that accesses private members of another class directly.

What about constructors? 🔗

If we have a private field that we want to set once, why don't we use a constructor to accept a value for it? It's certainly an option and there are serialization systems which look at constructors to provide deserialization in this way. They may be a bit more complicated but it's possible to implement them.

However, in a generic environment that Stride provides it's a bit difficult. How would the editor create a new instance of your class if it requires data to be passed in the constructor? Will it provide default values, will it look for a private parameterless constructor?

What about init properties? 🔗

C# 9 has introduced init properties which are only allowed to be set at object construction. Reflection is able to bypass that of course, while at the CLR level a special marker modreq is placed on the property which asks the compiler to provide modreq marker on the callsite as well (see thread). Compilers which don't know about init properties would still prevent you from assigning them. And the CLR is not actually enforcing anything here - only compiler - thus the generated serializers are still able to use those properties.

But in your code the constraint will be enforced and no runtime modification will occur after the object is initialized.

public string MyProperty { get; init; }

`UnsafeAccessor` in .NET 8 🔗

As we're trying to squeeze out more performance and improve the Stride codebase we're looking at rewriting the AssemblyProcessor from Mono.Cecil and manually emitting IL into a Roslyn C# source generator. This will also mean being restricted to whatever the compiler enforces, such as not setting init properties outside of object construction.

Luckily in .NET 8 there's a new performance hack which allows you to access private fields on other classes. You can read about it more in the proposal and on the performance blog.

[UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_myField")]
extern static ref string _myField(MyClass c);

Summary 🔗

There might be some extra work needed to implement the changes to allow setting private members in the editor. At the moment using init properties is nice a middle ground.

While in my opinion designing clear public APIs for components in a data driven approach is the way and it doesn't need access to private members, there's many users who see value in being able to use private members to their advantage and it's on the editor and engine to provide flexibility of choice in how you structure your code.

Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

Unity's Licensing Changes: Discovering Stride, a Community-Driven Open Source Engine

Thu, 14 Sep 2023 00:00:00 +0000

Explore the key differences between Unity and Stride, a C#-based, open-source game engine powered by .NET 6 (soon .NET 8). Learn how Stride's flexibility and native .NET support offer a unique development experience.

Table of Contents:

Introduction to Stride 🔗

Stride is not just another game engine; it's written entirely in C# and serves as a powerful platform in the .NET ecosystem. This unique focus on C# offers developers the native .NET tooling and functionalities they are already comfortable with. What sets Stride apart is its project structure; Stride projects are standard csproj files, allowing them to integrate effortlessly into your existing .NET solutions.

Difference Between Unity and Stride 🔗

Unity is developed by a large team and offers a feature-rich experience. On the other hand, Stride is open-source and built by community contributors.

This means that Stride might not have all the features that Unity has, simply because there aren't as many people working on it. However, the open-source nature of Stride allows you to customize it according to your needs and provides a solid foundation for any rendering project.

Additionally, Stride allows you to utilize any NuGet package and even provides access to the Main function of your game. You can also find useful resources such as documentation, community toolkits, and guides for migrating from Unity to Stride.

Stride for Unity Developers

Licensing 🔗

Stride is released under the MIT license, which is important because it grants you significant freedoms to use, modify, and distribute the engine.

What games were made using Stride? 🔗

For examples of games developed using Stride, check out Made with Stride section.

Operating System Support 🔗

Editor: Windows
Runtime: Windows, Linux, macOS, Android, iOS

IDE Support 🔗

Stride games are "standard" C# projects, meaning you can use a variety of IDEs:

VS Code
Visual Studio 2022
Rider
Blocknote + MsBuild
VVVV

Note: There's a Visual Studio extension for syntax highlighting, shader build keys and error checking.

Note: Another extension offers syntax highlighting only.

.NET Hot Reload Support 🔗

Stride has the capability of using .NET Hot Reload for C# scripts, allowing real-time code modifications as your game runs. Importantly, this feature is also available when editing the engine side, giving you even more flexibility. Standard .NET hot reload rules are in effect.

This feature streamlines development by minimizing the delay between coding and observing results, enhancing both efficiency and ease of use. If you're familiar with .NET and C#, you'll find that Hot Reload in Stride feels intuitively familiar.

Multiplayer Support 🔗

Stride does not offer built-in multiplayer or Server/Client architecture. However, you can easily integrate any .NET networking library to implement these features. You have the freedom to choose from a variety of libraries and resources. For a curated list, you can check out Awesome-Stride's Networking section.

Unity Assets 🔗

You can import some 3D models from the Unity store into Stride. However, scripts will need modification since the two engines differ.

These are the basic Scripting Differences:

StartupScript is a MonoBehaviour without the Update method
SyncScript is a MonoBehaviour with an Update method that runs every frame
AsyncScript is unique and runs asynchronously

Screen Capture 🔗

To capture a frame, you can use the following code snippet:

var commandList = GraphicsContext.CommandList;

commandList.RenderTarget.Save(commandList, stream, ImageFileType.Png);

Shaders Available 🔗

SDSL is a shader language written on top of HLSL.

Build Automation 🔗

Yes, since Stride uses .NET, automating the build process works out-of-the-box.

Add-ons and Extensions 🔗

You cannot extend the editor in the same way as Unity, but you can create custom code extensions as seen in the following:

Transformations 🔗

The TransformComponent class in Stride is a fundamental component for representing an entity's position, rotation, and scale within a 3D scene.

Important Features:

LocalMatrix and WorldMatrix: These matrices manage the transformations of the entity.
Position, Rotation, and Scale: These properties represent the entity's position, rotation, and scale in the local coordinate system. The Position property is a Vector3, defining the entity's position. The Rotation property uses a Quaternion to represent the entity's rotation, and the Scale property is a Vector3 that sets the scale. You can modify these properties to transform the entity.
UpdateLocalMatrix() and UpdateWorldMatrix(): These methods update the local and world matrices, respectively.
Parent and Children: These properties allow you to establish parent-child relationships between entities, affecting their transformations accordingly.

Rendering 🔗

Stride primarily uses clustered forward rendering, with some additional features. Read more in the docs.

Gamepads 🔗

Gamepads

Other Q&A 🔗

What is the Equivalent of a Coroutine in Stride? 🔗

Unlike Unity, which uses IEnumerator for asynchronous code execution, Stride leverages C#'s built-in await and async features. This can be accomplished using AsyncScript, which essentially acts as a SyncScript (the Stride equivalent of Unity's MonoBehaviour) but with asynchronous methods. You can use async methods within sync scripts, the same as standard C#.

What is a StartupScript? 🔗

A StartupScript in Stride includes a Start method that is invoked when it's added to the scene tree. This is similar to Unity's Start or Awake methods. However, StartupScript does not contain Update methods and therefore doesn't execute code every frame.

Using Other Assemblies/Projects in Stride 🔗

In Unity, the packaging system is built on top of a csproj file, which allows Unity to protect its proprietary source code. Stride, however, grants you full access to your csproj and sln (Solution) files. This enables you to include any NuGet packages or other C# projects in the usual way, by adding project references. If you add a new subproject to your main project through the Stride editor, it will be correctly configured by default, including folder location and references to the Stride engine.

Is There an Asset Store for Stride? 🔗

No, Stride does not have a dedicated Asset Store. However, most additional libraries specially designed for Stride can be found on GitHub or NuGet. For easier discovery, a summary has been made available at Awesome-Stride.

Null Checking in Stride vs Unity 🔗

Does is null and == null work? Unlike Unity, which has overridden the Equals operator to be compatible with its C++ engine, Stride allows you to use is null and == null to compare the existence of an Entity or Component directly.

Where to Start 🔗

Getting started with Stride is easy, thanks to a wealth of resources available. Here are some you shouldn't miss:

Stride's Manual: A comprehensive guide that covers everything from basic setup to advanced features.
Stride's Tutorials: Step-by-step tutorials to help you get your first project off the ground.
Discord: Join the community on Discord for real-time discussions and the latest updates.

How to Find Answers 🔗

Consider checking these platforms where your query may have already been addressed or where you can gain more context:

Discord: Use the search functionality in our Discord channel to see if your topic has been discussed before.
GitHub Issues: Navigate to Stride's GitHub Issues to see if your question is related to a known issue or feature request.
GitHub Discussion: Participate in Stride's GitHub Discussions to engage with the community and explore various topics.

This proactive approach not only helps you get immediate answers but also makes it easier for the community to focus on unresolved or unique queries.

🤝 Join Us: Stride Bug Bounties and Feature Funding 🛠️ 🔗

We invite talented developers to collaborate with us through our Bug and Feature Bounties. With tasks ranging from Vulkan support to decals and morph targets, there's something for everyone! Reach out via the specific GitHub Bounty tickets to get involved.

📬 For suggestions on new bounties, don't hesitate to connect with us on our Discord server or directly through GitHub.

Participating in our bug bounties is a win-win! Not only will you be able to hone your skills, but you'll also contribute to the expansion and enrichment of the Stride community—and get compensated for your efforts! 💰

Stride's Open Collective Projects

Flappy Bird - Stride Engine Demo 🔗

Ned Reid, a new member of the Stride community, has created a Flappy Bird demo, while exploring Stride as an alternative to Unity. He shared the following thoughts on his experience:

I decided a couple of days ago that I would explore engines outside of Unity (for obvious reasons), and wanted to start with something simple. Over a fairly relaxed weekend, I've managed to put together a neat little Flappy Bird clone!

A screenshot of the Flappy Bird demo created by Ned Reid

Closing Thoughts 🙂 🔗

If you've made it this far, congratulations 🎉! You now have a comprehensive understanding of Stride, its capabilities, and how it compares to Unity. The world of game development is vast and ever-changing 🌍, but the emergence of community-driven, open-source engines like Stride showcases the exciting directions the industry is taking. With its C# focus 🎯, extensive .NET support 💻, and flexible licensing 📜, Stride is a formidable option for both new and experienced developers.

As the saying goes, the best way to learn is by doing 🛠️. So dive in 🏊, start a project 🚀, and don't hesitate to participate in the community discussions on Discord or GitHub 👨‍💻👩‍💻. Your journey with Stride is what you make of it, and the resources and community are here to support you every step of the way 🤗.

Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

Taking .NET Game Development in Stride

Thu, 15 Jun 2023 00:00:00 +0000

Just a little reminder that Stride has been presented in a .NET Live! 🎥🎥🎥

Vaclav, Tebjan and I participated in a .NET live session to showcase the Stride engine, as well as some work done by users. Many questions were asked, and Manio answered many of them in the chat.

Watch the .NET Live right here 🔗

Content

History of the Project
Roadmap
What are some of the big game titles that folks would recognize
The UI
Add Scripts to Entities
Integrating Stride into your projects
Add Interaction
Shader System of Stride
Shader Code
Shader Language

The most important questions answered 🔗

In this live session, we answered the most important questions about the project, including how to use Stride and what it aims to be!

Tebjan presented a bit about what contributors have done and what users (professionals/hobbyists, artists/developers) have done so far to show off the capabilities of the engine. He also gave a small presentation on how Stride is used with VVVV for 3D rendering!

A fun experimentation 🔗

Vaclav, having dived into Stride with a desire to use Stride without an editor, created an API to experiment and create games using just a NuGet package. He presents his NuGet package, explains how to use it, and how to make games leveraging the power of .NET and hot reloading!

Shaders 🔗

I've personally become interested in the shader system of Stride and found it refreshingly easy to use. I decided to show more about how to use shaders, update them, and extend the rendering engine of Stride.

Closing 🔗

We strongly recommend watching this live session, as it will help you gain a better understanding of Stride. .NET is becoming more and more relevant for a game engine, as evident with Stride. Don't hesitate to reach out to our community through the Discord server!

Announcing Refreshed Stride Website

Wed, 14 Jun 2023 00:00:00 +0000

The Stride team is happy 🙌 to announce the release of our refreshed Stride website. We have been working on this for a while, and we are excited to share these updates with you and hope you enjoy the enhanced browsing experience.

The Motivation for the Update 🔗

The Stride website has been around for some time ⌛. It was originally created using Jekyll. Over the years, we have added more content, but the website has not been updated for quite a while.

Our main goal was to make the website future-proof and easy to maintain. We also wanted to improve the overall user experience and give it a more modern feel.

What's New or Updated 🔗

Improved consistency across pages, posts, and styling, offering an excellent reading experience
Enhanced content readability
Modern and simplified design
Updated static page generator: Eleventy 2.0 (previously Jekyll)
Bootstrap 5.3 (previously Bootstrap 3)
Font Awesome 6 (previously 4.4)
Removal of old, unnecessary code, such as AddThis, Disqus, JQuery, and JavaScript libraries
Improved website responsiveness (mobile, tablet, desktop)
Content review and minor corrections
Tags page
Archive page
Every single page was reviewed and updated 🤯
Dark Theme (Experimental)
Search functionality now includes our documentation website
GitHub Wiki was enabled for content contributors, containing information about the website structure, how to add new content, and how to contribute.

This new update will enable us to share more content with you faster and more easily. We will also be able to add more features and enhance the overall experience.

The Disqus comment widget has been removed from the blog posts, as we would like to encourage our readers to use GitHub Discussion or Discord. We are considering integrating the GitHub Discussions with the blog posts.

What's next 🔗

We will continue to improve the website and add more content. Additionally, we will be adding more features and further refining the overall experience.

Our Stride website GitHub issue tracker is open for any suggestions or feedback. We encourage you to collaborate, create issues, and submit pull requests.

Closing 🔗

We hope you like the updated website.

With this new release, we would like to encourage our community to contribute as well. Your experiences, insights, and knowledge are invaluable, and we would love to showcase them on our blog.

If you have a topic, tutorial, or success story you'd like to share, we invite you to get in touch. By contributing, you'll not only help others in the community but also gain visibility for your work and expertise.

Let's work together to make the Stride community even more vibrant and enriching.

Stride 4.1 is Now Live

Sat, 16 Jul 2022 00:00:00 +0000

Stride contributors are proud to announce a new release now running on .NET 6 supporting the latest C# 10. That means you can now head to the download page and start developing your games using the latest .NET technologies.

Stride On .NET Live 🔗

We had the pleasure to be on a live stream with the .NET team! We gave an introduction, overview and some live demos:

Improvements Summary 🔗

Here's a non-exhaustive list of new improvements:

.NET 6 support and VS 2022 plugin
- Stride 4.1 leverages the power of .NET 6
- Support for C# 10
Dithered shadows for semi-transparent materials
Physics constraints
- Bullet constraints wrapped around in easy to use functionality
- Editor gizmos for physics constraints
Physics performance optimization
ACES tonemaping
Fog image effect
Outline image effect
Improved editor gizmos
C# Intermediate tutorials project
- This Open Collective sub-project was successfully funded by the community. All related video recordings are available on Stride's Youtube channel and the tutorials page in the documentation will also be update to reflect the new project.
Many more minor fixes and quality of life improvements
- Fixed sample game
- Simpler Procedural Model creation
- New math signatures (1122, 1121, 1090)
- Dispatcher/threadpool improvements
- Ambient Occlusion quality improvement
- And many other fixes

Improvement Details 🔗

Dithered shadows for semi-transparent materials 🔗

Produces semi-transparent shadows by poking more and more holes in the shadow map based on the transparency of the object, shadow map filtering will blur those holes with their neighbor which will result in those partially opaque pixels.

Physics constraints 🔗

Stride's physics system Bullet comes with a set of constraints for you to use in your projects. These constraints are now all visible inside the editor, previewing the constraints using various editor gizmo.

For more information on all the types of constraints, you can read up about them in the Stride documentation or watch the video below.

Physics optimizations 🔗

Retrieving collision and contact information was previously done by re-testing all components for collisions, which, as one might expect, led to awful performance for physics heavy scenes (could take up to and above 90% of the frame).

Contacts are now lazily evaluated to reduce overhead when nothing ends up reading them. Users can now read and iterate over all collisions through Simulation.CurrentCollisions.

Improved editor gizmos 🔗

The old gizmos weren't very nice to look at, so this feature makes them look better and more user-friendly. It also changes how the rotation gizmo works and adds scale planes to the scale gizmo.

This feature also updates the text on the CameraOrientationGizmo to be XYZ instead of right/left. Still prefer the old text instead of the XYZ coordinate? Don't worry, there's a setting under the viewport settings that swaps it back to the old text.

Intermediate tutorials 🔗

One of the first Open Collective sub-projects is the intermediate C# tutorials project. After discussion in community meetings and with various contributors donating directly to this project, the amount for this project to be included in Stride quickly became a realization.

With Stride 4.1, you will be able to select the C# intermediate tutorials project as a new template project. The template project contains (at the moment of writing) 11 topics that every developer will want to have a look at.

UI basics
Collision triggers
Raycasting
Projecting and Unprojecting
Async(hronous) scripts
Scene loading
Animation basics
Audio
First person camera
Third person camera
Navigation

Each tutorial has a video tutorial accompanying it, which can be found on Stride's Youtube channel. Below you can find the full playlist.

Known Issues 🔗

Integrated C# Editor 🔗

The transition to .NET6 unfortunately broke the help tooltips and the code completion of the integrated C# code editor. But we decided to accept it for now, as everyone is using a proper C# editor anyways, such as Visual Studio, Rider or Visual Studio Code.

The reason for the error is that RoslynPad, the underlaying library, also needs an update or fix. We'll address this in one of the upcoming minor version releases.

A Little Help 🔗

We, contributors, believe that Stride can help .NET game developers make the games they want with ease using their favorite languages. We want to make sure Stride offers the most comfortable environment for developing games, and this takes time and effort.

Since the free and open-source release of Stride, the community has been growing slowly, so we have decided to open a fund to reward developers for any contribution they make to Stride. We set up an Open Collective page to manage our funds and allocate money for features that the community would like to see implemented.

We have various bounties for bug fixes and features (Vulkan support, decals, morph targets, and many others). If you have or know someone with the skills to tackle those bounties, please reach out to us through the respective GitHub tickets. You can also contact us through our discord server or on GitHub to propose new bounties.

Contributors 🔗

Many thanks to all the contributors who have donated their time and skill by adding features, fixing bugs, managing the build pipelines, adding documentation, and reviewing PRs.

Financial contributors 🔗

Also, a huge thanks to the individuals and companies who contributed financially to our Open Collective!

ORE System with a diamond sponsorship
xen2 Core contributor that donated a large portion of the previous Patreon back through Open collective
vvvv A visual live-programming environment for easy prototyping and development. It is designed to facilitate the handling of large media environments with physical interfaces, real-time motion graphics, audio and video that can interact with many users simultaneously. vvvv uses Stride
Vašo
Mitchel Albertz
Bill
Ideonella
Soul Rider
najak3d
Eideren
Jorn Aggror
Marian Dziubiak
Youness KAFIA
David Thunderclown
Christian Clavet
Marko Viitanen
Aaron Disibio
z16
Incognito
Walter Hulsebos
TheKeyblader
James Rinker
ztl
Bruno Garcia
BanditRevolver
EmmX
SeleDreams
Vignette
Longplay Games
Redberd36

Community Meeting February 2022

Wed, 16 Feb 2022 00:00:00 +0000

The Striders discussed allocating their $4,220.48 USD budget for bug bounties and new features. Funding proposals include fullscreen Vulkan support, UI slowness bug research, Linux runtime support, decal support, morphing target animation support, and embedding Stride into UI frameworks. Release 4.1 is in progress, and an Epic grant proposal is being prepared.

Summary 🔗

On February 16th, we held a whopping 2.5-hour community meeting covering various subjects.

Current Funding 🔗

With a budget of $4,220.48 USD at the moment of the community meeting happening, we wanted to decide on whether to allocate money for bugs and new features. So a big thanks to all those who are donating to this project. In particular:

Funding for bug bounties 🔗

Fullscreen Vulkan support
- GitHub ticket
- Bounty: $200,- USD
- AggrorJorn will provide the texts for the bounty and once approved by other contributors/developers in the team, this will be updated on the Open Collective project for Bug bounties.
UI slowness bug
- GitHub ticket
- A smaller $50,- USD bounty for more research on this bug. If it can be pinpointed what exactly is causing this, we can also estimate better whether it is worth spending more money on it.
- Depending on the outcome we might skip this bug and spend time researching/implementing a replacement UI.
- AggrorJorn will provide the texts for the bounty and once approved by other contributors/developers in the team, this will be updated on the Open Collective project for Bug bounties

Funding for features 🔗

Linux runtime support
- GitHub ticket
- Requires mores fleshed out details and deliverables
- Once that is done, we can decide on funding
  - Either fixed amount or use xx,xx amount per hour with a certain limit.
- New Open collective project Linux runtime
Decal support
- GitHub discussion requires more deliverables
- New Open collective project Decals added and will be updated once deliverables are clear:]
Morphing target animation support
- GitHub discussion requires more deliverables
- New Open collective project Morhping Target added and will be updated once deliverables are clear:
Embed stride into UI frameworks
- There already is a work in progress PR that allows developers to specify a custom render context.
- New Open collective Project for Embedding Stride into UI frameworks
Silk.NET
- New Open collective project Silk.NET

Release 4.1 🔗

Release notes wip are prepared by Eideren/Vaso/Yka.
Final checks by Xen2: VS plugin

Additional task for Xen2 🔗

Documentation needs to auto-release when Release branch is updated
Ask previous implementer of SPIR-V shader system if he is interested in new work for Stride

Work in progress 🔗

Code only project: will enter beta phase
- When merged into Stride 4.2 beta, we will add an Open collective page for additional examples.
C# Pong game example: finishing touches (sound)
The following C# intermediate tutorials are written but not yet recorded:
- UI basics
  - Both via the editor as well as entirely through code
- Scene loading
  - Loading/Unloading
  - Reloading scenes
  - Child scenes
- Collision triggers
- Raycasting
- Animation basics
- Audio
  - Small tutorial really
- Navigation meshes and pathfinding
  - Both editor as well as code only approaches
- Sync vs Async
  - Difference and 2 examples

Epic grant 🔗

Yka and AggrorJorn have a look at Epic grant and make final proposal in the 3rd week of February

Community Meeting November 2021

Mon, 29 Nov 2021 00:00:00 +0000

After a month on Open Collective, the Stride collective reached $1,984.31 USD and discussed funding for various projects. Plans for requesting an Epic grant are in progress. Ongoing development includes physics constraints, splines, and the upcoming release of version 4.1.

Summary 🔗

November 29th we had another commmunity meeting. This blog post summarizes the topics we talked about.

Sponsors 🔗

Started of with a thank you to all those who donated on the new sponsor platform: Open collective. In particular a big thanks to:

Xen2, who decided that he wanted to contribute some of the Patreon money back in to the community.
ORE system💎
VVVV🥇
Vašo ( Vaclav )🥇

A Month of Open Collective 🔗

After a month using the new sponsor platform, the Stride collective has reached a balance of $1,984.31 USD. We started discussing how and where the money should be distributed to. We want to do this with the help of Open collective 'Projects'. These projects are listed on Stride's Open collective page, and have their own tiers, targets and description. Users can sponsor projects directly instead of the main Stride collective if they want to.

We have come up with several projects that need to be written out in more detail before we will add them to the Open collective page. All tickets below have a Github disscusion for more details.

OC project: Bug bounties project
- Before starting on an issue, make it known on Github and Discord that your are willing to tackle the issue. It would be a shame if multiple people try to solve the same issue.
- Any PR to the Stride repo must be reviewed by a contributor and discussed if needed.
- Once a PR is reviewed and merged to the Stride repo, the submitter 60% of the bounty.
- The submitter receives the remaining 40% when stride release happens.
- Github Discussion
OC project: .NET 6 platforms support
- In order for proper support for macOs, we need hardware to test this on. Xen2 will look in to the hardware requirements for this.
- Github Discussion
OC project: Shader system
- Xen2 will gather info and budget requirements
- Github Discussion
OC project: Linux/macOS support'
- A rather large topic that require a lot of work is the the support for Linux and/or macOs. When worked out in more detail, it can be used in the plan for requesting an Epic grant. Subtopics to resolve:
  - Runtime/3d
  - Build tools (able to msbuild a Stride project and have the asset compiler work on it) requirement: FBX/Assimp
  - Editor
- Github Discussion

Preparing Request Epic Grant 🔗

For a while now we have been wanting to pursue the option of requesting an Epig grant. In order to do so however, we need to come up with a proper plan. The endgoal is to have a proper document explaining what we want to do, and how we plan to spend any given budget.

AggrorJorn starts a github ticket where we gather info on the request to Epic. He will contact others for proof read and further info. Github Discussion

Some of the topics mentioned:

Shader system
Editor rewrite
Megascan Integration
ECS rewrite/Run Update() and Render() in parallel

Other Action Items 🔗

We close forum in December as there is almost no activity there. We want to utilize Discord and Github discussion for this. The forum will be read only but we will no longer refer to it from the website and Github.
Use a Github project for remaining tasks: Overview
Github ticket on a simple free community marketplace
- Github Discussion
- A lot of people have made usefull components/utilities/art and other usefull assets for in Stride projects. Right now we don't have a quick and easy to import such assets in to an existing (editor) project.
- What we can do it is utilise the existing Nuget (tagging) system so that users can quickly add a component to their ongoing project in the editor.
Documentation on the stride source/new comers tutorial
- YKA, Manio143 and Tebjan collect some info for a tutorial: Github Discussion

Ongoing Development 🔗

Manio143: finishing touches/documentation for Physics constraints
AggrorJorn: Splines
- Trying to finish the base splines which could be integrated in to the Stride source. Other Spline based components should be added later, so that we can have a milestone finished.
- Some tricky stuff with custom translation gizmo's for controlling tangents in the editor are currently holding me back. If this isn't resolved quickly I will make a PR without this (nice to have) feature
Release of 4.1 only held back by final .NET 6 related fixes. After that Xen2 will prepare release. AggrorJorn will aid in blogpost release notes

Open Collective

Sun, 31 Oct 2021 00:00:00 +0000

Stride has been using Patreon and GitHub sponsors for a while now. However, in the recent community meeting of october 1st it became apparent that these donation platforms don't really suit all of our needs. Both GitHub sponsors and Patreon don't really show where the money is going.

To solve this we have been looking at a different platform that allows us to communicate more openly on our expenses and where money will be spent. After some investigation and various registration and other formalities, we can now say goodbye to Patreon, as Stride will from now use the Open Collective platform.

Summary 🔗

Open (Source) Collective 🔗

Open collective is similar to other sponsor platforms, but sticks out in the way it openly displays payments and expenses. Everything about it is open for everyone to see. Through various Tiers, people can sponsor the Stride game engine. Each tier will have its own reward(s). Some tiers for instance will have the reward that users are shown on the stride website as a thank you. This is being worked on.

We also needed a good way to deal with payments towards contributors and any tax related activities that come with it. Open collective allows the Stride collective to join a so-called 'Fiscal host' which takes care of all of that for us, for a percentage of the money contributed. After some communication and verification on the Stride github repository we are now also officially connected with the Open Source Collective. The Open Source Collective has various open source projects under its wing: WebPack, VueJs, OBS, Babel, Bootstrap and many more.

Payments and Expenses 🔗

Every payment made to a contributor will always show up on the Stride's open collective. A Stride contributor can submit an invoice: for instance the cost of Google accounts or domain names. These invoices can be approved by the Stride contributors team. These are the same people that are active members of the Stride Contributors team on Github. Submitted invoices can be approved at any given time but allocating money for specific projects is done at the end of each month (or beginning).

Projects 🔗

The Stride contributors have the final call where all the collected money will be allocated too. This will be done with the help of Projects. This Open Collective feature acts as a sort of 'Ledger' where money can be stored until the time comes to pay the contributor(s) of a project. A project can have its own tiers and goals. Those projects could be all sorts of things: new engine features, research on new technology, high priority bugs or documentation. These kinds of projects will be discussed at community meetings to get the input of the Stride community. Here is an example project.

People can also choose to donate to a specific project rather than the Stride collective in general if they want to. So if you only want to see your money being used for a specific cause, you are completely free to do so. You are more than welcome to do both of course. In the image below you can see an example of how money that has been donated to the Stride collective, has been partially allocated to a specific project.

What's Next? 🔗

We first want to see how this first month of the new platform goes. At the end of November/beginning December we will hold a new community meeting and we will discuss how things went and how we plan on distributing the donations.

There are also some remaining tasks regarding the Open Collective that will be taken care of in the weeks to come:

Setup webhook to Discord
Setup webhook to Twitter
Fully automate the website to show sponsors
Fully automate the Github backers.md file with sponsors
Write up blog on the entire process on how we spend money
Add open collective to sponsors.yaml on github

Community Meeting October 2021

Fri, 01 Oct 2021 00:00:00 +0000

It has been quite a while since we had a community meeting with the Stride community. On the 1st of October 2021 we had a good 2 hour chat about various topics on the Stride game engine.

Summary 🔗

Access Rights 🔗

First topic was about clearing up access rights of the Stride source contributors and how this can be displayed better to the rest of the world.

Github features a teams option, which is now free for open source projects. Xen2 made sure that those contributing to the engine are now part of the team on Github: https://github.com/orgs/stride3d/teams/stride-contributors. These contributors can review and approve pull requests in to the various stride projects (engine, website, documentation).
- When changes are merged into the website project and specifically the 'release' branch, an automated process will trigger the website deployment.
- Documentation is updated as well, although this is a manual process that needs to be triggered. Xen2 and Aggror will do some knowledge sharing in private, so that this process does not lie solely with xen2.
Social media access
- Youtube: xen2 and Aggror
- Facebook: xen2 and M0TH
- Twitter: xen2 and Aggror

Roadmap 🔗

The roadmap on Github hasn't received an update in quite a while. The reason for this is that there simply is no capacity to pick up these kind of features like terrain editor, visual programming etc.
What we see in the community is that various contributors work on useful features for their own games, and as a result these kind of features and bug fixes and up being merged in to the Stride repository.

As a result it has now been decided that we no longer will use the roadmap on Github. At the moment of writing this blog, the roadmap has already been removed. If, in the future, we have more funding and capacity, we can re-introduce it again.
Aggror will try to put out a blogpost once a month keeping the community up to date on features that community members are working on. This also requires some initiative from the community. So if you have something that you are working on, feel free to send a message to Aggror on Discord. That we can feature your screenshots, videos, PR's in a blogpost on the stride website.

Funding 🔗

There were 2 ways to contribute to Stride financially: Patreon and Xen2 sponsorship on his Github account.

Both these donation services didn’t really give a clear overview where the money was being spent on.
Sponsoring Xen2 on Github would specifically and only go to Xen2. On top of that there is no easy way to use this as a marketing tool.
Only Xen2 had access to Patreon, making it another responsibility for him to:
- Post something interesting on Patreon (for which he has no time)
- Do tax related activities and payments.
Because of the above, Stride's Patreon page will soon close (or already might be at the time of posting blog)
Aggror will look into setting up a more open way of viewing where money from donations is being spent on. The idea here is to have a look at Open Collective
- Aggror will present his findings to xen2. Once a decision has been made, the community will be informed.
.NET foundation
- Stride has joined the .NET foundation. The .NET foundation offers to host various services on their Azure subscriptions. That means that a majority of the costs when it comes to hosting is taken care of for us.
- As a result of this, Xen will move various services from Digital ocean to Azure. This will reduce costs. Money that is gained from donations can be spent on bug bounties, features and documentation. Once we have a new donation mechanism in place, we will have another community meeting on how to distribute money.
- Aggror will also be included in the communication with .Net foundation.
Xen2 gave a nice summary on the operating costs for various (web related)services
- Azure: used to be $50~$100 per month but now paid by .NET Foundation
- StackPath (CDN): $10 per month, can be moved to Azure
- Google Cloud Service: $5 per month
- DigitalOcean: $30 per month (teamcity and forums server), can be moved to Azure
- GitHub: $40 per month
  - Some demo's use LFS. If .NET foundation were to cover those costs too, we could add additional demo's.
- SSL: used to be expensive but now free (auto renew let's encrypt or Azure)
- Domains: cheap, $10 per year
Applying for a grant with Epic, Microsoft etc.
- Although this is something that we want to pursue, we first want to have a new donation service in place. The next community meeting will cover this topic again.

Stride 4.1 🔗

Stride 4.1 is on its way, but when exactly and what can we expect this year?

Stride 4.1 BETA will include the upgrade to .NET 6
Stride 4.1 targeted around november/december 2021
Although full Linux support is not possible right now, we will look at having the Linux runtime working again with Stride 4.1
Aggror will start collect info for the release notes

Remaining Topics 🔗

For the remaining topics, we ran out of time, so these will be picked up at another community meeting.

Stride 4.0 is Now Live

Mon, 01 Feb 2021 00:00:00 +0000

Stride 4.0 is now out of beta, and the Xenko game engine has been renamed to Stride. This release brings Voxel Cone Tracing GI, .NET 5 support, flexible GPU instancing, Vulkan improvements, and new documentation and tutorials. The Stride team is also welcoming new developers to contribute to the engine's development.

Stride 4.0 has been around for a while, but it's now time to remove the -beta tag!

Many thanks to the community and all the contributors who made this release possible!

Summary 🔗

Xenko is now Stride! 🔗

The Xenko game engine has been renamed to Stride. From now on, all source code, blogs, and tutorials will use the name ‘Stride’ instead of ‘Xenko’.

Here is the new logo:

More details available on the dedicated blog post.

Voxel Cone Tracing GI 🔗

Thanks to a substantial contribution from Sean Boettger and sponsored by David Jeske, Stride now supports Voxel Cone Tracing GI!

Here it is in action:

As you can see, there are many customizations and settings available in the editor:

There's a documentation page explaining how to set up the project with Voxel Cone Tracing GI.

Here's the original forum post and pull request. Thanks again for this great contribution!

.NET 5 🔗

Stride editor and toolchain is now running with .NET 5! Runtime has been working with .NET Core for a few versions already.

This allows us to have scripts and custom assets in a project targetting .NET Standard 2.1 or .NET 5.

If you have scripts or custom assets in a .NET Framework project rather than a .NET Standard project, you can still choose between .NET 5 and .NET Framework within the launcher:

The framework will also be displayed in the Game Studio toolbar for easier identification while both coexist.

.NET Framework version can be considered deprecated and will likely be removed in a future release (likely 4.1) to allow us to take full advantage of C# 8.0 and soon-to-come C# 9.0.

We also expect dropping .NET Framework and supporting only .NET 5 will greatly simplify our installation process since we won't depend on specific workloads or packages of Visual Studio being installed anymore. This was a recurring issue with our users.

Flexible GPU Instancing 🔗

Aka geometry instancing. Thanks to another big community contribution sponsored by vvvv, Stride now supports GPU instancing per model.

The nice thing about it is, that it plays together with the entity-component system: Simply add an Instancing component to an entity with a model. Then you can choose between 3 ways of how you generate the instances:

EntityTransform, uses the transformation of other entities with an Instance component. This allows you to add components like physics, audio, etc. to each instance.
UserArray, for providing an array of matrices via script
UserBuffer, for providing a structured buffer (GPU resource) of matrices via script

UserArray and UserBuffer even allow you to specify how the matrix is multiplied with the parent transformation.

It even works with skinning:

Picking individual instances in Game Studio works as well and selects the entity with the respective Instance component.

There are also two new entity templates for easy setup:

An example project that shows the new features can be found here: StrideTransformationInstancing

Graphics API: Different Selection Mechanism + Vulkan Improvements 🔗

There's been a big overhaul on Stride build system to make Graphics API selection work in a more future-proof way.

It was previously relying on the custom RuntimeIdentifier being set in the solution. This didn't work very well because it was completely orthogonal to the existing RuntimeIdentifier, and sometimes not having good fallbacks.

From now on, the user project will use StrideGraphicsApi in the .csproj project file to specify the graphics API. We hope to expose this in the editor later.

We also took the opportunity to improve the state of Vulkan renderer (thanks to a switch to Vortice.Vulkan bindings from Amer Koleci) and automatize graphics unit tests, currently running for D3D11 and Vulkan.

It's still a work in progress so expect more in future releases.

Documentation & Tutorials 🔗

The first 10 C# beginner tutorials are recorded and uploaded to the official Stride Youtube channel. You check out the playlist here.

These videos are the video equivalent of the existing online documentation for the C# beginner template tutorials and the 'new project' template when creating a new project from the Stride launcher.

The C# beginner series should be fully recorded by the end of July 2020.
After those videos are done, Jorn will put his focus on the C# Intermediate project template. Here a is work in progress screenshot on the raycasting tutorial:

New Developers are Welcome! 🔗

The Stride GitHub repository has more closed pull requests than open issues. This is a good sign! But in order to move faster and adapt to new technologies, we would be very happy to see more new talents in our friendly and professional developer community.

There are several good reasons to join us:

Writing engine code in C# is fun and quite productive
Stride users will work with what you create
We are happy to help, should you get stuck
You can learn a lot, the Stride code base is very professional and has high-quality standards
An open-source contribution is a great addition to your portfolio

No matter whether you (or someone you know) can contribute documentation updates, UI improvements, bug fixes, or new rendering technologies, we welcome everyone!

VL.Stride Released by vvvv

Fri, 02 Oct 2020 00:00:00 +0000

We're excited to announce that vvvv has released a new 3D engine for vvvv, our visual live-programming environment for .NET. Named "VL.Stride," it is essentially a wrapper around the Stride engine and can be used independently from the Stride Game Studio.

Read more about the release and its details in this release blog post.

Note that vvvv's focus is not on creating games but rather on creative coding and interaction design style of applications. But due to its live-programming nature, using a state hot-reload approach, it may still be interesting for you to quickly prototype some functionality for your games. Also vvvv can help you explore all the different parts of the Stride engine and understand how they work together. Being able to touch all parts while they are running, allows to get an overview faster than just going through Stride's documentation.

We'd like to invite you to play with it and hear your feedback. vvvv is free for non-commercial use, no strings attached. So please just go ahead, download vvvv gamma 2020.3-preview and let us know what you think!

NODE20 🔗

If you're already convinced and want to learn more about vvvv, join us for 30 online workshops covering various topics, we're running during the NODE20 - Forum for Digital Arts from October 3rd to 8th.

To give you an idea, the following workshops will be using VL.Stride:

As you can see, with vvvv we're quite invested in Stride. We bow before everyone who helped to make it what it is today and want to do our best to contribute our share to give it a bright future.

Yours, vvvv.

Community Meeting May 2020

Fri, 08 May 2020 00:00:00 +0000

On May the 8th we held another community meeting in the Discord. Its main goal was to talk about the ongoing work on Stride and its first official release after the rename to Stride.

Summary 🔗

Official Stride 4.0 release. The plan is to release Stride 4.0 officially within the next 2 weeks. It depends a little on whether .Net 3.1 is going to be part of it. If this can be done within reasonable time than we rather incorporate this into the official release of 4.0
- The release notes will be written in a more friendly way.
- Aggror will look into making a video regarding the release as well as some of the new key features like VXGI cone tracing.
Xen2 has filled in the application for joining the .NET Foundation, a non-profit organization (NPO). At the moment of writing this blog, no response to this yet.
Roadmap The GitHub roadmap will be updated. From now on it will only contain features that Xen2 or others will actively work on. This means some epics will be removed from the roadmap, and some new ones will be added. The epics that are removed will still be visible as requests in Github issues.
There is now a stride tag on gamedev.stackexchange (tag might be changed to stride-engine soon btw). We can use this site for Q&A and additional "How to? questions. https://gamedev.stackexchange.com/questions/tagged/stride
Documentation
- Recording of C# beginner video tutorials is ongoing. Videos are listed on the official Stride Youtube account. Basically, every page will have an accompanying video. The playlist is being updated on the go.
- Started making the C# intermediate tutorial section.
- Continuation of the editor video tutorials once the programming tutorials are up to speed again.
Some people showed interest in working on a community showcase demo for Stride. A new discord channel #showcasing-team was created.

VVVV and VL.Stride 🔗

User Tebjan explained some more about VVVV and VL.Stride.

Here is a short overview of what we at vvvv are doing and will release somewhen this year:

What is vvvv gamma?

vvvv gamma is a live programming environment for .NET
VL is our visual programming language that works with every .NET assembly
Development, compilation and state hot-reload at runtime, we believe this is the future of software development
You can see the data while you develop
Can export .NET executables
More info and download at: visualprogramming.net

What is VL.Stride?

Stride will be our 3d rendering library of choice
We are working on making the Stride features available as convenient nodes in vvvv gamma
High-Level nodes for: Mainloop, Windowing, Scene Graph, Materials, Models, Textures, etc.
Low-Level nodes for: Drawing API, Visual Shaders, Vector Math, etc.
Load a Stride project at runtime and use all content of it
You can see dev captures at: vl-xenko-3d-engine-update-3

We actively support the Stride open-source community and financially support the Stride development: vvvv-meets-xenko

Sponsoring and gold members 🔗

We welcome our new gold sponsor David Jeske. We would also like to thank him for contributing the work on VXGI last year. He is using Stride for one of his projects.

OUTDATED: As off November 2021, we will use Open collective.

Also, a friendly reminder, that if you sponsor Stride through Github, the reward is doubled by Github.

~~You can also still sponsor through Patreon~~.

Links 🔗

In case you missed them, here are the new links that you should be using:

Github: https://github.com/stride3d/stride
Website: https://stride3d.net/
Documentation: https://doc.stride3d.net/latest/en/manual/
Twitter: https://twitter.com/stridedotnet
Youtube: https://www.youtube.com/@Stride3D

If you have any further questions, feel free to reach out on Discord or the forum.

Xenko Has Been Renamed to Stride

Mon, 20 Apr 2020 00:00:00 +0000

The Xenko game engine has been renamed to Stride. From now on, all source code, blogs and tutorials will use the name 'Stride' instead of 'Xenko'.

Why the name change? 🔗

Changing product names always is a lot of work and comes with some downsides. However, we would not do this if there weren't any good reasons for us to do so. Since 2019, xen2, has been trying to affiliate Xenko with the .NET Foundation, a non-profit organization (NPO).

There are various reasons for this:

We wanted to let the community know that Xenko is completely and 100% free and open in its development. This also means that any donations should always be made 100% visible to the public. This also includes what and where the donation money is spent on. Joining the .NET Foundation would aid in visualizing how this money would be spent.
Being able to tell possible investors/backers/companies that Xenko/Stride can be trusted. This can help with publicity and more funding.
They also provide help for opensource projects in various areas.

This sounded great, but unfortunately, there was a massive drawback to this: as long as the project kept the name 'Xenko' (trademarked by Silicon Studio), it would be difficult to transfer to the .NET Foundation. After a lot of back and forth between Silicon Studio legal department, xen2 and the .NET Foundation, we didn't get any step closer to achieving our goals.

After several months without progress, we started to suggest the idea of a rename to the community. In the Discord server, we opened up the name change and logo suggestions to see how people would react and what their suggestions would be.

About 6 months later, several polls, logo proposal and a lot of brainstorming, we settled for the name: Stride.

New Stride Logo 🔗

The new Stride logo, designed by sebl (from schnellebuntebilder), was chosen after a process managed by Eideren consisting of several community votes. Also, tebjan is the one that came up with the name Stride. Many thanks to them, as well as to all the other people involved!

Without further ado, here it is:

Game Studio will use a red variant:

What does this mean for you? 🔗

The Xenko launcher will ask to install Stride launcher.
Stride will be available starting from version 4.0 (available shortly). This rename also applies to all websites, social media and documentation. It is possible that the name Xenko or its logo might still be drifting around somewhere in a screenshot here and there, but those will eventually be removed.
Stride 4.0 can opens Xenko 3.1 projects and convert them automatically. Please don't forget to properly backup your projects, and report any issues you have during the automatic upgrade process.

What's next? 🔗

Release Stride 4.0 within the next few days
A new application to join the .NET Foundation
A new effort to find new backers
The new Youtube channel will be the new hub for video tutorials. We will start with recording videos for the C# beginner section. After that, we will look at new editor video tutorials and extend the C# tutorials.

Here are the new links that you should be using:

Github: https://github.com/stride3d/stride
Website: https://stride3d.net/
Documentation: https://doc.stride3d.net/latest/en/manual/
Twitter: https://twitter.com/stridedotnet
Youtube: https://www.youtube.com/@Stride3D

Final Notes 🔗

We would like to thank each and everyone involved in the long process of picking a new name, a new logo and other related media/art. A huge shoutout to xen2 for doing the renaming process.

Recap January 2020

Mon, 03 Feb 2020 00:00:00 +0000

Stride is changing its logo due to similarity concerns with substance/adobe's logo. The community is invited to submit new designs for the Stride logo. Meanwhile, the 3.2 release is approaching, and the engine's rename to Stride will follow. Check out the community projects BanditRevolver and AggrorJorn for inspiration.

A New Logo for Stride 🔗

We decided to contact substance/adobe at the start of January after seeing that many people felt that the most voted community logo for Stride was too close to theirs. We received a reply from their legal team which, of course, told us that we would need to change it. It's the legal team, playing it safe is part of their job. They also told us that we could get in touch with their design team, we took that opportunity and sent multiple emails but they never got back to us.

Proposals are open again so if you think you have a logo that would fit with our new name (Stride), please fill in the picture attached below with your design. There’s also the Figma project 6 if you would rather work on that. For more information see the forum post.

3.2 Release 🔗

We are getting close to the 3.2 release. We hope to share some info on that soon. In the mean time we are also getting ready for the rename to Stride. This will happen after the 3.2 release.

Community Picks 🔗

Check out these community projects that people are working on: BanditRevolver and AggrorJorn.

Project Draco from BanditRevolver 🔗

Rollerghoaster from AggrorJorn 🔗

Recap December 2019

Tue, 31 Dec 2019 00:00:00 +0000

Happy new year everybody. In this blog we do a quick recap of the final developments of Xenko in 2019 and what the community has been up to.

What is being worked on? 🔗

The latest new features are being finished for the release of 3.2. This version should be released near the end of January.

Community Meeting 3 🔗

On December 18th we held another community meeting. Check here for the summary. The most important thing here is that we are getting ready for the rename.

Stride Logo 🔗

With 'Stride' being the new name for Xenko in the near future, the #logo-change Discord channel has been seeing a lot of suggestions and even a voting on some of the ideas from the community.

Community Picks 🔗

Check out these awesome projects that community members have been working on:

Testing Xenko by MentalArray 🔗

Testing the Xenko game engine took only a week to do this that included learning the scripting system and all model building and texturing was really trying to figure out animations and happy with result

Fog of war from Jarmo 🔗

This is a fog of war system written for Xenko.

Github project

Community Meeting December 2019

Wed, 18 Dec 2019 00:00:00 +0000

On December the 18th we held a community meeting in the Discord. Its main goal was to talk about the logo, roadmap and ongoing work on Stride.

Final Stride logo deadline: 22 december 2019
With the current amount of developers and resources, larger features like features are simply not possible. Features like cross-platform support, Visual studio Code, rebuilding the editor for Linux, Terrain and vegetation.
- If you have any programming skills and want to help out, have a look at the issues on github.
Roadmap 3.2 - Estimated by end of January 2020
- New feature: Url Reference
- New feature: HeightField property
- (optional) Debug Drawing
- (optional) LOD script
Roadmap 4.0
- This version will cover the rename of Xenko to Stride.
- Activating the first social media accounts.
- Joining the .NET foundation to become an NPO.
- Git/Patreon donations will have to be evaluated depending on NPO requirements.
- Contacting Microsoft/Partners for support/sponsorship.

Xenko 3.1 Released

Mon, 11 Nov 2019 00:00:00 +0000

It took some time to stabilize everything with the new Xenko packages, but we now feel confident enough to release Xenko 3.1!

Highlights 🔗

One of the major change is turning the engine into modular NuGet packages, published on NuGet.org.

Please note that Visual Studio 2017 is not supported anymore, please upgrade to 2019.

Community 🔗

Many thanks to the community and all the contributors who made this release possible: aggror, Eideren, alexb910, comradekingu, flabbie, CharlesWoodhill, Artaki, indigozero, dfkeenan, dominikjancik, erictuvesson, Hyperpred, louies0623, Lucifer2031, Ethereal77, mostafa901, Kryptos-FR, shinkitsunemaru, phr00t, Polymo, profan, xendez, Scorp-121, SleepyMode, tebjan, xen2, WhyPenguins, OoElectron, joreg, meriaizen86, rgawry, SantosSi, xwellingtonx, SilentCLD, HoSeCoin, Swann Martinet, WaldiS and pansan.

Xenko 3.1 Loves NuGet! 🔗

Xenko was always a big proponent of NuGet: since first version, Xenko was distributed as a NuGet package.

However, due to limitations (hello packages.config and project.json!), we were leveraging NuGet more as a distribution medium than proper NuGet packages: Xenko 3.0 is still a monolithic single package and it would not work out of the box when referenced from Visual Studio without using Xenko Launcher and Game Studio.

Xenko 3.0 paved the way by making Xenko compatible with the new project system (game projects were referencing Xenko using a PackageReference).

Today, Xenko 3.1 brings Xenko as a set of smaller NuGet package, each containing one assembly, with proper dependencies:

As a result, it is now possible to create a game project that references only the packages you want. Here are a few examples of "core" packages:

Xenko.Engine: allows you to use core engine runtime (including its dependencies)
Xenko.Core.Assets.CompilerApp: compile assets at build time
Xenko.Core.Mathematics or Xenko.Graphics: yes, if you want to make a custom project only using Xenko mathematics or graphics API without the full Xenko engine, you can!
Xenko.Core.Assets, Xenko.Presentation or Xenko.Quantum: all those piece of tech being used to build Xenko tooling are also available for reuse in other projects. Nothing prevents you from generating assets on the fly too!

Then, various parts of the engine are distributed as optional packages:

Xenko.Physics
Xenko.Particles
Xenko.UI
Xenko.SpriteStudio
Xenko.Video

If you don't reference those packages, they won't be packaged with your game either. In many situations, it will result in a smaller packaged game and improved startup time.

Also, you will be free to replace those functionalities with alternative libraries.

Package layout: following best NuGet practices 🔗

Previously Xenko references were added to the project using custom targets.

New packages are now be layout as NuGet/Visual Studio expects them, in folders like lib/net45 and lib/monodroid10.

We still have a few custom MSBuild targets but reduced them to minimum.

Xenko assets are also distributed as part of package 🔗

NuGet packages have a xenko folder containing Xenko assets. As a result, user are able to generate nuget package containing Xenko assets out of the box from Visual Studio and publish them on NuGet for general consumption.

Xenko Packages are now distributed on nuget.org 🔗

With all those changes, it makes sense to stop distributing Xenko on our custom nuget server and use nuget.org instead.

This will greatly reduce friction to try Xenko (any project would work out of the box in Visual Studio). This might also make our launcher completely optional in the long run.

Xenko tooling resolves assemblies dynamically using NuGet API 🔗

Tools such as GameStudio or Asset Compiler are distributed as NuGet packages. However, it won't bundle Xenko Runtime, which will simply be encoded as dependency.

When running those tools, they are resolving Xenko runtime assemblies directly in the NuGet cache.

This allows for distributing those tools as very small and easy-to-upgrade packages, avoiding file duplications. This is similar to what dotnet-cli is doing with deps file.

This brings lot of technical challenges but should allow us in the future to be more flexible in the future to load the exact runtime and plugins that the user project reference rather than the one hardcoded with the tool.

Future: plugin support for editor 🔗

Xenko 3.1 editor will still be monolithic: editor support for UI, SpriteStudio, Video and other optional modules will be hardcoded.

However, the target is to get rid of them as soon as possible, and treat them as what they are: plugins.

Full switch to .NET Standard 🔗

Xenko supports .NET Standard for most of its runtime assemblies.

Xenko games can run on .NET Core for both Windows and Linux.

Tutorials 🔗

Xenko now has a tutorial section in the documentation!

The first project “C# Beginner”, demonstrates 12 beginner programming concepts.

Users will be able to select the tutorial template when creating a new Xenko project to practice and experiment with the code.

Additionally, the code used in the project is directly referenced by the new documentation section which explains each individual tutorial level.

The amount of tutorials, as well as intermediate and advanced tutorials, will be extended/added from now on.

BulletSharp update 🔗

Eideren worked on updating our old custom modified version of BulletSharp (the wrapper library we use for our physics engine).

Things should be much easier to maintain from now on.

Changelog 🔗

This release also contains numerous improvements, bugfixes and new translations.

Here is the full changelog in all its glory:

Alex (1):

Fixed spelling error in Quaternion.cs view commit

Allan Nordhøy (9):

Added translation using Weblate (Norwegian Bokmål) view commit
Added translation using Weblate (Norwegian Bokmål) view commit
Added translation using Weblate (Norwegian Bokmål) view commit
Added translation using Weblate (Norwegian Bokmål) view commit
Translated using Weblate (Norwegian Bokmål) view commit
Translated using Weblate (Norwegian Bokmål) view commit
Translated using Weblate (Norwegian Bokmål) view commit
Translated using Weblate (Norwegian Bokmål) view commit
Translated using Weblate (Norwegian Bokmål) view commit

Andrea Aruta (6):

Added translation using Weblate (Italian) view commit
Added translation using Weblate (Italian) view commit
Added translation using Weblate (Italian) view commit
Translated using Weblate (Italian) view commit
Translated using Weblate (Italian) view commit
Translated using Weblate (Italian) view commit

Charles Woodhill (1):

[UI/INPUT] Expose mouseOverElement view commit

Christian Georgiev (2):

Added translation using Weblate (Macedonian) view commit
Translated using Weblate (Macedonian) view commit

Cody Lee (4):

Added issue templates for bugs and feature requests (#327) view commit
Moved pull_request_template.md to correct location view commit
Removed any pluralization of the word question in the question_request.md for consistency view commit
Updated CONTRIBUTING.md and added a 'submitting changes' section view commit

Daniel Keenan (2):

Change the ObjectToTypeName value converter to give prettier C# names. (#400) view commit
[GameStudio] Improve "Add component" button usability. (#411) view commit

Dominik Jančík (6):

Initial SDL Finger Multitouch support view commit
Removed lastCtrl field view commit
FingerSDL GUID view commit
FingerSDL PointerID generator view commit
Renamed FingerSDL to PointerSDL view commit
SDL Touch>Mouse synth. disabled when PointerSDL is used view commit

Eideren (55):

Include nuget to proj view commit
Straightforward changes view commit
Potentially harmful changes view commit
Minor proj update view commit
Matrix conversion fix view commit
Main conversion done, next up the rest of the CharacterComponent view commit
Character component, waiting on bullet wrapper for the rest view commit
Static mesh base view commit
Static Mesh: Update shape factories view commit
[Core] ThreadPool: shutdown idle threads (#302) view commit
[Samples] Misc camera controller fixes (#359) view commit
Fix for #422 view commit
Revert nugget view commit
[Bullet] Update libs view commit
[Bullet] Update projects mapping view commit
[Bullet] Remove bullet refs within mathematics view commit
Merge branch 'master' into bulletsharp_nuget view commit
[Bullet] Rely on our bullet for math conversions view commit
[Bullet] Finish height field mappings view commit
[Physics] Remove unused enum and previous namespace import for inlining view commit
[Bullet] Update all platforms to latest libs view commit
[Physics] Reduced physics test allocations (#443), cleaned up Simulation view commit
[Physics] Implement ignore collision between two specific components view commit
[Physics] In-editor static mesh collider view commit
[Physics] Avoid duplicate allocations for colliders based on models view commit
[Physics] Fix initial collider scaling view commit
[Misc] Exception prone basic functions view commit
[Transform] Deal with ChildrenCollection todo view commit
Merge branch 'master' into bulletsharp_nuget view commit
[Physics] Use asset cloner for shape desc view commit
Merge remote-tracking branch 'origin/master' into bulletsharp_nuget view commit
[Physics] Replace ColliderShapes' TrackingCollection view commit
[Physics] Replace Rigidbody's hacky delegate usage view commit
[Physics] Rollback unused serialization workaround view commit
[Physics] Cleanup RigidbodyComponent view commit
[Physics] Clarify comments in StaticMeshColliderShape view commit
[Physics] Fix #463 view commit
[Physics] Fix very large meshes throwing view commit
[Physics] Expose Capsule's readonly data view commit
[Physics] Provide read access to collider shape's data view commit
[Physics] Split static mesh collider into new PR view commit
[Physics] Fix ShapeSweeps output view commit
[Physics] Provide public access to callbacks' recycle and buffer view commit
[Physics] Clarify bullet lib's usage and sources view commit
[Editor] Fix orbit editor camera stutter view commit
[Editor] Re-order code execution view commit
[SceneManagement] Assign Entity.sceneValue before firing events view commit
[Camera] Fix processor's cameraSlotsDirty not being reset after process view commit
[SceneManagement] Fix loop skipping items when collection is modified view commit
Avoid unnecessary alloc view commit
Deal with Add(), sub-optimal implementation view commit
[Threading] ThreadPool refactor, reduce allocation, fix wrong argument view commit
Move PooledDelegateHelper outside lock view commit
Swap task factory view commit
[GameSystems] Fix removing systems not clearing it from update and draw view commit

Eric Tuvesson (1):

Assets Compiler Support MSBuild Toolset Version 16.0 (#421) (fixes #420) view commit

Félix Dion-Robidoux (1):

Update BACKERS.md view commit

Hyperpred (1):

Remove cast to Game in AudioSystem (#472) view commit

Jarrett Robertson (1):

Fixed issue with scene instance using the wrong collection in for loop count view commit

Louies (10):

Added translation using Weblate (Chinese (Traditional)) view commit
Added translation using Weblate (Chinese (Traditional)) view commit
Added translation using Weblate (Chinese (Traditional)) view commit
Added translation using Weblate (Chinese (Traditional)) view commit
Translated using Weblate (Chinese (Traditional)) view commit
Translated using Weblate (Chinese (Traditional)) view commit
Translated using Weblate (Chinese (Traditional)) view commit
Translated using Weblate (Chinese (Traditional)) view commit
Translated using Weblate (Chinese (Traditional)) view commit
Translated using Weblate (Chinese (Traditional)) view commit

Lucifer (8):

Added translation using Weblate (Chinese (Simplified)) view commit
Added translation using Weblate (Chinese (Simplified)) view commit
Added translation using Weblate (Chinese (Simplified)) view commit
Added translation using Weblate (Chinese (Simplified)) view commit
Translated using Weblate (Chinese (Simplified)) view commit
Translated using Weblate (Chinese (Simplified)) view commit
Translated using Weblate (Chinese (Simplified)) view commit
Translated using Weblate (Chinese (Simplified)) view commit

Mario Guerra (10):

Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit

Moustafa khalil (1):

Update README.md view commit

Nicolas Musset (10):

[Localization] Update extraction script view commit
[Localization] Update extracted strings view commit
[Localization] Update Japanese view commit
[Localization] Add French view commit
[Build] Update solution and project view commit
[Localization] Fix build for path containing spaces (#381) view commit
[Presentation] Bugfix/int3 editor (#387) (fixes #383) view commit
[General] Simplify editor and presentation project files view commit
[General] Fixup rule for .xaml.cs files view commit
Update .gitattributes view commit

Oscar Sanchez (9):

Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit

Phr00t (2):

[Graphics] Vulkan: add support for R10G10B10A2_UNorm and R11G11B10_Float view commit
[Input] Fix mouse VirtualButtons view commit

Polymo (1):

Translated using Weblate (German) view commit

Robin Hübner (2):

[Physics] correct userdoc for convex hull collider parameters. (#382) (fixes #372) view commit
Make SDL window user resizable. view commit

Rui Mendes (3):

Added translation using Weblate (Portuguese) view commit
Added translation using Weblate (Portuguese (Brazil)) view commit
Translated using Weblate (Portuguese) view commit

Scorp-121 (4):

Added translation using Weblate (Russian) view commit
Added translation using Weblate (Russian) view commit
Added translation using Weblate (Russian) view commit
Added translation using Weblate (Russian) view commit

Scorp121 (10):

Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit
Translated using Weblate (Russian) view commit

SleepyMode (1):

[Mathematics] Fixes for Color/ColorRGBA float/byte mismatches (#258) (fixes #251) view commit

Swann Martinet (2):

Translated using Weblate (French) view commit
Translated using Weblate (French) view commit

Tebjan Halm (6):

Quick fix as suggested by @xen2 in chat to avoid crash in shader compiler (#343) view commit
Added translation using Weblate (German) view commit
Translated using Weblate (German) view commit
Resetting shader key scope for multi pass materials (#456) view commit
added xenko-community-project to README.md (#514) view commit
Fix DataBaseFileProvider cast (#538) view commit

Virgile Bello (510):

[Design] VisualStudio.Project doesn't need a reference to Solution anymore view commit
[Assets] Package can now also represent a csproj + package (only new game creation is working) view commit
[Assets] Removed AssetItem.SourceProject view commit
[Assets] Move assets to Assets folder for now view commit
[Assets] Fix project loading view commit
[Assets] Simplified Package.Profiles into Package.Profile view commit
[Assets] Removed PackageProfile.ProjectReferences view commit
[Assets] Removed PackageProfile.Name view commit
[Assets] Allow creation of samples (as long as they don't use external packages) view commit
[Assets] Added the concept of Package container (project or standalone) view commit
[Assets] Turned Session.Packages into a readonly collection view commit
[Assets] Properly process dependency graph using remote info to perform package upgrades before downloading nuget packages view commit
[Assets] Removed LocalDependencies and fixed TemplateSampleGenerator view commit
[Assets] Fix platform update view commit
[Assets] AssetCompiler now works against .csproj view commit
[Assets] Fixed asset compiler get-graphics-platform view commit
[Assets] Fix view models to allow selection as current project view commit
[Assets] Properly regenerate platforms for sample templates view commit
[Assets] Ignore assets from executable projects (computed automatically) view commit
[Templates] Moved template packs assets from Assets/Shared to Assets view commit
[Assets] NewGameTemplateGenerator: assets were loaded twice, resulting in issues later with cloned AssetItem (fix asset packs) view commit
[Templates] Simplify platform projects view commit
[Templates] Moved templates packges asset folders from Assets/Shared to Assets and removed intermediate solution folders view commit
[Assets] Adjust PackageProfile.ResourceFolders during package upgrade view commit
[Templates] Sample Templates now works (asset packs are now ProjectReference and their assets are properly copied during template generation) view commit
[Assets] Properly get namespace from project view commit
[Assets] Fix CodeViewModel to use ProjectCodeViewModel view commit
[Assets] Fix platform updates view commit
[Assets] Rearranged templates for the new xkpkg = csproj change (note: project delete is broken) view commit
[Assets] Package.Profile is now properly deserialized by discarding default value view commit
[Assets] Removed PackageProfile.Platform view commit
[Build] Make sure Package.Id stays is in sync with .sln one view commit
[Assets] Removed Package.Id view commit
[Assets] Removed PackageProfile view commit
[Assets] Stop adding default folders in Package ctor view commit
[Assets] Reunified ProjectState and PackageState view commit
[Assets] Moved Package.Save() to PackageContainer.Save() view commit
[Assets] Avoid creating .xkpkg for projects without one in the first place (use implicit one instead) view commit
[Assets] Rework package dependencies view commit
[Assets] Also support loading sln with new csproj Guid view commit
[Assets] Support Packing and consuming simple NuGet packages with Xenko assets view commit
[Assets] New game template: set current project to Windows view commit
[Assets] Simplified NuGet package restore (only happens during PreLoadPackageDependencies) view commit
[Assets] Update Code library template to match others view commit
[Targets] Stop using XenkoDir.cache file during build view commit
[Build] Bump to 3.1.0.1 view commit
[Assets] Store pendingPackageUpgrades in PackageSession view commit
Merge remote-tracking branch 'origin/master' into onecsproj_onexkpkg2 view commit
Merge branch 'master' into onecsproj_onexkpkg2 view commit
[Assets] Process dependencies for RootAssets in view model view commit
[Assets] Made !file and !directory tags mandatory in Yaml for easier dependency analysis view commit
[Assets] Temporary fixes for root assets and default scene opening view commit
[Assets] Pack assets using actual package data rather than hardcoded rules view commit
[Build] Reorganize build system (WIP) view commit
[Build] NuGetAssemblyResolver WIP view commit
[Engine] Move default assets to individual assemblies rather than global Xenko.xkpkg view commit
[Assets] Compiler: can now properly compile existing projects view commit
[Launcher] Fix launcher build view commit
[Editor] Temporarily moved game studio shaders to Engine, until we have proper design-time package references view commit
Merge branch 'master-3.0' into onecsproj_onexkpkg2 view commit
[Build] Use RuntimeIdentifier to separate graphics API runtimes view commit
[Build] Improved cross compilation view commit
[Build] Renamed XenkoRuntime into XenkoNETRuntime view commit
[Build] Added XenkoRuntime flag view commit
[Assets] project.Type evaluation needs to be done after package are restored view commit
[Assets] Reorganized templates view commit
[Assets] Fix package upgrader view commit
[SpriteStudio] Added templates view commit
[Assets] Properly find ffmpeg.exe and msdfgen.exe view commit
[Assets] Move VHACD to Assets assembly and properly bundle C# wrapper view commit
[Assets] Compiler: use thread-safe version of NuGet (when writing lock file) view commit
[Deps] Switched to NuGet version of Xceed.Wpf.Toolkit/Datagrid/AvalonDock view commit
[Build] Bump to .NET 4.7.2 view commit
[Build] Adjust bindings for System libraries with 4.7.2 changes view commit
[Deps] Xenko.Metrics and Xenko.CrashReport are now packaged with NuGet view commit
[Build] Lot of adjustments for new NuGet resolver system (incl ConnectionRouter, VS Package, etc...) view commit
[Samples] Moved samples from Xenko.Assets.Presentation to a dedicated project to have faster rebuild view commit
[Assets] Some improvements so that unit tests can compile view commit
[Assets] Some improvements so that unit tests can compile view commit
[Build] Removed XenkoDir environment variable view commit
[Assets] Fixed templates to have proper assembly names and namespaces view commit
[Build] Readded support for UWP view commit
[Build] Readded support for Android view commit
[Build] Readded support for iOS view commit
[Build] Optimized ProjectReferences view commit
[Build] Check Visual C++ Runtime is properly installed as part of build targets view commit
[Build] Added Xenko.PackageInstaller to Xenko.GameStudio view commit
[Build] Use "XenkoPlatforms" to specify which platforms to build view commit
[NuGet] Upgrade to 4.9 and use RestoreRunner to have faster noop restore on second run view commit
[Tests] Fix build of some test projects view commit
[Build] Also deletes .nupkg.metadata on package auto deploy (https://github.com/NuGet/Home/wiki/Nupkg-Metadata-File) view commit
[Build] Make sure user projects are always built so that compiler app is checking assets again (until we feed "fast up to date" with proper inputs/outputs) view commit
[Assets] Make sure to explicitly include Xenko.Core for its targets until VS2019 enables it by default (https://github.com/NuGet/Home/issues/6091[#](https://github.com/xenko3d/xenko/issues/)issuecomment-438073285) view commit
[Assets] Don't include package targets when evaluating project files view commit
[Assets] Order windows executable project first in solution files (sln) so that VS uses them as startup project by default view commit
[Build] Added some docs related to new build system view commit
Merge remote-tracking branch 'origin/master' into onecsproj_onexkpkg2 view commit
[Build] Fix iOS solution view commit
[Build] Moved PackAssets task in Xenko.Core.Tasks view commit
[Build] Use PackAssets as an exe rather than a Tasks so that MSBuild doesn't lock the files (annoying when rebuilding) view commit
[NuGet] Log everything view commit
[NuGet] Restore inside assembly resolver to avoid deadlock and rewrote logging code view commit
[Build] Only build default graphics platform when opeining sln unless we explicitly set XenkoGraphicsApiDependentBuildAll view commit
[NuGet] Perform nuget resolve only for entry assembly view commit
[Assets] Better resolution of project platform (needed so that windows project is auto selected) view commit
[Build] Fix build when choosing a single graphics API view commit
[NuGet] Add dev store before trying to restore packets view commit
[Build] Removed Xenko.xkpkg view commit
[Build] Moved PackageUpdateVersionTask to a separate assembly to simplify build view commit
[Build] Unify version management in a single file (except for samples which will be versioned separately) view commit
Merge remote-tracking branch 'origin/master-3.0' view commit
[Build] Added package details view commit
[Build] Output nupkg in bin\packages view commit
[Build] Xenko.Samples.Templates: add missing dependency view commit
[NuGet] If restore failed, try to kill known blocking processes (Connection Router, CompilerApp, etc...) view commit
[NuGet] Improve logging if restore failed view commit
[Build] Remove non-existing files from Xenko.sln view commit
[NuGet] Use SourceCacheContext to avoid ArgumentException view commit
[Build] Sign dll/exe when building package view commit
[Build] Also sign Launcher executables view commit
[Build] Escape/Unescape XenkoPlatforms for properly passing info from Xenko.build to targets view commit
[Build] Package build improvements view commit
[Build] Package build improvements (part 2) view commit
[Build] Signing tool was mistakently always enabled view commit
[Build] Package build improvements (part 3) view commit
[Setup] Update to Advanced Installer 15.5.1 view commit
[Build] Remove invalid character from Xenko.build view commit
[Build] Fix Linux Vulkan build view commit
[Build] Added bin/packages/.gitignore file view commit
[Build] Fix restore phase in Xenko.build view commit
[Build] Removed Xenko.SamplesBootstrapper and fixed Xenko.Samples.Tests view commit
[Samples] Fixed Xenko.Shaders.Tests view commit
[Build] Use active build configuration rather than forcing Debug view commit
[Build] Stop using Bin\Windows for unit tests view commit
[NuGet] Couldn't resolve EnvDTE.dll view commit
[Assets] Don't try to load vcxproj as package view commit
[Samples] PhysicsSample: Update for Vector3 Gravity view commit
[Tests] Xenko.Assets.Tests: Don't compile assets view commit
[Tests] Fixed some unit tests view commit
[Tests] Fixed folder for gold image view commit
[Launcher] Ignore server-side dev packages view commit
[Assets] Fixed TestBasicPackageCreateSaveLoad view commit
[Assets] Package upgrade is now working for 3.0 projects view commit
[NuGet] Update to NuGet 4.9.1 view commit
[Launcher] Ignore invalid NuGet sources (404, 401, etc...) view commit
[VSPackage] Fix build of test project view commit
[Launcher] Bump to 3.0.1 view commit
[Assets] User can now create GameSettings freely (need to display warning if nothing matching expected name?) view commit
[CompilerApp] Removed unused GetGraphicsPlatform code view commit
[Build] Removed obsolete target files view commit
[Build] Xenko.build now properly build Launcher view commit
[Build] Switching unit tests to new targets view commit
[VSPackage] Fix Xenko.build targets view commit
[Build] Clean packages before full package build view commit
[GameStudio] Asset editors close button is back view commit
[Graphics] Removed PreferredGraphicsPlatform from RenderingSettings view commit
[VSPackage] Fix build when using multiple XenkoPlatforms view commit
[Build] Adjust package versioning so that NuGetVersion doesn't contain build metadata view commit
[Native] Explicitly require related Assembly when loading native library (we can't use GetCallingAssembly as it might be wrong due to optimizations) view commit
[Native] PreloadLibrary: Use type rather than assembly (to avoid use of GetTypeInfo() everywhere) view commit
[GameStudio] About page: added markdown files to package view commit
[Launcher] Few fixes so that launcher properly separate view commit
[GameStudio] About page: display version with build metadata view commit
[Build] Force cross-targeting if there is multiple RuntimeIdentifiers view commit
[Launcher] Stay compatible with Xenko 1.x/2.x view commit
[Build] Properly fix how RuntimeIdentifier is used for multi graphics API per platform view commit
[Assets] Solution file was generated with empty DefaultVisualStudioVersion view commit
[OpenTK] Use win7 runtime rather than win view commit
[Assets] Made DefaultVisualStudioVersion public again view commit
[Build] Properly forward XenkoGraphicsApiDependentBuildAll view commit
[Build] Workaround: Remove RuntimeIdentifier from Solution references (https://github.com/onovotny/MSBuildSdkExtras/issues/139) view commit
[Assets] Make sure solution/project path use backslashes view commit
[Particles] Remove ambiguities in data member order view commit
[Assets] Keep solution folders, just remove package info view commit
[Assets] Improve package upgrade when there is no ProjectReference view commit
[Samples] Updated samples view commit
[Samples] Removed Xenko.Navigation where not needed view commit
[Samples] Removed Xenko.Physics where not needed view commit
[Assets] Make sure implicit packages have IsDirty set to false when loaded view commit
[Assets] Fix asset upgrade view commit
[GameStudio] Fixed template samples generator to work with updated project format view commit
[Samples] Updated with 3.1 (step 2) view commit
[Samples] Keep Xenko.Particles for now, until we have better extensibility in Graphics Compositor view commit
[Assets] Allow some assets to be non-referenceable (asset name collision is allowed in this case because they exist only at compile-time). This is used for scripts, otherwise they can't have same name as an asset. view commit
[Assets] PackAssets: skip excluded files view commit
[Settings] Remove the !file when serializing setting keys view commit
[Build] Package necessary WindowsAPICodePack assemblies with Xenko.Core.Presentation.Dialogs view commit
[Build] XenkoPlatform was not properly set for Linux platforms view commit
[Assets] PackageUpgrader: react to multiple package names (to support renames and/or package splits in multiple parts) view commit
[GameStudio] Improve default asset selection to match opened asset editors view commit
[Assets] Compiler: Move default asset build path to obj\xenko\assetbuild view commit
[Build] Changed dev/beta versioning to permit upgrading between interleaved dev and beta releases (betaXX.YYYY format with XX = asset version and YYYY = git height) view commit
[Build] Generate ref folder for all platforms (otherwise Android/iOS/UWP might fallback to ref/netstandard2.0 of Linux) view commit
[Build] Fix Android build due to lack of NuGetRuntimeIdentifier view commit
[Templates] Remove the _Game from sample templates view commit
[Build] Adjust PackageVersion for sample templates according to XenkoOfficialBuild rather than XenkoPackageBuild view commit
Updated BACKERS.md view commit
[Launcher] Display source in tooltip for Xenko downloads view commit
[VSPackage] Various fixes so that shader highlighting/goto works view commit
[Build] Updated UWP to use uap10.0.16299 view commit
[UWP] Simplified some code (can now use Thread and other newer API) view commit
[Build] Hide Microsoft.NETCore.UniversalWindowsPlatform from references and update build doc view commit
[Build] Fix Xenko.Shaders.Tests name view commit
[Assets] New Game template was not properly copying asset package files view commit
[GameStudio] Use same build folder for game studio as for actual game build view commit
[Templates] Fixed Linux template view commit
[Templates] Fixed UWP template view commit
[Build] Use win instead of win7 runtime identifier view commit
[Templates] Additional fix for Linux template view commit
[Templates] Linux: adjust default runtime identifier view commit
[Launcher] Various fixes for downloading and error reporting view commit
[Launcher] Bump to 3.0.4 (3.0.3 was built with incorrect source changes) view commit
[VSPackage] Fix NuGet assembly resolve (avoid infinite loop) and handle properly non-Xenko solutions (fixes #298) view commit
[Editor] Properly report solution load/save exception to log view commit
[Reflection] Rewrote part of AssemblyContainer to handle deferred loading view commit
[Build] Updated to MSBuild.Sdk.Extras version 1.6.65 (compatible with VS2019) view commit
[Build] Use $(RoslynTargetsPath) rather than $(MSBuildBinPath)\Roslyn (which doesn't work with VS2019) view commit
Change link+badge for chat from gitter to discord view commit
[Build] Use netstandard2.0 version of OpenTK view commit
[Build] Switch to netstandard2.0 wherever possible for the runtime view commit
[Build] Switch game projects to use netstandard2.0 view commit
[Build] Fix Windows+Linux build view commit
[Build] Hide Microsoft.NETCore.UniversalWindowsPlatform from references and update build doc view commit
[Build] Fixed build of RenderDocPlugin view commit
[Build] Additional fixes for single 3d graphics API build mode view commit
[Templates] Patching of TargetFramework section is now forcing netstandard2.0 view commit
[Templating] Switch to latest version of Mono.TextTemplating (t4) and add reference to netstandard view commit
[Build] Various fixes for .NET Standard build view commit
[Build] Bump Android SDK version from 5.0 to 8.1 (Google Play recent requirement for new app and .NET Standard 2.0 also requires 8.0+) view commit
[Build] Force references to be added only for direct and explicit package references view commit
[Build] Properly forward XenkoGraphicsApi when building a single graphics platform view commit
[Build] Make sure to override RuntimeIdentifiers on UWP otherwise it builds all CPU versions and result in write conflicts view commit
[Build] Use "any" instead of "win" view commit
[Build] Make sure "win" is the default when building a netstandard2.0 reference (to make sure a RID-specific project always use RID) view commit
[Build] Define output path (otherwise using a Platform might override them) view commit
[Build] Properly setup RuntimeIdentifier if it was not a Graphics-API-specific one view commit
[Build] Pack Xenko assets as part of NuGet packaging view commit
[Build] Fix the NuGet publish build file view commit
[Build] Removed unnecessary solution references view commit
[Build] Properly compute & restrict RuntimeIdentifier for ProjectReference view commit
[Build] Better detection of default RuntimeIdentifiers view commit
[Build] Fix RuntimeIdentifiers detection for graphics API mode view commit
[Build] Adjust RuntimeIdentifier and XenkoPlatform detection view commit
[Launcher] Remove custom Http code and decrease concurrency (which might be problematic since our packages are bigger than average) view commit
[Launcher] Switch from gitter to discord view commit
Updated BACKERS.md view commit
[Launcher] Bump to 3.0.5 view commit
Update Crowdin configuration file view commit
Update Crowdin configuration file view commit
[Launcher] Skip unlisted packages, and don't use cache view commit
[Launcher] Also use normal output data for error output of PackageInstall.exe view commit
[Physics] Enable PhysicsShapesRenderingService only if there is a IGraphicsDeviceService view commit
Update BACKERS.md view commit
Merge remote-tracking branch 'origin/master-3.0' view commit
[Physics] Add comment for PhysicsShapesRenderingService creation view commit
[Build] Added option XenkoPublishSkipSamplesTemplates view commit
[Build] Adjust platform detection (broken for multiplatform) and preparations for OSX view commit
[Build] Additional fixes for computing runtime identifiers view commit
[Build] Further fixes for computing runtime identifiers view commit
[Build] Run Visual C++ checks only on .NET Framework MSBuild view commit
[Build] Additional setup for macOS build view commit
Merge pull request #323 from Kryptos-FR/feature/l10n view commit
[Build] Native: Generate only x64 for macOS (.NET Core only supports x64) view commit
[Graphics] Update to SDL 2.0.9 view commit
[Graphics] SDL: Load from proper directory view commit
[Shaders] Added macOS glslangValidator view commit
[Shaders] Vulkan: Add "NoSampler" to reflection view commit
[Core.IO] Disable LockFile code from macOS (not supported) view commit
[Core] Copy native libs for more platforms, and only if CopyLocalLockFileAssemblies is not set to false view commit
[Build] macOS: Update NativePath to latest version view commit
[Graphics] Update SharpVulkan (works on OSX and easier to access NativeHandle) view commit
[Graphics] macOS: Added MoltenVK view commit
[GameStudio] Added project template for macOS view commit
[Localization] Use $(RoslynTargetsPath) rather than $(MSBuildBinPath)\Roslyn (which doesn't work with VS2019) view commit
[Samples] Templates: Added Cache to list of ignored folders (can be leftover from build during previous Xenko versions) view commit
[Graphics] macOS: Updated MoltenVK view commit
[Assets] PackAssets: Use proper asset path when computing resources relative paths (fixes #326) view commit
[VSPackage] Upgrade version to 3.0.3. Add support for VS2019. New release needed since RestoreHelper.cs was updated (fixes #324) view commit
Update license for 2019 view commit
Update BACKERS.md view commit
[Build] Copy .xml and .pdb from NuGet package references when using new csproj format view commit
[VSPackage] Run VSIX installer only for VS2017+ (fixes #332) view commit
[Build] Use latest version of Windows 10 SDK view commit
[Build] Update requirements view commit
[Build] Publish was not properly copying native libs and compiled assets (fixes #331 and #334) -- thanks to jazzay for the initial implementation view commit
[VSPackage] Make ProjectReference between Commands and Package private so that it doesn't exist as a NuGet dependency view commit
[VSPackage] Add TODO for restore log view commit
[Build] Native: use vcxproj directly to avoid TRK0005: Failed to locate: "link.exe" or "cl.exe" (fixes #337) view commit
[Build] Properly include install-prerequisites.exe next to Xenko.GameStudio packageinstall.exe view commit
[Install] Prerequisites installer: improve error reporting and retries (i.e. UAC not clicked) when installing Visual Studio or Build Tools view commit
[Install] Prerequisites: Update to VC++ 2017 prerequisites view commit
[Install] Prerequisites: Add ".NET Core 2.1 development tools" to list of Visual Studio prerequisites view commit
[Install] Prerequisites: Improve Visual Studio detection/update mechanism view commit
Update BACKERS.md view commit
[GameStudio] Switch to Roslyn 2.10 view commit
[Assets] PackAssets: properly copy RootAssets (fixes #347) view commit
[Assets] Perform null check before upgrading PackageProfile view commit
[Assets] PackageSession: Properly fallback to AssemblyName if PackageId is not set view commit
[Assets] Remove asset upgrader code for versions before 3.0 view commit
Explain how CLA is to be signed. view commit
Update BACKERS.md view commit
[Build] NuGetVersion reported to TeamCity was wrong view commit
[VR] Fix UWP build (#213) view commit
[Build] Add XenkoBuildDoc parameter to force TargetFramework even if not specified (seems necessary for older version of Roslyn used in docfx) view commit
[GameStudio] Add missing RoslynPad assemblies in the composition context view commit
[GameStudio] Allow drag & dropping of read-only assets (as long as they wouldn't be modified) view commit
[GameStudio] CodeLibrary projects were not properly initialized (assets couldn't be created) view commit
[Build] Sign packageinstall.exe view commit
[Build] Include RoslynPad assemblies with Xenko.Assets.Presentation package view commit
Update ContributorLicenseAgreement.md view commit
[Build] Unlocking C# 7.3! view commit
[Core.Design] AssemblyContainer: Process deps.json files (fixes #365, fixes #342) view commit
Merge branch 'master-3.0' view commit
[Physics] Fix ColliderShapeAsset upgraders (was previously enclosed in XENKO_SUPPORT_BETA_UPGRADE) view commit
Merge remote-tracking branch 'origin/master-3.0' view commit
Merge remote-tracking branch 'origin/master-3.0' view commit
[Build] Add option -NoSymbols to nuget push view commit
[Graphics] D3D: add support for using typeless textures view commit
[Reflection] AssemblyContainer: return already loaded assemblies if AssemblyName matches rather than loading new one (it seems that assembly is requested several times because we are not loading in the proper load context) view commit
[Build] runtime.json: fix spacing view commit
[Build] Added new CPU-specific variants to runtime.json (#370) view commit
[Build] Bumped LLVM to 7.0.1 view commit
[Render] Decouple RenderParticleEmitter from ECS view commit
[Render] Decouple RenderUIElement from ECS view commit
[Render] Decouple RenderMesh and others from ECS view commit
[Rendering] Remove various dependencies from lighting code to LightComponent view commit
[Rendering] Removed SceneInstance dependency from rendering code view commit
[Rendering] Removed dependency from VisibilityGroup to ShadowMapRenderView view commit
[Rendering] LightSkybox: Removed obsolete comment view commit
[Rendering] Moved RenderGroup class to Rendering namespace view commit
[Rendering] PostFX: remove dependency to CameraComponent view commit
[Rendering] ShadowMapRenderer: remove unused nested class view commit
[Rendering] ForceAspectRatioSceneRenderer: Made default aspect ratio local to remove dependency to CameraComponent view commit
[Engine] Moved IndexingDictionary to Xenko.Core view commit
[Rendering] EffectSystem: Remove dependency to Game class and move EffectCompilationMode in the same namespace view commit
[Rendering] EffectSystem: Moved CreateEffectCompiler in a separate static class outside of Rendering code view commit
[Rendering] Made ForwardLightingRenderFeature not dependent on LightProcessor anymore view commit
[Rendering] Made LightProbe code not dependent on LightProbeProcessor anymore view commit
[Rendering] Made LightShafts independent from LightShaftProcessor view commit
[Rendering] Fixed RenderContext.GetCurrentCamera() tag owner view commit
[Streaming] Removed dependency on Engine.Game view commit
[Rendering] Splitted most of low-level rendering code into a new Xenko.Rendering assembly view commit
[SpriteStudio] Fixes for SpriteStudio to work properly again view commit
[Rendering] Make Xenko.Rendering platform-specific view commit
[TextTemplating] T4: use a custom version of Mono.TextTemplating, including https://github.com/xen2/t4/commit/0d0b6db3ca3aba82fd7597951be2361265043e5e view commit
[Serializaton] Bump format version (Rendering split) view commit
[Build] Bump to beta02 view commit
[Build] Fix .usrdoc generation and copy (fixes #377) view commit
[NuGet] Remove deleted xenko sources during startup to avoid restore failures (fixes #338) view commit
Merge remote-tracking branch 'weblate/master' view commit
[Localization] Added Russian as a supported language view commit
[Localization] Added a few missing important translations (which were omitted for ApplicationCommands) view commit
[CrashReport] Bumped crash report to 1.0.1 (force HTTPS), anonymize reports and make sure it doesn't conflict with NuGetAssemblyResolver view commit
[Localization] Updated po files view commit
[Build] Regenerated sln (which were invalid since Xenko.Rendering was added) view commit
[Samples] Removed reference to RenderContext.SceneInstance (fixes #386) view commit
Merge remote-tracking branch 'weblate/master' view commit
Merge remote-tracking branch 'weblate/master' view commit
[Localization] Only generated when building Release, and added Russian in Xenko.Editor view commit
[Localization] Added support for German and Spanish view commit
[Localization] Rearranged targets so that localization code is unified view commit
Merge remote-tracking branch 'weblate/master' view commit
[Localization] Added support for Chinese (Simplified) view commit
[Setup] Don't delete top level installation folder if not empty (esp. if it was installed in a root folder containing other programs by mistake!) view commit
[Launcher] Use cache but always refresh it, even when installing. view commit
[Launcher] Set LauncherApp as default project view commit
[Launcher] Bump to 3.0.6 view commit
[Templates] Fix version in reference to Xenko.Samples.Templates package view commit
[Rendering] Add Sprite to rendering only if it's enabled view commit
[Rendering] Properly register Xenko.Rendering in AssemblyRegistry (fixes #409 and fixes #410) view commit
Update BACKERS.md view commit
Merge remote-tracking branch 'weblate/master' view commit
[GameStudio] Fast-reloading for types such as Material and Texture were not working as expected, forcing a full model reload on every edit view commit
[GameStudio] Fix for fast-reloading view commit
[GameStudio] Rewrote and simplified code for fast reloading (also support cases such as material layers properly now) view commit
[GameStudio] AvalonDock: Fix a bug in AvalonDock 3.4.0 which sets CanClose to false once a LayoutAnchorable is dragged into a new floating window or a new pane. view commit
[Physics] CleanContacts was working on previousFrameContacts rather than currentFrameContacts, resulting in warnings "Pair not present". Thanks @EternalTamago for the fix! (fixes #88) view commit
Update BACKERS.md view commit
[Graphics] D3D11: Begin/End were not reentrant because of how Query were used (#427 #428) view commit
Merge remote-tracking branch 'origin/master-3.0' view commit
[Audio] Encode little bit longer to compensate for encoding delay (fixes #350) view commit
[Build] Make sure _XenkoGenerateDependencies runs in all situations (otherwise unit tests won't work) view commit
[Build] Make sure _XenkoGenerateDependencies runs also for C++ projects view commit
[Build] Readjust _XenkoGenerateDependenciesAfterBuild target/comments view commit
[Build] Unit tests: use proper xunit.console.exe depending on x86 or x64 view commit
[Tests] Fix sample games unit tests view commit
[Samples] Fix Sprite Studio demo (missing reference to SpriteStudio runtime) view commit
[Editor] Preview View Model was not properly removing event handlers (fixes #438) view commit
[Launcher] Improve log/error message in an attempt to investigate #310 view commit
[NuGet] Switch to NuGet 5.0 view commit
[Build] Require VS2019 instead of VS2017 to take advantage of new NuGet buildTransitive feature view commit
[Build] Removed obsolete props files view commit
[Build] Update NuGet.exe to 5.0 view commit
[Build] Update build instructions view commit
[VSPackage] Update to new AsyncPackage and upgrade/cleanup unecessary PackageReference view commit
[Build] Bump MSBuild.Sdk.Extras to 2.0.24 view commit
Merge remote-tracking branch 'origin/master' into vs2019 view commit
[AssemblyProcessor] Fix a case where ImportReference was not called for GetTypeFromHandle(). Bumped Cecil to NuGet 0.10.3 rather than custom one. view commit
[Assets] Added a new KeepReferences flag to AssetCloner view commit
[Build] Stop detecting Android NDK version using folder name (latest VS2019 uses "ndk-build" folder name without version) view commit
[Build] VS2019 now understand WindowsTargetPlatformVersion being set to 10.0 rather than a specific version. Also bump PlatformToolset to v142 view commit
[Build] Converted some design-time libraries to .NET Standard 2.0 view commit
Revert "[AssemblyProcessor] Fix a case where ImportReference was not called for GetTypeFromHandle(). Bumped Cecil to NuGet 0.10.3 rather than custom one." view commit
[AssemblyProcessor] Fix a case where ImportReference was not called for GetTypeFromHandle(). view commit
[Assimp] Added error details if something went wrong (and test if scene is null to avoid NullReferenceException). view commit
Merge remote-tracking branch 'weblate/master' view commit
[Build] Reorganized targets to more easily choose multiple graphics platforms at once. view commit
[Build] Bumped sln to use VS2019+ view commit
Revert "[Build] Reorganized targets to more easily choose multiple graphics platforms at once." view commit
[Build] Reorganized targets to more easily choose multiple graphics platforms at once. view commit
[Build] Removed deprecated Android armeabi CPU architecture (fixes #461) view commit
[Vulkan] Back buffer: add missing ViewType parameter (2D) when creating back buffer view commit
[Build] Android: Bump TargetSdkVersion to API level 27 (matches VS2019 install and TargetFrameworkVersion set in csproj) view commit
[Launcher] NuGet: 1 hour timeout instead of 100 seconds as a workaround for https://github.com/NuGet/Home/issues/8120 (fixes #310) view commit
[Launcher] Bump to 3.0.8 view commit
Revert "[Assimp] Updated assimp to official 4.1.0 and updated references in projects (closes #458)" view commit
[Build] Removed armeabi libraries to completely fix #461 (fixes #470) view commit
[Build] Android: unify all minSdkVersion to 16 and targetSdkVersion to 27 (fixes #469) view commit
[VSPackage] Bump to 3.0.5 view commit
[Physics] Renamed NewShapeFromDesc to CreateShape view commit
[Launcher] Allow to select Xenko version view commit
[Build] Bumped Cecil to NuGet 0.10.4 rather than custom one. view commit
[Physics] Update README.md with new BulletSharpPInvoke repo location view commit
Merge pull request #289 from Eideren/bulletsharp_nuget view commit
[Physics] Fix typo in PhysicsEngineFlags.ContinuosCollisionDetection (fixes #152) view commit
[Build] Properly copy back IntDir/OutDir to IntermediateOutputPath/OutputPath for C++ project view commit
[Input] Fix SDL key mapping for 0 and 1 view commit
[Build] Updated editorconfig to contain VS2019 default style (which we use in Xenko) view commit
[Build] XenkoContent: do not include in NuGet package as Content view commit
[Graphics] Compare InputElements length before comparing elements view commit
[Graphics] Remove unecessary GraphicsDevice.ThreadCount view commit
[SDL] AppActivated and AppDeactivated were reverted view commit
[Vulkan] Fix validation for texture upload view commit
[Vulkan] Update glslang to 7.11.3214 (May 2019) view commit
[Vulkan] PipelineState: Entry point name could be GC before used view commit
[Vulkan] PipelineState: Properly set PrimitiveRestartEnable view commit
Revert "[Graphics] Vulkan: add support for R10G10B10A2_UNorm and R11G11B10_Float" view commit
[Vulkan] Fixed memory barriers for Clear functions view commit
[Vulkan] UpdateSubresource: Fixed memory barrier view commit
[Vulkan] Fixed mixup between Clear DSV and RT view commit
[Build] Android: Updated to NDK r19 (with proper version check) and remove our custom libc++abi (first step for #460 and #379) view commit
[Build] Android: Avoid "error MSB4044: The "FilterAssemblies" task was not given a value for the required parameter "DesignTimeBuild"." with latest Xamarin.Android view commit
[Audio] Android: Updated OpenSLES header (which were incompatible with arm64 due to SLuint32 mapping to long instead of int) (fixes #379) (fixes #460) view commit
[Setup] Upgraded Visual C++ prerequisites to latest VS2019 ones view commit
[Assimp] Properly copy Xenko.Assimp.*.dll (fixes #465) view commit
Merge remote-tracking branch 'weblate/master' view commit
[Build] Android: Workaround for https://github.com/onovotny/MSBuildSdkExtras/issues/174 view commit
[Build] Transformed Xenko.Core.BuildEngine into a .NET Standard assembly view commit
[Build] NETStandard: Switch from AssemblyBuilder.DefineDynamicAssembly view commit
[Build] NETStandard: Remove unnecessary using view commit
[Quantum] Renamed Index into NodeIndex to avoid clash with future System.Index view commit
[Build] NETStandard: Remove unnecessary using view commit
[Assets] Switch from implicit project to explicit project if necessary (fixes #442) view commit
[Build] Switched to MSBuild.Sdk.Extras version 2.0.41 view commit
[Build] Doc: Copy .xml file in ref folder view commit
Revert "[Build] Switched to MSBuild.Sdk.Extras version 2.0.41" view commit
[Build] Moved Microsoft.NETCore.Platforms reference from Xenko.Graphics to Xenko.Core (otherwise scenarios like referencing only Xenko.Core with win-x64 doesn't work) view commit
[VSPackage] Syntax highlighting service was not properly registered asynchronously (fixes #651651) view commit
[VSPackage] Fix Xenko detection view commit
[VSPackage] Bump version to 3.0.6 view commit
[Build] Replaced to for shaders/effects view commit
[VSPackage] Add a launchSettings.json with proper parameters for easier debugging view commit
[Input] SDL: fix OemPlus/Minus mapping (thanks nes) view commit
[UI] Fix comment view commit
[Vulkan] Fix some memory barriers in CommandList.Copy and CopyRegion view commit
[Vulkan] CommandList: Don't use ImageView.Null in DescriptorImageInfo view commit
[Streaming] Load a few initial mipmaps for streamed texture (otherwise they start as completely uninitialized: bad for rendering, and causes crash on Vulkan) view commit
[Shaders] Fixed precompiled shader code generation view commit
[Shaders] Added ElementType info to reflection for buffers/textures view commit
[Vulkan] Properly store info if a texel buffer need to be integer or float. view commit
[Shaders] Make sure NoSampler is added before computing list of resource groups (otherwise it ends up having no location attribute) view commit
[Input] Fixed copyrights view commit
[VSPackage] Fix Xenko version detection to work not only with nuget packages but also solution projects, so that it works with Xenko solution itself. view commit
Merge remote-tracking branch 'weblate/master' view commit
[Localization] Added Italian view commit
[Localization] Added info in doc on how to translate and add new language. view commit
[Build] Remove the -beta02 version suffix view commit
[Shaders] D3D: Properly copy ElementType when duplicating resource binding per stage (fixes #515) view commit
[Samples] Updated to 3.1.0.1 view commit
[Setup] PackageInstall: check if VS Installer needs an update, and if yes try to do it automatically view commit
[Build] Temporary workaround for .NET Core 3.0 new runtime identifier system (credits go to Solr for finding this fix) view commit
[NuGet] Rewrote how assembly resolver is ordering assemblies found in nuget packages (there was a bug where it could select net46 instead of net461, resulting in crash) view commit
[Build] Moved Xenko.Samples.Templates version in a single unified location to simplify future maintenance view commit
[Setup] PackageInstall: Check VS Installer update if any workload needs to be installed (two UAC, but probably better than an error and extra step) view commit
[Build] Bumped MSBuild.Sdk.Extras to 2.0.54 view commit
[Build] Updated codesign certificates view commit
[Build] Android: Use AssemblyName rather than RootNamespace for Resource class otherwise it might clash between some assemblies (i.e. Xenko and Xenko.Engine) --> view commit
Revert "[Build] Remove the -beta02 version suffix" and bump samples accordingly view commit
[Build] Use default RuntimeIdentifier for default GraphicsApi, so that even if our custom RuntimeIdentifier are not merged properly, everything still work. view commit
[Build] Removed previous workaround for https://github.com/NuGet/Home/issues/7351 view commit
[Build] Bump NuGet.exe to 5.3.0 view commit
[Build] Improved behavior of XenkoGraphicsApiDependentBuildAll view commit
Merge branch 'runtimeid_fixes' into master-3.1 view commit
[Build] Android: Fix NDB platform versions view commit
[Graphics] Updated SharpDX to 4.2.0 view commit
[UpdateEngine] AssemblyProcessor was generating invalid ldftn for virtual/interface calls (causing crashes with .NET Core 3). Switch to ldvirtftn for those instead. view commit
[Graphics] Update D3D12 code for SharpDX 4.2.0 view commit
[Build] AssemblyProcessor task need to change identity on each change otherwise we can run into https://github.com/microsoft/msbuild/issues/663[#](https://github.com/xenko3d/xenko/issues/)issuecomment-310530046 view commit
[Graphics] Streamed compressed texture could end up having their initial texture size not multiple of 4, resulting in error at runtime loading. Skip these cases for now. view commit
[Fonts] Fix how matrix is computed and compute realVirtualResolutionRatio depending on actual requestedFontSize (fixes #314) (fixes #364) view commit
[Fonts] Dynamic fonts: use virtual resolution (otherwise real size changes on every camera move and requests new character, esp. if UI is in 3D) view commit
[Fonts] Do not alter fontSize view commit
[Fonts] Turned various internal parameters from ref to in (C# 7.2) view commit
[Fonts] Turned various internal parameters from ref to in (C# 7.2) (missing file) view commit
[Build] Added a trailing slash at the end of PackageOutputPath (maybe necessary since latest VS2019?) view commit
Revert "[Build] Add XenkoBuildDoc parameter to force TargetFramework even if not specified (seems necessary for older version of Roslyn used in docfx)" view commit
[Build] Separated XenkoGraphicsApis into one list per platform (otherwise we can't really control properly and risk overriding a platform with nothing) (fixes #544) view commit
[Build] Remove GetSolutionConfigurationContents hack (which was necessary for WinStore/WinPhone port) (this allows command line build for Android/iOS #543) view commit
[Build] Remove the -beta02 version suffix and bump samples accordingly view commit
Updated BACKERS.md view commit

WaldiS (3):

Added translation using Weblate (Polish) view commit
Translated using Weblate (Polish) view commit
Translated using Weblate (Polish) view commit

WhyPenguins (1):

Add output merger UAV binding. (#478) view commit

Yuuki terumi (5):

Added translation using Weblate (Spanish) view commit
Added translation using Weblate (Spanish) view commit
Added translation using Weblate (Spanish) view commit
Added translation using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit

dfkeenan (5):

Allow spaces in TargetDir when building LauncherApp project. view commit
Update Roadmap url to github projects. view commit
Add tooltip status text for link buttons. view commit
Add patreon link to launcher. view commit
Remove AnswerHub link from launcher. view commit

ioc (1):

Fix broken link to Teamcity Android build in ReadMe view commit

joreg (1):

VR tracker support (#213) view commit

meriaizen86 (3):

Translated using Weblate (Spanish) view commit
Translated using Weblate (Spanish) view commit
Update XenkoDefaultSplashScreen.xktex view commit

pansan (1):

Translated using Weblate (Chinese (Simplified)) view commit

phr00t (2):

Make alpha optional in Color4 view commit
[UI] don't invalidate text UI if we set it to the same thing view commit

rgawry (1):

Translated using Weblate (Polish) view commit

ssantos (1):

Translated using Weblate (German) view commit

tebjan (4):

[Assimp] Updated assimp to official 4.1.0 and updated references in projects (closes #458) view commit
[Assimp] Updated assimp to official 4.1.0 and updated references in projects (closes #458) view commit
fixed null pointer exceptions in render features view commit
removing a package did not fire an event, so all related assets where still in the dependency manager view commit

xwellingtonx (1):

Fix editor resizing and to insert auto hide minimum size (fixes #189 and #190) view commit

陈宇航 (1):

Translated using Weblate (Chinese (Simplified)) view commit

Generated using

git shortlog origin/master-3.0..origin/master-3.1 -w0,0,0 --pretty=format:"* %s [view commit](https://github.com/xenko3d/xenko/commit/%H)" | sed -r "s/#([[:digit:]]*)/[#\1](https:\/\/github.com\/xenko3d\/xenko\/issues\/\1)/g"

Recap October 2019

Thu, 31 Oct 2019 00:00:00 +0000

Welcome to our October edition. Here's a quick recap on Xenko development and its community. Official 3.1 Release is in final testing phases. You can now sponsor Xenko through Github sponsors. Possible name change is being discussed. The first tutorial project is almost ready.

Official 3.1 Release 🔗

The 3.1 was originally scheduled for release this month, but some last minute breaking changes prevented the release. The official release is now in its final testing phases and should be released shortly. Once the release is final, we can focus on planning out tasks and the new roadmap for 3.2.

Git Sponsorship 🔗

Next to Patreon you can now also sponsor Xenko development directly through Github sponsors. GitHub even doubles the money that is donated the first year up to $5000!

Possible Name Change 🔗

For those of you who have missed it: Xenko is looking for a possible rename of the engine. There have been lengthy discussions on Discord about the name we could pick. See the fixed topic in the Discord #name-change channel.

Documentation 🔗

The first tutorial project is almost ready. Users will be able to select tutorial templates from a Tutorial category in the project launcher. The first project “C# Beginner”, demonstrates 12 beginner programming concepts. The amount of tutorials, as well as intermediate and advanced tutorials, will be extended/added once the first release is done.
Additionally, the code used in the project is directly referenced by the new documentation section which explains each individual tutorial level.

Community Picks 🔗

Check out these awesome community projects that people are working on:

Voxel cone tracing based global illumination from Spike1 🔗

Forum post
Github project

Heightmap Terrain from SilentCLD 🔗

Github project

Xenko meets vvvv

Fri, 04 Oct 2019 00:00:00 +0000

Explore the integration of Xenko and vvvv, a powerful combination that unlocks new possibilities for creating visually stunning and interactive 3D experiences in real-time.

Xenko and vvvv 🔗

When Xenko went fully open-source in 2018, one of my intent was to be able to engage directly with some of Xenko's most enthusiast customers and power users. vvvv is definitely a perfect example.

vvvv is a hybrid visual/textual live-programming environment for easy prototyping and development.

vvvv has been using Xenko under the hood for a while, e.g. for the Ocean of Air project.

They also have various plans to leverage Xenko even further in the future gamma version.

That's what led me to establish closer contact with them. One things led to another, and in May 2019 I jumped in with both feets and moved to Berlin. They've been graciously sponsoring Xenko and allowed me to use their office since then.

My sincere thanks to them for supporting both Xenko and me!

Please find vvvv announcement at https://vvvv.org/blog/vvvv-meets-xenko

Code signing certificates 🔗

A few days ago, Xenko code signing certificate expired, leaving the project in a tough situation, where smooth releases were not possible anymore.

vvvv graciously offered me to temporarily sign Xenko official releases with their own codesign certificate. So don't be surprised to see their name popping up next time you upgrade Xenko!

This is only temporary and we are working to get our own code signing certificate as soon as possible. More to come soon on that front!

Contributor Meeting October 2019

Tue, 01 Oct 2019 00:00:00 +0000

Discover highlights from Stride's first contributor meeting, focusing on project collaboration, development updates, and ways to enhance the game engine together.

Next to the community meetings were everyone can join in on the discussions, we now also have the contributor meetings. These contributor meetings are for the people who are actively participating in Xenko development. Last weekend we had our first gathering. Another thank you to all who participated!

Summary 🔗

Date of meeting: 28 September 2019

Official release of 3.1
- The release of 3.1 is imminent. More details on this will be provided soon.
- Nuget package creation is the biggest task to be completed.
General roadmap
- The roadmap currently planned on Github is outdated. It needs to be updated and become more relevant to the capacity we currently have as Xenko contributors/developers.
- New freedcamp tasks will come out of this that can be assigned to contributors. Some areas of contribution:
  - Xenko core (subsystems, frameworks, .Net version etc)
  - Editor improvements
  - Examples/Tutorials: C# coding, Models/materials setup from Import to Scene, Animation
Roadmap for 3.2
- Planning out the next features is a big challenge, because there are so many things wanted/requested. Since Xen is the only full time core developer, we can probably only toggle 1 major feature next.
- After the 3.1 is released the strategy on which core feature should be implemented. This has yet to be decided. The next developer meeting will go deeper in to this.
  - Example on what could be worked on: asset compiling/.NET Core 3
Release cycles
- We will try to adapt a more frequent official release strategy. Even if that official release contains few fixes or improvements. We do not want to plan releases on fixed dates, but instead we do want to keep the 3-4 months idea in our mind. This should provide the community more reliability.
- Depending on the amount of fixes/improvements this will major or minor.
Phr00t fork
- It has proven difficult to merge functionality from phr00t fork to main xenko, but there is ongoing progress!
- 2 users (Fdrobidoux and SilectCLD) are currently working on merging code. If you are interested in following the progress have a look at the task for this.
- Vulkan improvements will need to be done differently, and some work from xen2 has already landed for this.
Documentation
- The C# basics tutorials are making progress, but the sample project is not quite there yet.
- Some better screenshots and a base tutorial scene that looks a little bit more appealing could be really useful.
- Release for this is extended by 1 month.
Access rights:
- We can distribute some access rights among contributors to ofload some of task from Xen.
  - Social media: SyrikZero
  - Website deployment Teamcity/Azure: JornAggror
Name change
- Let’s take it one step at a time: first let’s see what possible name we can come up with.
- Check the voting topic by Eideren for more info.
General topics:
- We are aiming to do a contributor meeting every 2 months.
- This meeting was a long sit: 1.5 hours. Next meetings should be 1 hour at max, but preferable shorter.
- Using Discord for the meeting, was not ideal. We will try to see if we can use Google Hangouts for this.
- The timezone planning of the meeting did not go as planned even though Doodle does support this. This will be properly tested for the next meeting.
- Freedcamp will remain as the tool for planning generic tasks. Since most contributors have now joined, new members can only edit tasks if they are invited.

Want to join the contributors? 🔗

Whether you are a developer, designer, artist or writer, you are always free to create Pull Requests or add issues to the Xenko github project.

If you are interested in participating in the contributor meetings and the Xenko Freedcamp project, please send a private message to AggrorJorn using the Xenko forum. All you need to do is send in your email address and what areas of contributing you are interested in. You will be invited to join the publicly viewable Xenko Freedcamp project which we use to keep track of all sorts of tasks that people are working on. We can then also have a quick chat to get you up to speed on any tasks.

Recap September 2019

Mon, 23 Sep 2019 00:00:00 +0000

Welcome to the September blog post of Xenko. In this blog, we will have a quick recap on what's going on with Xenko development and its community. From now on we will have a monthly recap blog to let the world know what we are up to.

Picking Up Speed 🔗

Since the last developer meeting in July, it was made clear that Xenko really needs the help of the community to improve. Part of improving is making sure that the community can help out on various aspects of Xenko. This is not just the development of the Xenko engine itself, but also all the other processes that are involved around it. You can follow the ongoing forum discussion here.

New Project Overview 🔗

As part of getting things done quicker, a new public project overview has been set up using Freedcamp. In this here we track of ongoing tasks, who is assigned to it and what possible milestones are. If you want to contribute to this project or just check out the current tasks, have a look.

What is being worked on 🔗

Here are some of the things that are being worked on:

New tutorials section for the documentation website. Starting with a section of C# basics with Xenko, we can start making it easier for people to get the hang of Xenko in no time. Here is a quick peek at how it is going to look like.
Phr00t fork merging: The Phr00t fork contains many features that the main Xenko engine could benefit from. From countless API improvements to bigger features like Vulkan improvements. Right now contributors are looking in which features and functionality to move to the main Xenko repository.

Possible Name Change 🔗

For those of you who have missed it: Xenko is looking for a possible rename of the engine. If you want to know more about the why and why not, have a look at this forum topic. Regardless of whether the name change will happen, we need to find a suitable candidate. In a few weeks, we will start a poll to narrow down the long list of suggested names. A more detailed blog on this will follow soon. In the meantime, if you have a great idea, feel free to make a suggestion in the topic above or in the Xenko discord channel “Name-change”.

Community Meeting July 2019

Fri, 19 Jul 2019 00:00:00 +0000

Get an overview of Stride's second community meeting, discussing updates, future plans, and addressing questions from developers and users of the game engine.

Time for our second community meeting.

Yes, it has been renamed from Developer meeting to Community meeting to better reflect the intended target audience.

This time, the idea is not only to find where Xenko should head next (I am sure there will be hundreds of ideas, many of them already waiting on GitHub issues!), but also to find more people volunteering to take over some of those tasks!

Here is a tentative schedule for this meeting:

UTC (GMT) Wednesday, 24 July 2019, 15:00:00 UTC
Berlin (Germany) Wednesday, 24 July 2019, 17:00:00 CEST
Paris (France) Wednesday, 24 July 2019, 17:00:00 CEST
Tokyo (Japan) Thursday, 25 July 2019, 00:00:00 JST
San Francisco (USA - California) Wednesday, 24 July 2019, 08:00:00 PDT
New York (USA - New York) Wednesday, 24 July 2019, 11:00:00 EDT
London (United Kingdom) Wednesday, 24 July 2019, 16:00:00 BST

It will be held on Discord in the #dev-meetings channel.

Please come define the future of Xenko with us!

Starbreach Demo

Fri, 31 May 2019 00:00:00 +0000

Explore the impressive Starbreach demo, a testament to Stride's powerful 3D game development capabilities, featuring stunning visuals, smooth gameplay experiences, and a glimpse into the engine's potential for creating immersive and engaging gaming worlds.

Hi everyone, Silicon Studio agreed to release the Starbreach demo from GDC 2017, along with all associated assets as open source (see license), for the Xenko community to use. Code in the project is released under an MIT license, the assets are released under a attribution-NonCommercial 4.0 International (CC BY-NC 4.0) license.

Starbreach was originally developed as the Xenko GDC demo for 2016 by Silicon Studio with art support from N-iX production studios. Virgile Bello (xen), Xenko’s lead developer has spent a chunk of time updating the demo and assets to work with the latest release of the Xenko.

You can find the demo and assets here:
https://github.com/xenko3d/Starbreach

And more on the licensing here: https://github.com/xenko3d/Starbreach/blob/master/LICENSE.md

Xenko now has a great playable demo... Can we make it even better? 🔗

The community is doing a great job building out the xenko 3.1.0.1 beta release especially filling in gaps, fixing bugs and fulfilling the promise of a community led game engine - so special thanks to Tebjan, phr00t, dfkeenan, Eideren, Venthe, Aggror, Pred, Jarmo, dio and xen to name only a few.

With the release of Starbreach demo - we now have a great playable demo that shows off Xenko. xen’s thrown the glove down and done his part with getting release permission and updating - but can everyone in the community help make it even better? Maybe by adding additional AI, improving the game play or adding a new boss character or full levels? Source is on github and let’s discuss on Discord or in the Forum.

Welcome TurboPlay as Gold Sponsor

Tue, 12 Feb 2019 00:00:00 +0000

We're happy to announce TurboPlay is helping Xenko not only as a Gold Sponsor, but also have further plans to support Xenko in the future.

Our respective visions for a more open game engine and decentralized marketplace seem to have a lot in common.

Thanks TurboPlay for supporting Xenko and its community! This is a very exciting milestone and hopefully the beginning of a new era for Xenko!

Open the full post for the press release in all its glory.

Press Release: TurboPlay Announces Videogame Engine Support With Xenko 🔗

TurboPlay is pleased to announce Gold Sponsorship for the Xenko Game Engine and its Open Source Community.

“We’re pumped to have the opportunity to support the Xenko development team and work with them to develop amazing new technologies for their community and ours! Xenko is a modern game engine technology developed entirely in C#. Xenko’s technology has incredible potential in today’s gaming market. Through this partnership we can provide direct support to Xenko indie developers,” said Vince McMullin, TurboPlay President and CEO.

Launching in 2019, TurboPlay is developing a full-fledged marketplace ecosystem by maximizing exposure for unique indie content. TurboPlay is the world’s first ultra-modern, fully-scalable, fault-tolerant, peer-to-peer, videogames marketplace.

“I'm super excited to work with TurboPlay! We’ll be able to achieve great things together. I believe that both organizations are philosophically aligned, embracing the ideas of permissive open-source, decentralized and distributed architectures to disrupt the status quo in the games industry,” explains Virgile Bello, Lead Engine Developer.

TurboPlay plans to support Xenko in future endeavors, including their Indie Community, with developer grants supporting game development using both Xenko & TurboPlay technologies.

For further inquiries regarding this topic, please contact our CMO, Lisa Weeks, by email, lisaw@turboplay.com. Thank you.

https://www.linkedin.com/company/turboplay
https://www.linkedin.com/company/xenko

Twitter

https://twitter.com/trbplay
https://twitter.com/xenko3d

Facebook

https://www.facebook.com/TRBPlay
https://www.facebook.com/xenko3d

Link to the official press-release:
https://www.newswire.com/news/turboplay-announces-videogame-engine-support-with-xenko-20801982

Developer Meeting January 2019

Sat, 19 Jan 2019 00:00:00 +0000

Get insights from Stride's first developer meeting, covering project status, development progress, and future plans for this versatile game engine.

Now that Xenko 3.1 beta is well underway, it's time to prepare for the future.

As part of this process, I would like to involve our newly formed community.

The idea is to decide together during a developer meeting what are the next long-term targets for Xenko, and what to put in release 3.2+.

The first developer meeting will be open to everybody (developers, users and potential future users).
It's possible we then evolve toward a more moderated format if needed.

Here is a tentative schedule for this meeting:

Tokyo (Japan) Wednesday, 23 January 2019, 01:00:00 JST
Berlin (Germany) Tuesday, 22 January 2019, 17:00:00 CET
Paris (France) Tuesday, 22 January 2019, 17:00:00 CET
London (United Kingdom) Tuesday, 22 January 2019, 16:00:00 GMT UTC
San Francisco (USA - California) Tuesday, 22 January 2019, 08:00:00 PST
New York (USA - New York) Tuesday, 22 January 2019, 11:00:00 EST
UTC (GMT) Tuesday, 22 January 2019, 16:00:00

It will be held on Discord in the #dev-meetings channel.

Please come define the future of Xenko with us!

Xenko 3.1 Beta Released

Mon, 24 Dec 2018 00:00:00 +0000

Explore the Xenko 3.1.0 beta release, featuring exciting new features, enhancements, and improvements in this powerful 3D game engine by Stride.

Just in time for Christmas, Xenko 3.1 Beta is out now!

One of the major change is turning the engine into separate NuGet packages, published on NuGet.org.

Merry Christmas and Happy Holidays!

Xenko 3.1 Loves NuGet! 🔗

Xenko was always a big proponent of NuGet: since first version, Xenko was distributed as a NuGet package.

Xenko 3.0 paved the way by making Xenko compatible with the new project system (game projects were referencing Xenko using a PackageReference).

Today, Xenko 3.1 brings Xenko as a set of smaller NuGet package, each containing one assembly, with proper dependencies:

As a result, it is now possible to create a game project that references only the packages you want. Here are a few examples of "core" packages:

Xenko.Engine: allows you to use core engine runtime (including its dependencies)
Xenko.Core.Assets.CompilerApp: compile assets at build time
Xenko.Core.Mathematics or Xenko.Graphics: yes, if you want to make a custom project only using Xenko mathematics or graphics API without the full Xenko engine, you can!
Xenko.Core.Assets, Xenko.Presentation or Xenko.Quantum: all those piece of tech being used to build Xenko tooling are also available for reuse in other projects. Nothing prevents you from generating assets on the fly too!

Then, various parts of the engine are distributed as optional packages:

Xenko.Physics
Xenko.Particles
Xenko.UI
Xenko.SpriteStudio
Xenko.Video

If you don't reference those packages, they won't be packaged with your game either. In many situations, it results in a smaller packaged game and improved startup time.

Also, you are free to replace those functionalities with alternative libraries.

Coming Soon 🔗

Xenko Assets Distribution 🔗

Xenko Assets will be packed and distributed with NuGet automatically.

Coming soon in next beta, C# projects containing Xenko assets will have those assets automatically NuGet packaged in a xenko folder.

As a result, you will soon be able to generate NuGet package containing Xenko assets out of the box from Visual Studio and publish them on NuGet.org for general consumption for other Xenko users.

We can't wait to see what will come up!

Full Switch to .NET Standard 🔗

Soon Xenko will support .NET Standard for most of its assemblies.

Xenko games will be able to run on .NET Core for Windows (Linux is already supported).

Feature Spotlight: Xenko 3.1 + NuGet

Tue, 13 Nov 2018 00:00:00 +0000

Discover the powerful features of Xenko 3.1, the latest update to the Stride 3D game engine. Learn how NuGet integration streamlines development and enhances your game creation experience. Dive into our detailed blog post now!

Today, I would like to highlight some work being done on Xenko.

Xenko 3.1 will bring some big changes in the way Xenko is packaged, distributed and consumed.

Xenko 3.0: Welcome PackageReference! 🔗

Xenko was always a big proponent of NuGet: since first version, Xenko was distributed as a NuGet package.

However, due to limitations (hello packages.config and project.json!) we were leveraging NuGet more as a distribution medium than proper NuGet packages: Xenko up to 3.0 is still a monolithic single package and it would not work out of the box when referenced from Visual Studio without using launcher and Game Studio.

Xenko 3.0 paved the way by making Xenko compatible with the new project system (game projects were referencing Xenko using a PackageReference).

This Xenko "fat" package is still containing everything: Xenko runtime, editor, compilers, samples. Various features of Xenko are forced onto the users: UI, Physics, SpriteStudio, etc...

Additionally, Xenko assembly references are still manually added through complex target files rather than following package reference layout and see them where they should have been, nested inside the Xenko NuGet reference:

Xenko 3.1: Enter Modular Xenko 🔗

Most of the changes discussed in this section are still in a prototype state, but should hopefully be merged soon in master.

One Package per Assembly 🔗

Xenko 3.1 will bring Xenko more in line with a more proper way of organizing NuGet package: one package per assembly, with proper dependencies:

As a result, it is now possible to create a game project that references only the packages you want. Here are a few examples of "core" packages:

Xenko.Engine: allows you to use core engine runtime (including its dependencies)
Xenko.Core.Assets.CompilerApp: compile assets at build time
Xenko.Core.Mathematics or Xenko.Graphics: yes, if you want to make a custom project only using Xenko mathematics or graphics API without the full Xenko engine, you can!
Xenko.Core.Assets, Xenko.Presentation or Xenko.Quantum: all those piece of tech being used to build Xenko tooling are also available for reuse in other projects. Nothing prevents you from generating assets on the fly too!

Then, various parts of the engine will be distributed as optional packages:

Xenko.Physics
Xenko.Particles
Xenko.UI
Xenko.SpriteStudio
Xenko.Video

If you don't reference those packages, they won't be packaged with your game either. In many situations, it will result in a smaller packaged game and improved startup time.

Also, you will be free to replace those functionalities with alternative libraries.

Package Layout: Following Best NuGet Practices 🔗

Previously Xenko references were added to the project using custom targets.

New packages will now be layout as NuGet/Visual Studio expects them, in folders like lib/net45 and lib/monodroid10.

We still have a few custom MSBuild targets but reduced them to minimum.

Xenko assets are also distributed as part of package 🔗

NuGet packages will have a xenko folder containing Xenko assets. As a result, user will be able to generate nuget package containing Xenko assets out of the box from Visual Studio and publish them on NuGet for general consumption.

Distribution Platform: time to switch to nuget.org? 🔗

This is still something under consideration and it will need some testing, but it now starts to make sense to distribute Xenko packages on nuget.org rather than our custom NuGet server.

This will greatly reduce friction to try Xenko (any project would work out of the box in Visual Studio). This might also make our launcher completely optional, if not redundant.

Xenko tooling will resolve assemblies dynamically using NuGet API 🔗

Tools such as GameStudio or Asset Compiler will be distributed as NuGet packages. However, it won't bundle Xenko Runtime, which will simply be encoded as dependency.

When running those tools, they will resolve Xenko runtime assemblies directly in the NuGet cache.

This allows for distributing those tools as very small and easy-to-upgrade packages, avoiding file duplications. This is similar to what dotnet-cli is doing with deps file.

Future: Plugin Support for Editor 🔗

Xenko 3.1 editor will still be monolithic: editor support for UI, SpriteStudio, Video and other optional modules will be hardcoded.

However, the target is to get rid of them as soon as possible, and treat them as what they are: plugins.

Conclusion 🔗

This is just the beginning, laying out foundations to turn Xenko into a set of reusable libraries. Much more to come soon!

This is an exciting era for Xenko. Hopefully it will open doors to many new use cases, and bring us lot of new potential users and developers!

Opensourcing Done! What's Next?

Wed, 22 Aug 2018 00:00:00 +0000

Explore the future of Stride 3D game engine after going open source. Understand the roadmap, exciting developments, and how the community plays a crucial role in shaping its growth. Read our in-depth blog post to learn more!

Now that Xenko is opensource under the MIT license and the dust settled a little bit (took a few weeks of vacations after the opensource release crunch), it's time to take a step back, think about what's next, and start building it together!

We need help! 🔗

First of all, the main objective will be to grow our developer and user community. Xenko has no chance to succeed if we don't have enough people contributing on and using it.

Thanks to its still small but dedicated community of early adopters, within a few weeks, Xenko already had a bunch of pull requests accepted and issues opened during those few days. This has led to new releases including some of the new fixes and features.

Thanks everybody, your help is very much appreciated! Please keep up the great work!

Of course, Xenko can't compete yet against more famous alternatives in terms of features, but I think Xenko is already an attractive choice for several populations, such as:

people wanting to develop and/or experiment on a game engine
companies wanting to invest in open technologies, and build freely on top of it
indie developers
non-game projects

We will need your help to find those people: please spread the word! Feel free to contact us if you have any idea (company interested in Xenko, marketing opportunities, etc...).

Roadmap 🔗

I have started to organize the list of Epic features into a roadmap draft on GitHub. It's still an early work in progress so please check regularly. We will also be using ZenHub to organize issues and epics.

Feel free to add your own ideas!

However, I want to stress an important point: this just acts as a wishlist and it should only be taken as a recommendation of what need some work.

Being an opensource project, I can't and don't want to enforce a strict roadmap. People work out of motivation driven by their own interests or needs for their own projects. This is incompatible with enforcing a roadmap and strict deadline. This might change later if we get enough funding to hire full-time people.

Still, if you are not sure what to help with, starting with the issues is probably a good starting point (I will mark some of them with the good first issue label). Feel free to stop by gitter to discuss with the developers.

Please state your intention to work on something on GitHub issues, and confirm how to do it with other collaborators to make sure it doesn't conflict and will be accepted smoothly.

Expect some tweets and blogs posts about what's being worked on in the coming weeks.

Donations 🔗

OUTDATED: Use Open Collective instead.
~~If you want to help Xenko, or if Xenko is helping you or your company, please consider donating on Patreon.~~

This will help me not having to focus on side projects to secure money, and bring me peace of mind to focus solely on Xenko. Since my plan is to work full-time on it, this will be my main source of income for now.

I extend my thanks to early donors for supporting the project in its infancy! Your help means a lot.

And thanks again everybody for your support and time so far, and let's hope for a bright future for Xenko!

Xenko 3.0 is Now Free and Open-Source!

Thu, 02 Aug 2018 00:00:00 +0000

Unveiling Xenko's transition to an open-source MIT license, opening doors for developers to access and contribute to the powerful Stride 3D game engine. Learn about the benefits, opportunities, and how to get involved in our comprehensive blog post!

You read that right. Xenko 3.0 is out now, released under the permissive MIT license.

From now on, you can use and modify Xenko completely free — whether you're a professional, a student, or just looking for a new hobby. This includes both the runtime and editor.

Main focus for this release was on the open-source transition, but Xenko 3.0 also includes some new features, such as a switch to the new C# project system, video, hair and skin rendering. Read the full release notes here.

Silicon Studio no longer supports Xenko, but members of the Xenko team will continue to work on it independently as part of the community. More specifically, I will personally work on it fulltime for the next few months to see if it picks up some steam as a community project. Kudos to Silicon Studio for starting and supporting the project so far! Turning the project open-source and community-driven is a fantastic achievement.

This project will live thanks to its community and will have its own GitHub organization. Want to contribute? Join us on GitHub!

Updated: Use Open Collective to support further Stride Engine development.

Outdated:
~~Also, I have setup a Patreon page for people who want to financially support the effort (servers and me working fulltime).~~

We're proud of everything we and our users have achieved with Xenko over the last three years. We can't wait to see what you do with it next!

Changes to the Xenko License

Fri, 30 Mar 2018 00:00:00 +0000

Dive into the significant changes to Xenko's license and how they impact the Stride 3D game engine community. Understand the new licensing terms, benefits, and opportunities they present for developers. Get all the details in our informative blog post!

Long time no see!

The Xenko promotion period has ended, and we've made some changes to the license plans.

As of 1 April 2018, Xenko Pro and Xenko Pro Plus are no longer available.
Xenko Personal is still free for personal use and for businesses of less than $200,000 US in annual revenue. If you don't meet the Xenko Personal criteria, contact us for a custom plan.
If your business makes over $200,000 US in annual revenue, and you downloaded Xenko before 1 April 2018, you can continue to use Xenko until 1 April 2019. If you want to use Xenko after that, you need to contact us to create a custom plan before 1 April 2019.

For more information, see the FAQ.

Meanwhile, we're exploring the idea of a version of Xenko run entirely by the community. We also have a bunch of updates we're excited to show you, which we'll release once we finish exploring licensing options.

We know it's been a long wait for Xenko users. We really appreciate your patience.

Get Xenko here.

Xenko Pro Free until April 2018

Thu, 21 Dec 2017 00:00:00 +0000

Xenko game engine offered free until April 2018! Learn more about this limited-time opportunity in our brief blog update.

Nope, that’s not an April Fool’s. We've extended the Xenko promotion while we explore different licensing options. We can’t reveal too much right now, but we’re hoping to move to a more permissive license.

In the meantime, Xenko Pro will remain free for everyone until April 1, 2018, as per the existing terms and conditions. Consider it a Christmas present.

Get Xenko here.

Happy holidays!

Xenko and 3dRudder

Sun, 24 Sep 2017 00:00:00 +0000

Discover 3dRudder's integration with the Stride 3D game engine in our concise blog post. Learn about this unique foot-powered controller and its impact on game development.

The 3dRudder is an interesting piece of hardware that lets you use your feet to control game movement. It's one of a number of devices out there exploring different ways to interact with VR.

A while ago, the team at 3dRudder got in touch to show us a prototype they built in Xenko using the Virtual reality template project. This lets you move around the scene by tilting and rotating the 3dRudder.

The team has made their Xenko project available on GitHub for everyone to try out. You'll need a 3dRunner device with firmware version 1.3.5.2 or later to work with the project.

The 3dRudder team also took the time to report a bug that force-enabled the Ignore camera rotation VR option when using OpenVR as the API. The option means players can only change the view position by moving the VR device, and not external controllers, like mice, gamepads, or the 3dRudder. Whoops. That was fixed in a recent release.

It's great to see developers out there experimenting with Xenko and their creations. If you're cooking something up that should be on this blog, we'd love to hear about it.

For more information about the 3dRudder, see the 3dRudder site. For details about setting up VR in Xenko, check out the VR documentation.

Xenko 2.1 Released

Thu, 14 Sep 2017 00:00:00 +0000

Learn about Stride version 2.1.0, a significant update packed with new features, enhancements, and bug fixes aimed at streamlining game development and improving user experience.

Xenko 2.1 is out now! Thanks, as ever, to all our users for your feedback.

For the full list of changes, see the release notes.

Summary 🔗

Local reflections 🔗

Xenko 2.1 introduces local reflections. We wrote about this feature back in March; it's been through several revisions since then.

You can enable and customize local reflections in the graphics compositor on the post effects properties.

For details, see the local reflections documentation.

Clear coat shading 🔗

Xenko 2.1 includes a clear-coat material template that uses physically-based rendering to simulate vehicle paint.

Clear-coat shading has several advantages over creating the effect manually with material layers:

layers are blended based on distance
increased performance
improved visualization

You can add a predefined clear coat material from the Asset view under Add asset > Material.

For details, see the clear coat shading documentation.

Thin glass materials 🔗

You can now render thin glass materials such as windshields. The diffuse color controls the tint of the glass and how much light is blocked (darker colors block more light).

You can add a predefined Glass material from the Asset view under Add asset > Material.

Improved light shafts 🔗

You can now use light shafts with any kind of light that casts shadows (ie point lights, directional lights, or spot lights). You can also use them with multiple shadow cascades.

Additionally, Game Studio now displays light shaft bounding volumes in the scene editor, so you can easily see the areas where light shafts are created. To show or hide navigation light shaft bounding volumes, in the scene editor toolbar, open the gizmo options menu and use the Light shaft bounding volumes checkbox.

The LightShaftComponent settings have been simplified and now have settings to control quality and performance.

For details, see the light shaft documentation.

Texture streaming 🔗

Xenko now supports streaming for textures. This significantly decreases the time it takes to load a game or scene, uses less memory, and makes your game easier to scale.

Streaming is enabled for textures by default. You can find the option in the texture properties under Format.

You can also set the global Streaming settings in Game settings.

For details, see streaming documentation.

Render masks 🔗

You can now set which render groups a camera renders under Graphics Compositor > Entry points > Render masks. For example, you can have a model be visible to Camera A but invisible to Camera B.

For details, see the Render groups and masks documentation.

Improved profiler 🔗

The Game Profiler script now displays more information and is easier to use.

You can now:

profile GPU information
switch between CPU, GPU, and FPS-only results with F1
sort the result pages by Name or Time with F2
change how frequently the profiler gets and displays new results with - / +
jump to a results page with the number keys, or move forward and backwards with F3 and F4
set parameters in Game Studio:

For details, see the Profiling documentation.

Debug text 🔗

You can now display debug text at runtime. For more information, see the debug text documentation.

Rewritten input system 🔗

The input system has been rewritten to track different input devices and allow for better extensibility.

Allows detection of added/removed devices through events on the InputManager
New device interfaces such as IMouseDevice, IKeyboardDevice, IGameController
High-level IGamePadDevice replaces the gamepad functionality, with support for XInput
Lower-level IGameControllerDevice allows access to numbered buttons/axes
Automatic detection of plugged-in/removed controllers
Support for different keyboard layouts and IME for text input
Access to resolution and absolute coordinates for mouse/pointer devices
KeyEvent now has a RepeatCount member, indicating how many times the key has been repeated while being held down

For details, see the Input documentation.

Improved Direct3D 12 support 🔗

To support graphics functionalities on every platform, we've implemented missing features for the DirectX 12 rendering backend:

compute and tessellation shaders
unordered access views for textures and buffers
structured buffers

Improved environment fresnel 🔗

Fresnel describes how light is reflected depending on the angle the material is viewed from. Typically, high angles are more reflective.

Previously, Xenko used an imprecise polynomial approximation to compute the fresnel for environment lighting (such as cubemaps), resulting in a bigger-than-expected white outline. Xenko now defaults to a precomputed BRDF environment lookup texture that matches our default lighting equations (GGX Schlick). This produces much more accurate rendering.

Japanese documentation 🔗

ドキュメントは日本語での表示も可能です。言語を切り替えるには、右上のLANGUAGEボタンをクリックしてください。

The Xenko documentation is now available in Japanese. To switch languages, use the Language button in the top-right of the documentation site.

Game Spotlight: Children of the Galaxy

Thu, 11 May 2017 00:00:00 +0000

Get a glimpse of 'Children of the Galaxy', an ambitious game project powered by Stride 3D, in our Developer Spotlight series. Learn about the creative minds behind the game, their inspirations, and the challenges they've faced. Immerse yourself in the world of game development with our captivating blog post!

It takes amazing developers to build a game from scratch. To do it with an engine while it was still in beta is a next-level feat. Today, the Xenko team would like to spotlight the first developer to get their game published on Steam while Xenko was in its beta stage.

Filip Dusek is the creator and engineer of the newly released Children of the Galaxy game. Growing up in the Czech Republic, Filip frequently played 4X strategy games, and especially loved games such as “Civilization™” and “Endless Space™”. After a few years of learning game development at university along with self-study, he worked as a senior programmer at 2K Games working on such titles as "Topspin 4™", "Mafia 2™" and Mafia 3™". However, with 4X games still being his favorite genre, Filip decided to set out and create his own game set in space. Unlike any other 4X strategy games, he wanted to put his own spin on the genre by incorporating more tactical elements, enabling users to engage in complex strategies to play with. With that ideal in mind, he set out on his three-year journey to create Children of the Galaxy.

Development initially began on a different engine. Feeling that the engine was not up to par with his rendering needs, Filip searched for another C#-friendly game engine that would give Children of the Galaxy a polished feel, and that was also easily accessible. Eventually, through some shout-outs on Twitter, he discovered Xenko as a viable option. After some research into the engine and its features, he decided it was his best option to bring to life his vision for a game filled with galactic alien battles in the far reaches of space.

In a recent discussion with Filip, he noted, “Using Xenko was pivotal for creating Children of the Galaxy. Its ease of use, nested prefab feature, PBR and how easy it was to import data really gave me the tools I needed to develop my game.”

Children of the Galaxy is a 4X strategy game where the player is pitted against other alien races in a battle for survival. Carefully choose your tactics in this turn-based strategy game in a war for galactic domination.

Children of the Galaxy is available now on Steam. Download it here!

The Xenko team is proud to have such creative and talented developers using Xenko. This is the first in what we hope to be a long repertoire of developer showcases. We're looking forward to seeing what else our users have in store for us!

Xenko 2.0 Released

Tue, 25 Apr 2017 00:00:00 +0000

After nearly two years of open beta, we’re proud to announce that Xenko is now available as a commercial product. Xenko 2.0 adds features such as full VR support, a pipeline rendering editor, light probes, and scene streaming management, along with greatly improved stability.

We’d like to thank all our beta users for their feedback, which helped us improve Xenko immeasurably over the last two years. We couldn’t have done it without you!

Get Xenko 2.0

Pricing 🔗

Xenko remains free for individual users, small studios, and educational purposes. It will be available to larger businesses through a monthly subscription.

Pricing for Xenko is broken into four tiers:

Xenko Personal – Free but limited to small studios, personal use, and students
Xenko Pro – Designed for smaller studios at $75 per month per user
Xenko Pro Plus – Designed for larger studios at $150 per month per user
Xenko Custom – Available for teams with special requirements or large-scale projects

While the Xenko runtime source code remains open to everyone, the Game Studio source code is only available in the Pro Plus and Custom tiers. Personal and Pro users will be able to extend Game Studio via a plug-in system available later this year.

Xenko Personal is not available to non-profit organizations and companies with yearly income above $200k. Additionally, Xenko Personal users must display a “Made with Xenko” splash screen in their applications.

For more information about the pricing plan, see the official website page

Xenko Pro is free until December 31st 🔗

To give everybody a chance to check out Xenko 2.0, Xenko Pro is free until December 31st 2017.

During this period, you can use Xenko without creating a Xenko account and the Pro Plus version will be available only by contacting the Xenko team.

The Xenko Store opens on January 1st. From that date, Xenko Pro users must purchase a subscription, or switch to the Xenko Personal subscription if they’re eligible. The Xenko Pro Plus plan will also be available to buy from the online store.

For more information about the welcome campaign, see the official website page.

No need to make your game open-source 🔗

From Xenko 2.0, all Xenko users (on any tier) can modify the source code and recompile the engine without having to open the codebase of their game. You can also redistribute modified Xenko source code to other Xenko licensees having access to the same plan as you.

What about the beta versions? 🔗

Beta Xenko versions will remain available for now under the same conditions as before, but will no longer receive updates. We’ll remove the beta versions at some point, so we encourage you to switch to Xenko 2.0. Remember that Xenko is free for individuals and small businesses.

What’s new in Xenko 2.0? 🔗

Scene hierarchy and scene streaming 🔗

Working with scenes has become more flexible. Instead of a single scene, your game can now use a hierarchy of scenes to organize entities into levels, areas or layers, and let teams collaborate on them more efficiently.

Game Studio displays child scenes together with their parent. Individual scenes can be loaded, unload, locked and moved around.

When running your game, the default scene set in your game settings is loaded as the root scene and can be used to store persistent entities. More scenes can be dynamically loaded and unloaded from scripts and added as child scenes.

var childScene = Content.Load<Scene>("myChildScene");
SceneSystem.SceneInstance.RootScene.Children.Add(childScene);

To get started, take a look at the new built-in SceneStreamingScript. It demonstrates background scene loading when passing through trigger volumes.

You can now use a scene's Offset to move its entities both at design time and runtime.

The ChildSceneComponent has been removed. We encourage all entities to be managed by a single entity manager and rendered by a single graphics compositor.

Virtual Reality 🔗

Enabling VR is now as simple as a single click!

Xenko's clustered forward rendering, with its multisample anti-aliasing, makes it ideal for VR. Xenko uses a single API for every device, with native support for Oculus and HTV Vive (more devices coming very soon).

Xenko comes with a VR game sample that shows you how to implement VR gameplay, including environment interaction and teleportation:

Save valuable time by visualizing and testing VR directly from the scene editor:

Global illumination with light probes 🔗

Light probes capture the lighting at the position you place them. They simulate indirect light, the effect of light bouncing off surfaces and illuminating other surfaces.

They can make a dramatic difference to the mood and appearance of your scene.

Light probes can be placed freely and are processed per pixel. This means you can use them not only on small dynamic objects, but also large or static objects (until we have light maps for those!).

Last but not least, you can now very easily capture a DDS cubemap from current camera position in editor, for use as a diffuse or specular skybox light.

Light Shafts 🔗

Xenko now supports shadow map-based light shafts for directional lights.

Our implementation uses ray-marching rather than post effects, making the shaft visible and cool-looking even if the light source isn't visible.

Graphics Compositor 🔗

The graphics compositor is now a separate asset.

Rendering parameters (such as VR) and post effect parameters can be tweaked in just a few clicks.

This is just the first step towards making the graphics compositor easy to customize and extend. Stay tuned for more changes in future releases!

Improved Visual Studio experience 🔗

We now have full support for Visual Studio 2017!

Xenko Visual Studio extension now supports Visual Studio 2017
GameStudio recognize Visual Studio 2017.
Games can use C# 7.0, and our script editor can recognize C# 7.0 and offer C# 7.0 refactoring thanks to Roslyn (you need to make your solution VS2017+ for it to work).
Our internal AssemblyProcessor which perform various operations on generated assemblies can now work with portable PDB (as generated by .NET Standard projects)

Programmers working with Xenko often go back and forth between Game Studio and Visual Studio. To make their lives easier, we made a few key improvements to the Xenko Visual Studio extension:

You can now open the current solution in Game Studio directly from Visual Studio.
Syntax highlighting didn't behave well when switching theme.
Previously, when assets are compiling, MSBuild didn't report any progress until finished. It now displays information, warnings and errors while it compiles.

Also, our whole build infrastructure and script editor is now based on the latest version of MSBuild 2017 and Roslyn. Supporting the new VS2017 Project System with .NET Standard is just a few steps away!

Faster & Lighter 🔗

In order to provide a better experience for users, we've been working hard on various fronts to make the editor smoother and more responsive. This is still a work in progress and expect regular progress.

Also, package size has been almost divided by 3, resulting in much faster download and install time.

For the full release notes, see the dedicated page.

Add Xbox Live Service to Your Xenko Project

Thu, 09 Mar 2017 00:00:00 +0000

Discover how to integrate Xbox Live services into your Xenko game project with this step-by-step guide, enhancing player experiences and social features.

We have continued to work hard on our support in Xenko for Microsoft's Universal Windows Platform (UWP). Keeping with this, we've been working closely with our Microsoft partners to add official support for the Xbox Live SDK. So, now Xenko developers will have the opportunity to add Xbox live to their games.

What is the Xbox Live SDK? 🔗

The Xbox Live SDK is a set of APIs that power all social interactions on Xbox Live including friends, achievements, and multiplayer. Started originally on XBox, the service is now available on multiple other platforms.

It is available on nuget.org for registered ID@Xbox developers.

If you haven't yet joined ID@Xbox you can learn about the program and how to join here.

Once you have applied to the program and have been accepted as a managed partner with Microsoft, feel free to get started using our newly created Xbox Live sample here.

We hope you will give this a try, and let us know about your project! Feel free to leave any comments or suggestions below on how to improve the experience.

Release and Pricing Information

Fri, 03 Mar 2017 00:00:00 +0000

Explore the latest release details and pricing information for Stride 3D, the versatile game engine designed to power your creative projects.

We are pleased to announce that Xenko will exit its beta stage on April, 2017 with the first commercial version of the engine!
As we're still finalizing last details, the exact pricing model of the engine will be announced on the release day.
We can let you know that:

We are planning to switch to a monthly subscription model with several tiers (education, indie, etc.)
The tier intended for indies will be free to use
The code source of the runtime will remain available for everyone
The code source of the editor will be accessible only to the upper tiers
We will move from GPL to a custom license allowing developers to modify the engine without having to open their game sources
The beta versions will remain available to download for users already developing a game on it

We are thrilled to reach this next big step for Xenko and would like to particularly thank our users that have been working with the beta versions for the past two years.

We look forward to seeing all of your projects after release!

Xenko Exhibits and Official Release News

Wed, 22 Feb 2017 00:00:00 +0000

Silicon Studio is planning to announce the first official commercial release of Xenko at GDC! More details will be announced here in our blog in the coming weeks as well, so stay tuned!

We’re also excited to announce that Xenko will be in two locations at GDC this year! We’ll be in the Silicon Studio booth, #624 in Moscone’s South Hall, and will be official sponsors at the IGDA Pavilion in the West Hall.

We’ll be showcasing two cool, new demo games from Xenko. We will have our new VR demo, “Cave of Surtr” which will feature interactive gameplay using VR controllers. We’ll also be showcasing our third-person shooter demo game, “Starbreach”. Members from Xenko’s dev and marketing team will be around both of our exhibiting locations, so come and visit; we'll be happy to answer any of your questions!

To schedule a meeting, contact us through our website or direct message us on twitter @xenko3d.

We hope to see you soon at GDC 2017 in San Francisco!

Real-Time Local Reflections Preview

Thu, 09 Feb 2017 00:00:00 +0000

We're excited to be working on Xenko's real-time local reflections feature, coming in Xenko's next release. Real-time local reflections are a great way to visually ground objects in a scene. They give your games richer scenes and increased realism in rendering.

Without local reflections

With local reflections

Where the local reflections effect is available, it replaces image-based lighting (called environment lighting in Game Studio). This has the useful side effect of darkening surfaces where the object meets other objects, similarly to ambient occlusion.

Local reflections are most obvious when they project bright spots onto other surfaces. The effect looks great in night scenes, which have high contrast, and in rainy conditions with lots of reflective surfaces and highlights. Notice how the vending machine lights are reflected in the ground surface in this screenshot:

In games without lightmaps or global illumination, objects don't interact with each other as they do in reality, making them appear as if they have simply been Photoshopped in. With local reflections, objects appear to be part of the world rather than having been placed arbitrarily. It makes scenes feel much more grounded, and gives objects a feeling of weight.

To create local reflections, Xenko reflects the current rendered frame on itself. The technique employs a Hi-Z trace as described in Yasin Uludag's essay "Hi-Z Screen-Space Cone-Traced Reflections" in the book, "GPU Pro 5: Advanced Rendering Techniques".

Essentially, the effect allows the ray steps during the marching phase to skip large amounts of space. When the ray hits hierarchical depth cells, the algorithm progressively refines the level against which cells are checked until it hits the finest level.

(Image courtesy of Yasin Uludag and Tomasz Stachowiak's talk on screen space reflections)

A series of later treatments generates blurriness to approximate how reflections behave on rough surfaces. We've managed to keep the time per frame relatively low (3ms at 720p on GTX960), but the feature works best on high-end computers.

Local reflections are a great tool to have in your kit, but aren't appropriate for every object. It's a screenspace effect, meaning it only reflects images that are already on the screen; it doesn't reflect objects that are off-screen or obscured from the player by other objects. Put simply, if the player can't see an object at that moment, then the object isn't reflected. This means local reflections work well in enclosed areas such as corridors and rooms, but less well in open spaces. They also work best on bumpy surfaces, whose chaotic properties hide imperfections in the reflection. They work less well on glossy, mirror-like surfaces, because you naturally expect these surfaces to reflect the whole world.

The local reflections feature will be released in Xenko soon. In the meantime, keep your eyes peeled for more upcoming features!

Some Basic Xenko Facts

Fri, 03 Feb 2017 00:00:00 +0000

Uncover fascinating insights and essential facts about the Xenko game engine, empowering your creativity and enhancing your game development journey.

When looking at new game engines or software, it’s easy to get lost in feature details. So we thought we’d step back and take a moment to discuss some Xenko facts. If you are curious about the basics of Xenko, our in beta, open source, full C# game engine, this post will explain some of Xenko’s main characteristics along with system requirements.

Some of the benefits that Xenko brings users are its high-quality and flexible rendering, advanced C# scripting system, and upcoming VR support. Xenko’s editor, Game Studio, provides users a straightforward layout which allows users to easily start making games.

Xenko is still a relatively young game engine, and not yet as mammoth (or dare we say "brittle") as some of the more mature game engines that are commercially available. Being an open-source engine means that it's easy to customize, allowing users the ability to control almost every aspect of their development. It’s also worth noting that the Xenko engine itself is implemented in C# and always supporting the latest versions of C# and the .NET Framework. C# is the most widely used programming language among game developers, offering a great user experience when it comes to iterate on games quickly and efficiently.

With Xenko, you can currently develop games for the following platforms and graphics backends:

Windows (Desktop): DirectX / OpenGL / Vulkan
Linux/Mac: OpenGL / Vulkan
iOS/android (via Xamarin): OpenGL ES
UWP & XBox One: DirectX

You can learn more about supported platforms in our documentation.

Note: since the release of Xenko 1.9β, shared game assemblies are created using .NET Standard rather than PCL (Portable Class Library). You can learn more about why we made that decision in our earlier blog post, Toward a Better .NET!

You can currently develop games with Xenko only on Windows. We do not support Xenko game development on Mac yet.

For the system requirements, the Xenko install takes approximately 5GB and a minimum of 4GB of RAM; however 8GB of RAM is recommended for heavy 3D games or applications development. See Xenko’s development requirements for more details.

While the Xenko documentation is under way and improving daily, you may also find it beneficial to peruse our blog for each of our earlier beta releases to learn more on which features and techniques are implemented in Xenko. Of course, all of these features are in our documentation as well.

We hope this quick runthrough helped answer some of the fundamental questions we receive often about Xenko. Stick around for more news coming soon!

Feature Spotlight: Particle Effects

Wed, 18 Jan 2017 00:00:00 +0000

Dive into the world of particle effects with Stride3D's comprehensive guide! Learn how to create mesmerizing visuals in your 3D projects using particles, tips on optimizing performance, and inspiring examples from the industry. Master the art of visual storytelling with Stride3D

Happy 2017! 🔗

For our first post of the year, we're moving the spotlight back to a cool Xenko feature: particles. Particles are such an important aspect of almost every game and as a follow-up to our particles tutorial, we wanted to share with you a little more info about our particle system.

With Xenko's powerful particles system, you can implement effects like rain, explosions fire, smoke, electricity, magic spells, and lots more. Particles are a great way to bring your game worlds to life.

You can build particle effects completely inside Xenko Game Studio. Just add a Particle System component to your entity. The system is extensible, and any part can be customized in depth. And because Xenko is open-source, you can modify the code as you need.

Unlike legacy game engines, the Xenko particle system is modular: you add only the options you need, and remove anything you don't. This means no wasted CPU cycles loading effects you're not using.

To demonstrate how you can build particle effects from scratch in Xenko, we've put together a trail effect tutorial. Follow the steps to add a trail effect to a sword slash animation.

And to give you a taste of where you can go after that, here's a more elaborate trail that combines multiple particle effects:

If you'd like to see how this particular effect works, download the project file and take a look.

Don't forget, Xenko comes with some pre-made particles included as prefabs in the asset packs, too. To check them out, just select the Particles asset pack when you create a project.

We're really busy working on some important new features. Stay tuned for more news about what's to come.

Happy tinkering!

Happy Holidays 2016

Thu, 22 Dec 2016 00:00:00 +0000

Thanks for following us through another action-packed year of development. We think we've made some great progress on Xenko this year, and we hope you've made some cool stuff with it too.

Season's greetings from the Xenko team! 🔗

Exciting things are happening for Xenko in 2017, so stay tuned. Until then, have a great holiday season!

Back to Normals

Tue, 13 Dec 2016 00:00:00 +0000

Xenko 1.9.2β fixes an important issue with our normal maps. We have recently reviewed our normal map settings and shaders. Unfortunately, a lot of them cover cases that were previously missing or unclear, so automated conversion of the assets is not possible.

TL;DR 🔗

Set the Hint of your texture asset to Normal Map
In most cases, check Scale & Offset in your material
If your texture asset is Compressed, check Reconstruct Z in your material
If green colors in your normal map should be facing "up", check Y is up in your material

What are normal maps? 🔗

(Image courtesy of Julian Herzog shared under Creative Commons 4.0)

Normal maps are a way to simulate fine details in the surface of a mesh without relying on high polygon representation. When used in combination with lighting they produce believable image which appears fully 3D even on a flat surface.

Normal maps usually represent small changes of the normal vector (the vector which points out of the surface). Xenko Game Studio uses the most common convention, that the X and Y components follow the tangent and the bitangent of the surface, and the Z component follows the normal vector of the surface. This means that a value of (0, 0, 1) will coincide with the normal vector and will represent no change, while a value of (-1, 0, 0) will be strongly tilted to the "left", ("left" being negative X value in the tangent (local) space).

Settings 🔗

Texture asset 🔗

In additional to the common texture settings, there are a couple of options you should pay attention to when importing normals.

Hint 🔗

If you plan to use a texture as a normal map, this should be set to Normal Map. This makes sure that the texture is assumed to be in linear color space and gets converted to a format suited for normals.

Format 🔗

Compressed - Xenko will compress your texture in the most appropriate format for each platform. This will enforce some settings on the material side (see below). The compressed image will be unsigned, even if your input format is signed.
As-Is - Xenko will import the texture with the format you have supplied, as long as the target platform supports it.

Material Asset 🔗

In your Material properties, in the Geometry category, choose Normap Map as a Surface option. There are different input options, the default being texture. Select your texture and confirm the options below are correct.

Y is up 🔗

Normal maps represent vectors in tangent space. The surface's tangent is aligned with the horizontal texture direction and its bitangent with vertical direction. Depending on your normal map authoring tool and its settings, the bitangent is assumed to face either "up" or "down" the texture.

By default, Xenko assumes it is "down". Therefore, high green values indicate a surface facing "down". If instead your green values are supposed to make the normals facing "up", select this option.

Many tools, such as the Nvidia Normal Map Filter for Photoshop, let you customize the output by flipping some of the vectors. Please confirm which convention your tool uses.

Reconstruct Z 🔗

This option reconstructs the Z component from the X and Y components, assuming that X² + Y² + Z² = 1 and that Z is always positive, so that no normal vector can point to the back side of the surface.

This is necessary when storing normals in a 2-channel texture, throwing away the Z component.
Xenko might select such a format when you choose to Compress a normal map, so this option needs to be enabled.

Please note that this option will likely disappear in the future and be automatically inferred from the texture options and target platforms.

Scale & Offset 🔗

Most textures contain unsigned colors, meaning the red, green and blue channels are in the [0..1] range. However, normals require the signed range [-1 .. +1]. If your normal map is stored in an unsigned texture, this option will make sure that the values are properly scaled by x2 and then offset by -1.

Since normal maps are usually stored in unsigned formats, this option is enabled by default.
However, if you import your textures with the AsIs option and your input texture is signed, clear this option.

Future Plans 🔗

Some of the options, such as Scale & Offset and Reconstruct Z, can be automatically inferred from the texture format so they will likely disappear. Y is up will become an option of your texture asset.

Feature Spotlight: Archetypes, Prefabs, and Nested Prefabs

Wed, 07 Dec 2016 00:00:00 +0000

We released two really cool features, archetypes and prefabs, back in Xenko 1.6β. Open the post to see how these save our developers time.

Finding yourself constantly duplicating or updating the elements for your game? In Xenko 1.6β, we introduced archetypes and prefabs. These let you share properties between assets and elements of your games. Create reference assets and modular blocks for your scenes, embed them together, let Game Studio automatically update them when needed and save tons of time!

Archetypes 🔗

With archetypes, you can take an asset and derive a new asset from it. The new asset uses the original asset as the archetype, which means it shares its properties. If you modify the archetype, the derived asset also changes. This means that instead of editing each asset individually, you can edit the archetype and Game Studio automatically updates every derivative asset at the same time.

You can also override specific properties in the derived asset. These properties become specific to the derived asset. They aren't affected by further changes to the value in the archetype, but all other properties stay synchronized. This lets you create different versions of an asset that still share a common base.

Prefabs 🔗

Prefabs are an extension of the archetype feature. A prefab is a bunch of entities organized hierarchically with components like models, collider shapes, lights, scripts, and so on. Then you add instances of that prefab to your scene, just as you would with a model or other asset. This creates a copy of each entity in the prefab, with the same hierarchy, and links them to the corresponding entity in the prefab. Any change you make to an entity in the prefab is automatically applied to all your instances. Game Studio updates entities in real time, so you can see every change immediately.

The most common use for prefabs is to create a small piece of your world - like a car, a rock, a piece of furniture, an NPC, or whatever - and duplicate it as many times as you need. When you need to modify that object - for example, if you want to add a light or particle effect, or add or move its entities - you can do it in one place and Game Studio applies the change automatically everywhere at once.

You can change the entity hierarchy on the instance side without breaking the link to the original prefab. When you add an entity to the prefab, Game Studio adds it to the same parent or after the same sibling. If you delete the parent entity in the instance, Game Studio discards the entity. This means you can easily instantiate simple prefab subsets.

Override Prefab Properties 🔗

Of course, you can override prefab properties, just like with archetypes. Change any prefab instance and the change remains in that instance even if you then edit the original prefab.

Nested Prefabs 🔗

You can also nest prefabs inside other prefabs. This means you can build your project in a modular way. For example, you can create a room prefab, then use that to create a house prefab, then use that to create a village. Change something in the room prefab - like a piece of furniture - and the change appears in every house and every village where the room is used. Or you could create a basic prefab for every NPC, attach a script, then create variations to implement different NPCs: animals, monsters, AI companions, soldiers - whatever you need. There's no limit to the amount of prefabs you can nest.

Improve Performance With Prefab Models 🔗

If building everything at a detailed level with prefabs is affecting performance, Xenko has an experimental feature that lets you generate 3D models from prefabs. Just create a Prefab Model asset and drag your prefab into it. When you modify the prefab, every prefab model instance updates with the changes. We're extending the feature to physics colliders, and improving the workflow so you can group entities more easily. We’ll talk about that in a future blog post.

In the meantime, have fun with prefabs! They make managing your project a whole lot easier.

Newly Added Game Templates

Thu, 01 Dec 2016 00:00:00 +0000

With Xenko 1.9β, we’ve released our brand spanking new Game Templates! Super fun stuff, so open the blog post to see more!

Templates were designed to help bring your game ideas to life faster. With Xenko 1.9β you can now create a project more efficiently with our new templates, which will help kickstart your game development efforts!

We’ve started transitioning from small individual samples to more complete game templates and asset libraries to help you get the most out of Xenko. In the spirit of transitioning Xenko to an overall-game-dev-solution-provider, we’ve implemented templates for three popular game design genres - which you can now use as a starting point for your game.

The three templates we’ve added are:

First-Person Shooter 🔗

Arguably one of the most popular game genres today. Xenko’s FPS template helps our developers put together a game with a pre-set, first-person camera where you can shoot at the Xenko crates. The controls support both controllers and mouse/keyboard input. The crates come with physics' collider bodies and are fully interactive. The template also shows how to spawn particle effects alternating between bullet impact effect and a smoke trail depending on if you shoot a wall or a crate. Production quality model and animation assets make it easy to learn about controlling and switching animations.

Third-Person Platformer 🔗

This template is a great starting point for ever-popular platformer games. While the template is set in 3D it can be easily tweaked to become a 2D platformer. Just disable camera rotation in your 3D game to transform your game into a 2D platformer. Additionally, we’ve implemented a few techniques which we hope will be useful to you. Controls will now support both controllers and mouse/keyboard style input. The animation controller seamlessly blends the idle, walk and run animations providing striking visual feedback.

Top-Down Camera RPG 🔗

This template positions the camera at a fixed angle above the character and enables touch screen controls as well as mouse point-and-click, similar to many traditional RPGs. It also uses the Navigation Mesh feature so your character won’t get stuck in bad pathfinding or hit walls. On the game logic side, the template shows several kinds of interactions with game objects, like collecting coins and loot and attacking and breaking objects.

New Game Template 🔗

Our New Game template has access to existing production quality assets we used to create our templates! We have particle effects, physically-based materials, lots of animations for our new Xenko mannequin model and building blocks with physics ready for your rapid level prototyping. Unlike the templates, which are kept concise, the extra packages contain many more assets. You’ll even find some props which are not in the templates (swords for example!).

As always, we are committed to offering you best-in-class game dev solutions directly in Xenko’s Game Studio.

Additionally, we are looking to be able to give our users the opportunity to make their own templates that you will be able to share with other Xenko users. Of course, we’re planning on offering more templates as well. Keeping in line with our goal to become one of the best game engines for VR, we are also planning on adding a VR template in the not very distant future.

Do you have a template that you’d like to see on our Roadmap? Let us know in the comments!

Xenko 1.9 Beta Released

Thu, 24 Nov 2016 00:00:00 +0000

Xenko release 1.9 Beta introduces several major new features along with several relevant enhancements to existing features. We are excited to offer three new game templates to speed up your game design time, a brand new script editor as well as expanded copy-paste functionality and the last major new feature is our new Navigation Mesh system.

Highlights 🔗

Game Templates 🔗

We have added several templates packed with a lot of functionality to help you kickstart your games. Choose from:

First Person Shooter
Third Person Platformer
Top-View RPG

All of them come with basic camera and player functionality found in most games of their respective genres. They also have many production-quality assets so you can easily try different features on your own.

In addition to the game templates, the New Game project now includes optional packages with all the assets we used to build the samples. Unlike the game templates which are trimmed down, the optional packages include ALL assets, including some which are not used by any Xenko sample.

Script Editor 🔗

To ease friction from switching back and forth between the Game Studio and your IDE, we’ve built a new Script Editor. Relying fully on Visual Studio is no longer necessary because you can now edit your code directly within the Game Studio itself. You’ll get full syntax highlighting, auto-completion, live diagnostics and even the ability to auto-reload C# files and projects that changed on your hard drive due to changes in your external editor (e.g., Visual Studio).

In fact, expect:

Highlight, auto-completion and live diagnostics is available in the Xenko API, your own game code and libraries that you use
Auto-reload C# scripts and C# project changes that happened in the background
A Visual Studio like experience for all your code editing!

We had some help from Microsoft’s .NET compiler, Roslyn, so Xenko users will also receive the full benefit of all the latest features of .NET. Adding a Rosyln-based Script Editor makes it easier to keep up with the latest C# updates.

Using the Xenko Script Editor is fairly straightforward. Just follow these steps:

Create a new project/game in Game Studio
Add a script in Game Studio
Edit the script in Game Studio

C# scripts saved on Visual Studio side (or any text editor, for that matter) will automatically be updated in Game Studio without reloading. Same goes for project changes (.csproj): new scripts will appear automatically upon saving. GameStudio will automatically listen for file changes on the hard drive and update them live, or ask you what to do in case of conflicts.

In Xenko 1.9 Beta, you can create a navigation mesh powered by Recast and Detour with real-time feedback directly in the Xenko GameStudio! The navigation mesh is especially useful for RPGs or top-down strategy games, as you can use it to guide characters through complex scenes. The real-time feedback makes it easy to adjust and conveniently customize AI movement and the dimensions of the navigation mesh itself. The green outline of Xenko’s Navigation Mesh shows where the AI comes into play and where the colliders are set.

In the videos, you can see how the AI navigates the level using the logic within the navigation mesh, and how the colliders will automatically be set in real-time. Of course, you can script AI movement manually, too.

Copy & Paste Functionality Expanded 🔗

In the past we only supported copy and pasting of assets, but now you can copy-paste pretty much anything in the Game Studio.

Any entities in a scene are now copyable, as well as any sprites of a sprite sheet, UI elements, or even a single property in the property grid! For instance, you can copy a list and perform any of the following operations.

Insert it into another list at various positions, for example:

Copy and insert into the list (by pasting at a list item level).*

Copy and append to a list, for example, append it to the end of the list.

Copy and replace the whole list.

A bit more difficult to explain, but perhaps easier to show than write about is copy and replace at an item level. This action (shown in the video below) will remove the item (at its position in the list) and insert the copied ones starting at the same position of the item in the list. In our example below, the copy replace starts from Item 2 in List 2:

Some information about copying entities and prefabs:

An entire hierarchy of entities can be copied from one scene or prefab to another scene or prefab. Prefab instance will keep their reference to the source prefab as illustrated in the following example:

The prefab "MyHero" is copied into the scene. Links to the prefab are maintained.

It is also possible to copy a component from an entity and paste it into another entity.

Any property that can be serialized can be copied. You can copy something from one scene to another scene, from a sub-element in one scene to another scene and even from a scene to a text file, back and forth as needed. You can also copy simple values in the property grid (e.g., primitives such as int, vector3, string…) between separate Game Studio instances if that is something you find practical and useful.

Here’s an example of copying between scripts and transform entities in the GameStudio Property Grid:

.NET Standard 🔗

Starting with Xenko 1.9, shared Game assemblies will be created using .NET Standard rather than PCL.

It offers many advantages: much better API surface for the developer, improved forward and backward compatibility, reduced fragmentation, finer-grained modularity of the framework, easier to write cross-platform apps, more frequent updates, etc.

Newly created applications will target .NET Standard 1.4, but users are of course free to target a different version. Also, your existing PCL projects will still work as is, but we recommend you to update your projects to .NET Standard!

Assembly Reloading 🔗

Iterating on code is very important. So far, Xenko was supporting changes in scripts: as soon as you saved any C# file, Game Studio was offering to recompile and reload the assembly with the updated scripts. If there is an error loading the type, you can still edit other part of the asset, save it back while preserving the parts that could not be loaded.

In this version, we generalized the approach so that any type embedded in your assets can be reloaded! As a result, you can now implement your own classes for anything you want directly in your game or plugin assemblies, and keep editing them without restarting the Game Studio.

This includes renderers, material features, and will soon be extensively used in new assets.

Breaking changes 🔗

Windows Phone and Windows Store Removed 🔗

Windows Phone and Windows Store platforms are both removed.
Please use the newer Universal Windows Apps (UWP) instead. This platform was previously known as Windows 10.
Projects will be automatically upgraded to reflect this change.

Also, we renamed preprocessor definition SILICONSTUDIO_PLATFORM_WINDOWS_RUNTIME into SILICONSTUDIO_PLATFORM_UWP.

.NET Standard 🔗

The switch to .NET Standard for newly created projects implies that:

Runtime .NET framework requirement when distributing your projects is bumped from .NET 4.5 to .NET 4.6.1.
You need Visual Studio 2015 to open and compile newly created projects
You can upgrade older projects to use .NET Standard using Visual Studio 2015 Update 3 (in project properties)
From version 1.9, we don't install prerequisites to compile PCL projects anymore. If you have somebody in your team still working on a project created with a previous version of Xenko on a fresh PC, please make them install Xenko 1.8 so that it installs the proper prerequisites (even if the project has been updated to a newer version of Xenko).

Asset Serialization 🔗

We changed how we serialize asset in YAML. We introduced new concepts that improve how we can track overrides between an archetype or a prefab and assets/entities inheriting from it. Although everything happens "under the hood", this is a actually a heavy change that might impact the upgrading of your project.

We removed asset upgrading for projects made with version 1.3 and below (released more than a year ago). It is possible that you experience some issues when upgrading a project made with versions 1.4 to 1.7, but you should properly be able to upgrade any project that uses version 1.8. However a few cases are not supported:

Dependency Properties of UI elements that are overridden from an UI library will be reset during upgrade. Therefore, properties such as Grid Column and Row will have to be manually restored.
Some case of overriden materials in the material list of ModelComponent might be improperly upgraded.

Dropping Support for Windows Store 8.1 and Windows Phone 8.1 🔗

To properly support the .NET Standard 1.4 and offer our developers a more up-to-date and robust API, we decided to drop support for Windows Store 8.1 and Windows Phone 8.1 platforms.

As Microsoft seems to be focusing on Universal Windows Platform (UWP), we’ve also decided it was best to refocus on more pertinent and relevant platforms for Xenko users. UWP was introduced with Windows 10, and a whole range of devices already support it.

Of course, you are free to stick with Xenko 1.8 in case you have a project targeting one of those two platforms -- we know this is a big change, and we will make every effort to help our developers with this transition. We apologize for the inconvenience, and aim to bring you a top-notch .NET user experience!

Just as a reminder, we already support Universal Windows Platform (UWP) on x86, x64 and ARM as of Xenko 1.8, which means games and apps developed with Xenko can be deployed on a whole range of Microsoft devices, including Xbox One. Until 1.9, this platform was named Windows10 in Xenko, but we took the liberty to rename it UWP to better match the official naming.

Changelog Version 1.9.0-beta 🔗

Release date 2016/11/24

Enhancements 🔗

General 🔗

From now on, new projects are created as .NET Standard projects rather than PCL projects.
NuGet restore is automatically run on projects having a project.json file
Bumped FBX SDK to 2017.0.1
Mesh importing now supports ByEdge smoothing which was previously ignored. If you notice any difference with vertex normals for your models please check your FBX export settings.
Prerequisites installer will ask for UAC once instead of many times, and perform a silent installation for all of the prerequisites.

Game Studio 🔗

Previously, when an EntityComponent (i.e. script) couldn't be loaded because game or plugin assembly didn't compile properly, we kept a Yaml representation of it so that it could be saved or reloaded after a code fix. Now we allow it to happen anywhere, so that you can use and/or implement custom classes for any type of the engine in your game/plugin.
Improve asset logs and errors to properly display failure/warning icon on all assets, including the one with icon-style thumbnails.
Improve loading/refreshing of assets in the scene editor.
Asset editors will display a * in the tab name when an asset is dirty.
Add editor for C# source code.
C# files and .csproj files are automatically reloaded as they are modified on hard drive (using a Yes, Yes to All, No, No to All dialog).
C# files have their own undo/redo stack
Add a Save All button that saves both assets and source code files.
The Game Studio now uses AvalonDock as docking system
Improve DPI support (#454 and #470)

Assets 🔗

Asset YAML serialization has been changed to handle overrides in collection in a better way. More scenario of overrides are now supported.
SharpYaml has been integrated into our codebase as SiliconStudio.Core.Yaml. Most of the duplicated types have been merged back in the SiliconStudio.Core.Reflection.
Assets don't use a ~Base section nor a ~BasePart.
Change Asset.Id to be of an AssetId type rather than Guid, to avoid invalid comparisons with other kind of ids.
Remove the Properties member of Package.
Introduce a new assembly Assets.Quantum
Overrides of properties is now handled using Quantum instead of ShadowObject.
Remove the asset diff/merge classes.

Engine 🔗

DataSerializers are now generated in a file with .pdb information, so that the user can debug them.
Add Local offsets to procedural models.
EntityComponent now implements IIdentifiable and has an Id property.

Audio 🔗

Add SetRange support to AudioEmitterSoundController
Improve compilation speed of audio files

Materials 🔗

Normal maps now have the option to Invert Y, supporting both textures where the green component is facing up or down

Particles 🔗

Minor optimizations around vertex buffer building
Add StopEmitters() method to the particle system, which prevents new particles from spawning without pausing the entire system

Physics 🔗

Add Cone collider shape.
Replace float with AngleSingle for MaxSlope of character controllers.

Issues Fixed 🔗

General 🔗

UWP platform now uses UniversalWindowsPlatform 5.2.2 (was previously 5.0.0).

Game Studio 🔗

Fix many issues with property overrides.
Fix many issues when setting/overriding materials in ModelComponent.
Asset logs were not properly sent forward to editor, resulting in an empty log for all assets.
Sometimes there was a deadlock when compiling effects due to the way we were using the thread pool and task continuations.
Fix performance issue that could occur when duplicating entities with the same name many times.
Fix 'Rename' menu entry when right-clicking a folder of the scene editor.
Fix crashes in the UI editor that could occur when deleting or moving an element.
Fix crashes in sprite sheet editor that could occur when deleting, duplicating or moving sprites.
Fix sort order of assets in the asset view.

Assets 🔗

Fix tangents of imported meshes, when transforms are negative along some axes

Engine 🔗

Several issues with spot lights were fixed, including shadow maps
Fix flickering of some materials when no ambient light is present
Fix an issue on OpenGL that caused low frame rates when using post effects, due to blocking GPU-readback

Animation 🔗

Fix a bug where an empty animation clip caused a crash

Known Issues 🔗

On Linux, when switching the underlying Graphics Platform, rendering will not occur or fail. Delete the cache, local and roaming folder on the Linux host and restarting the game should fix the issue.
Performance issues on mobile (being worked on)

Script Editor Preview

Fri, 18 Nov 2016 00:00:00 +0000

Switching back and forth between your game development editor and your IDE for small changes starting to wear on you? Well, you can look forward to losing many of those unnecessary steps because Xenko is bringing you our new Script Editor feature - available soon in Xenko 1.9 Beta. Open the blog post for the full details!

Feeling the pain of switching back and forth between the Game Studio and your IDE? We hear ya! We know how annoying it can be, so that’s why we think we’ll save you some time and frustration with Xenko’s Script Editor!

With our new Script Editor, relying fully on Visual Studio is no longer necessary, because now you can edit your code directly within the Game Studio itself! You’ll get full syntax highlighting, auto-completion, live diagnostics and even the ability to auto-reload C# files and projects that changed on your hard drive due to changes in your external editor (e.g., Visual Studio).

In fact, expect:

Highlight, auto-completion and live diagnostics is available in the Xenko API, your own game code and libraries that you use
Auto-reload C# scripts and C# project changes that happened in the background
A Visual Studio like experience for all your code editing!

We had some help from Microsoft’s .NET compiler, Rosyln, so Xenko users will also receive the full benefit of all the latest features of .NET. Adding a Rosyln-based Script Editor makes it easier to keep up with the latest C# updates.

Okay, so let’s get back to the important stuff, like how to use the Xenko Script Editor, which is fairly straightforward.

Just follow these steps:

Create a new project/game in Game Studio
Add a script in Game Studio
Edit the script in Game Studio
(Optional) Click “Reload assembly” when you’re ready

Under the hood, Rosyln is the underlying technology that can process your Xenko source code. But we didn’t stop there! We were fortunate to find AvalonEdit, which provided us what we wanted for the visual appearance of the UI aspect of the Xenko script editor. We also integrated RoslynPad, which connects Roslyn and AvalonEdit together. We were lucky to be able to take advantage of these great Roslyn related efforts, and appreciate all the hard work the developers and contributors have put into RoslynPad and AvalonEdit, further strengthening the .NET ecosystem.

Overall, we were extremely pleased with these libraries; thus the C# Script Editor was much easier than expected to build. And, since Roslyn is now integrated into our code codebase, it will allow us to do more cool stuff in the future, such as:

Code upgrades (i.e. if we rename members or refactor some classes, we could automatically update the code of your older projects)
Better code analysis

With Roslyn now integrated into our codebase, soon we’ll be able to share with you a pretty awesome surprise we have coming, so stay tuned for more info in the next few months!

Navigation Mesh Preview

Fri, 11 Nov 2016 00:00:00 +0000

The real-time feedback makes it easy to adjust and conveniently customize AI movement and the dimensions of the navigation mesh itself. The green outline of Xenko’s Navigation Mesh shows where the AI comes into play and where the colliders are set.

Toward a Better .NET!

Wed, 02 Nov 2016 00:00:00 +0000

We’d like to announce some of our plans for the coming months, and also notify our users of some big changes that will be coming with release 1.9. Namely, we’ll be dropping support for Windows Store 8.1 and Windows Phone 8.1.

Switch to .NET Standard 🔗

Starting with Xenko 1.9, shared Game assemblies will be created using .NET Standard rather than PCL.

What’s next? 🔗

Microsoft also announced many improvements to come in Visual Studio 15. Once it is released, we will also follow the trend by moving project.json information to .csproj.

We will probably change any newly created project to target .NET Standard 2.0, and the Xenko runtime itself will probably switch to the .NET Standard for easier portability.

Additionally, we plan to support C# 7.0 as soon as possible, and plan to offer CoreCLR/CoreRT runtime on more platforms as those two runtimes mature.

C# 7.0 and future versions focus not only on language usability but also on tackling some performances issues (ref locals, stack allocation, etc.), and since we’re making a game engine, we couldn’t be more happy!

Overall we are very excited with how dynamic the new .NET ecosystem is becoming, and we plan to consistently provide you with the latest .NET changes so that you can enjoy coding faster and better!

.NET future looks very bright, so kudos to Microsoft!

Bye Windows Store 8.1 and Windows Phone 8.1, long live Universal Windows Platform (UWP)! 🔗

To properly support the .NET Standard 1.4 and offer our developers a more up-to-date and robust API, we decided to drop support for Windows Store 8.1 and Windows Phone 8.1 platforms.

Copy-Paste Improvements Coming Soon

Thu, 27 Oct 2016 00:00:00 +0000

Discover the groundbreaking Copy-Paste feature in Xenko, designed to streamline your game development process. Learn how this innovative tool simplifies asset management, accelerates workflow, and inspires creativity in your projects.

We are working hard to add some important new features to our next release and we’re pretty sure you’ll be pleased with our improvements to the cut, copy and paste interactions, for one. Our development team is excited to offer you one of the most advanced clipboard support systems found in other game engines today. In the past we only supported copy and pasting of assets, but now you can copy-paste pretty much anything.

Any entities in a scene are now copyable, as well as any sprites of a sprite sheet, UI elements, or even a single property in the property grid! For instance, in our implementation of Copy-Paste, you can copy a list (assuming the type of values are compatible) and perform any of the following operations:

Insert it into another list at various positions, for example:

Copy and insert into the list (by pasting at a list item level).

Copy and append to a list, for example, append it to the end of the list.

Copy and replace the whole list.

Some information about copying entities and prefabs:

The prefab “MyHero” is copied into the scene. Links to the prefab are maintained.

It is also possible to copy a component from an entity and paste it into another entity.

In fact, absolutely any property that can be serialized can be copied. You can copy something from one scene to another scene, from a sub-element in one scene to another scene and even from a scene to a text file, back and forth as needed. You can also copy simple values in the property grid (e.g., primitives such as int, vector3, string…) between separate Game Studio instances if that is something you find practical and useful.

Here’s an example of copying between scripts and transform entities in the GameStudio Property Grid:

Look for this feature in our forthcoming beta release 1.9, coming soon. As always, we are committed to offering you best-in-class game dev solutions directly in GameStudio.

Run, Don't Walk

Fri, 21 Oct 2016 00:00:00 +0000

Embrace the power of efficient movement in game development with the "Run, Don't Walk" blog post. Explore tips, tricks, and strategies to enhance your workflow and optimize your project's performance using Stride 3D's innovative tools and features.

Not so long ago, I heard some advice about supporting new features in a game engine that I hear often: Walk, don’t run. Makes sense, doesn’t it? Developers and artists need the basics to make any game, namely, a stable, state-of-the-art rendering system with things like support for PBR, efficient use of lighting technology, a decent physics engine, a functional U.I. system, pipeline optimizing shortcuts, a way to handle coding frameworks efficiently and much more. However, even for a game engine that needs to accommodate traditional game deployment platforms such as PCs, console and mobile devices, game industry software tool development teams rarely follow any kind of linear or waterfall product management techniques. Agile methods have allowed product managers and teams to sprint to support certain higher priority features as needed, some market driven, some purely technically driven. Not surprisingly, this is the way the Xenko game engine effort is handled at Silicon Studio, which allows us to react quickly to industry trends. Such has been the case with virtual reality (VR).

The largest disruption to the whole walk, don’t run philosophy we’ve seen the last two years has to be, without a doubt, the race to prepare game engines to support development for VR. Staying current and reacting to key trends in both the end-user market and in game development has always been a part of Silicon Studio Corporation’s strategy. We’ve spoken with many game industry leaders, notable game developers, and attended key industry conferences, all the while - listening and learning. Most every commercial game engine (and even most non-commercial games) have decided to change direction and embrace VR because of the VR market’s rapid growth. We, as well, must be prepared for the next generation of gaming and interactive experiences.

We want to make it easy for you to follow this new trend in gaming with us, by offering you a truly VR-friendly game development tool. We know there are many new and improved features game engines need to be useful for developing games and apps in VR. Therefore, we have decided to change course somewhat for our Xenko game engine plans - before we even release version 2.0, while we are still young, nimble and in beta. We realize VR is disrupting the work of some (most?) developers, but we haven’t forget those folks not interested in VR. We’ll keep improving the engine for our non-VR game developers as well. This said, we think - in the not very long run - you will be pleased with how well Xenko supports your VR development. For one, we know it’s necessary to make our rendering pipeline more flexible - to meet the demanding needs of VR. Also, thanks to the rapidly increasing popularity of VR content creation and experiences, expect cool new features as well to help you get started creating VR content.

Therefore, we are now 100% on track to support VR in Xenko. So, what does this mean? First of all, the technology hints were in place before the decision was made in July. Important rendering, lighting, and audio features were already in place or planned to soon to be in place. For instance, Forward Clustered rendering, touted as the best rendering for VR, is now supported, our support for Oculus Rift is in place, our performant multithreading and back-end support of next generation APIs such as Vulkan smooths the way for AAA style VR games needing the best possible performance, and last but not least, we are working on adding HRTF support to our audio system to accommodate a sense called proprioception, necessary for a true VR audio experience.

In conclusion, let’s not bury the lead here: the game industry disruption caused by this race to widely support VR, trough of disappointment or not, is the reason why Xenko is now on track to become the first built-from-scratch comprehensive VR engine for game developers.

Xenko 1.8 Beta Released

Wed, 31 Aug 2016 00:00:00 +0000

Xenko release 1.8 introduces three major new features along with several relevant enhancements to existing features. We are proud to be able to offer you our new UI Editor, enhanced performance via our newly multithreaded engine with Vulkan support and our new Prefab Model. Also, for your cutting edge rendering needs, we now support SSAO and cel (toon) shading!

Highlights 🔗

UI Editor 🔗

This release introduces new UI assets along with a brand-new UI editor, so that you can create amazing UI directly from the Game Studio!

The UI editor provides a full WYSIWYG experience. You can author the whole visual tree of your UI, edit the properties of each UI element (such as layout, background color, etc.) and preview its rendering.

Two new assets are available:

UI Page asset: represents a typical tree of UI elements that can assigned to the UI Component of an entity in the scene or prefab editor.
UI Library asset: represents a collection of UI trees (similar to prefabs) that can be reused by other UI Pages.
Both have runtime equivalents. UIComponent now expects a UI Page. A UI Library is useful to create or edit UI at runtime.

And since it is built on the same system as archetypes and prefabs, you can easily create shared UI parts, override some properties and have changes propagating automatically.

Performance 🔗

Multithreading 🔗

Many computationally intensive systems have been multithreaded. Expect a major increase in performance and better scaling to correspond with the size of your game! We have observed up to 6 times higher frame rates for heavily CPU bound scenes so far (on a typical 4-core CPU).

Parallelized code includes many EntityProcessors and almost every part of our recently rewritten rendering pipeline. On Vulkan and Direct3D12 this includes also recording of drawing command lists, giving them an edge over the other APIs.

Developers can find classes and utilities for concurrent programming in the SiliconStudio.Core.Threading namespace, e.g. Dispatcher.For(), which resemble the Task Parallel Library, but are more lightweight and tailored for work performed every frame in a game's update loop.

Over time, we will look into multithreading more parts of the engine, including independent subsystems, such as different phases of the RenderSystem and Scripts.

Prefab Model 🔗

The Prefab Model is a new type of Model asset that generates an optimized baked and merged single model from a prefab.

It merges meshes together by material and vertex layout. You can easily go from thousands of draw calls to one or two draw calls.

To use it, just create a new Prefab Model asset from the Game Studio and assign a prefab to it.
Make sure that the base prefab is just containing static entities as only ModelComponent types are merged.

Rendering 🔗

SSAO 🔗

Ambient Occlusion was added to the list of post-processing effects. The current technique implements Scalable Ambient Obscurance. It exposes a variety of options, including number of tap samples, intensity, tap radius and back buffer size.

It is currently part of the post-effect pipeline, but will later move to the lighting pipeline for more realistic rendering.

Cel Shading 🔗

Cel shading (or Toon shading) is now available as a rendering model with both Diffuse and Specular rendering options. The default implementation limits the light product to binary or 3-cuts discrete levels. You can also reference a ramp texture for better artistic control.

How To Upgrade 🔗

UI 🔗

The UIComponent RootElement property has been replaced with the Page property. It now expects an instance of the UIPage type. Scripts that were setting the RootElement property need to be updated:

// previous code (will not compile)
var grid = new Grid();
var component = Entity.Get<UIComponent>();
component.RootElement = grid;

// new code
var grid = new Grid();
var component = Entity.Get<UIComponent>();
component.Page = new UIPage
{
    RootElement = grid
};

Due to the slight API and behavior changes made to UI system, you might have to adapt some other part of your code. For example:

var text = new TextBlock();
var canvas = new Canvas();
canvas.Children.Add(text);

var position = new Vector3(0.0f, 1.0f, 0.0f);
// previously setting this attached property will also set Canvas.UseAbsolutePositionPropertyKey to false automatically
text.DependencyProperties.Set(Canvas.RelativePositionPropertyKey, position);
// now you need to set it explicitly
text.DependencyProperties.Set(Canvas.UseAbsolutePositionPropertyKey, false);
// note that using extension methods is the recommended way, and does all of that in a more concise way:
text.SetCanvasRelativePosition(position);

Changelog Version 1.8.0-Beta 🔗

Release date: 2016/08/31

Enhancements 🔗

General 🔗

Added a DebugConsoleSystem to be able to print basic debug information in game.
Added Utility methods FindChild and FindRoot to Entity.
Animation blend trees can now be created in script. The AnimationBlend pre-built script shows how to do it easily
Updated Roslyn to 1.3.2

Assets 🔗

Yaml scene files now encode entity and component references in a much more compact way
Yaml serialization order is now following class declaration order

Audio 🔗

Game studio side: added hard limits in Compression ratio, also now it is using a slider.
Added SetRange in SoundInstance to be able to set play range, it also enables seeking.
Added Position property in SoundInstance to be able to know the position in time of your playing instance.
Added PlayAndForget to AudioEmitterSoundController to play many instances of the same sound rapidly.
Added RequestedAudioDevice in AudioSystem to allow game code to select audio devices (Windows only for now).
AudioEmitterComponent now contains a dictionary of sounds that can be used from the emitter, those can be set from the Game Studio directly!
Game Studio sound preview now uses the internal engine, this means that you can directly preview the compression rate!

Graphics 🔗

CommandList can now compiled and executed
Constant Buffers are now uploaded in a single GPU Buffer and set with offsets on platform/API that support this mode
D3D12: reduced number of API calls

Game Studio 🔗

About Page accessible from Menu-->Help-->About.

Input 🔗

Added preliminary controller vibration support with Input.SetGamePadVibration

Particles 🔗

Particle rendering now uses the improved multithreaded pipeline, significantly speeding up the vertex buffer building.

Samples 🔗

Several samples have been removed. Particles and Physics samples have been greatly reduced and merged into only two, which allows the user to check more features with a single sample.

Issues fixed 🔗

Physics 🔗

Procedural models can now be used as a source to generate convex hull shapes.
We are now using the github version of Bullet Physics and actively cooperating with the project.
Fixed ColliderShape cached matrices computation.

Game Studio 🔗

Credential dialog will now save the credential settings when closing.
Credential dialog will not appear if you checked "Do not ask again".
Fixed hang when launching a Linux game remotely.

Breaking changes 🔗

UI 🔗

The UIComponent expect a UI Page in place of the previous Root Element property.
Most dependency properties were changed into regular C# properties, except the ones that are attached properties (such as the Column and Row attached property of a Grid).
In desktop, TouchMove event is also raised when no mouse button are pressed.
Default style of the UI has been removed.

Audio 🔗

Removed Play with boolean argument from SoundInstance, instead the same behavior will be achieved by using PlayExtended or Play.
Renamed IsLooped into IsLooping.
Deprecated: GetSoundController, AttachSound, AttachSounds, DetachSound, DetachSounds. Please add sounds now from the AudioEmitterComponent

Physics 🔗

Collision.Contacts is now an HashSet so access by index is not possible anymore, please use foreach or iterate them instead.

VR 🔗

Added audio, status and re-center support for Oculus Rift.

Known Issues 🔗

On Linux, when switching the underlying Graphics Platform, rendering will not occur. Delete the cache, local and roaming folder on the Linux host and restarting the game should fix the issue.
Linux Mono has some issue with the new effect compiler (since 1.7.5-Beta). Please use the "remote compiler" in the "package properties" (right-click on the package in solution explorer), or use Linux CoreCLR in the meantime.

Help Improve Xenko By Taking Short Survey! (Closed Now)

Mon, 25 Jul 2016 00:00:00 +0000

We’ve created a short, new survey, so that we can hear your thoughts and opinions about Xenko.

Link to new survey here: http://goo.gl/forms/2K33S9hg6rtuTRyu2

We are dedicated to continually improve Xenko, and eventually shape it into one of the best game engines to pick from for our awesome users. We will use your feedback to make Xenko a game engine that we hope you enjoy and find easy to use.

As always, thanks for your help and we look forward to hearing from you!

Xenko 1.7 Beta Released

Fri, 01 Jul 2016 00:00:00 +0000

We’ve got some big changes including Forward+, Vulkan, Linux, Audio and many GameStudio improvements! Unfortunately, UI editor and streaming couldn't make it in this release. We prefer to take little bit more time to polish them.

Highlights 🔗

Rendering 🔗

Forward+ 🔗

Xenko now features Practical Clustered Shading, a technique similar to Forward+ rendering.

It allows you to use many point and spot lights at the same time.
You will gain more control over the lighting of your scene by adding lights wherever they are needed.
It also works with transparent objects out of the box, just like ordinary forward rendering does.

If your game requires Direct3D10+ (or equivalent OpenGL), this will be the default setting - no changes needed! As a bonus, you'll see a decrease in compilation times and the number of shader permutations.

We also took this opportunity to rewrite most of our lighting code for improved performance and extensibility.

Vulkan 🔗

Vulkan joins our happy family of graphics platforms!
Experimental support has also been added for Windows and Linux. Android will follow soon.

Together with Direct3D12 and the recent overhaul of our rendering pipeline, this is another step toward preparing Xenko for the next generation of graphics. Stay tuned for performance improvements and hard numbers in the near future.

Try running your project on Vulkan by selecting it as the Preferred Graphics Platform in the Rendering Settings of your Game Settings asset.

GameStudio Improvements 🔗

Simplified Asset Creation 🔗

The workflow to create assets has been simplified! The new menu for asset creation contains multiple templates for each type of asset. You can now import assets from files more directly. With Xenko's efficient search function, creating assets should be faster and easier than ever!

Camera Preview 🔗

We've updated GameStudio's camera preview to now display only the camera currently selected. It also now displays the borders and the camera's name making it easier to see the camera and it's settings.

Drag & Drop Assets into the Property Grid 🔗

So far, you could drag & drop assets into your scene or the tree view.

New in this release, components can now be added to entities just by dragging & dropping matching assets into the property grid.

Drag & Drop scripts 🔗

You can also drag & drop scripts directly into the scene, tree view and property view:

Linux 🔗

Linux users rejoice! Linux is now a supported platform of Xenko among Windows, Android, iOS, and more! All you need is a PC running Linux Ubuntu 16.04 x64 or equivalent with a video card supporting OpenGL 4.2 or Vulkan 1.0. Mono or .NET Core (which need to be installed separately) will be powering your game.

In order to use the Linux platform, check Linux from the list of platforms in the GameStudio then compile.

Deployment to a remote Linux box is done via SSH when running your project from GameStudio.

To know more about our Linux support, read the Linux documentation.

Audio 🔗

We've rewritten our Audio engine. While most changes are internal, the public API has improved, and we are still working to make it great.

The SoundEffect and SoundMusic classes have been consolidated into Sound, also SoundEffectInstance is now SoundInstance. Sound formats are now converted using FFmpeg. Because of these updates, the range of supported formats has also improved.

Under the hood, the CELT codec (part of Opus) is now being used. We're delighted to say that performance has since skyrocketed! Music can now be mixed and crossfaded while streaming and decompressing directly from disk.

Xenko's API now builds on OpenAL for Linux/macOS/iOS, on OpenSLES for Android and on XAudio2 for Windows platforms.

Release notes 🔗

Have a look at the full Release Notes.

Xenko 1.6 Beta Released

Thu, 17 Mar 2016 00:00:00 +0000

Xenko 1.6.0-beta is now available, just in time for GDC 2016.

This release is a great step forward towards making the engine better to build awesome games.

Prefabs allow you to reuse assets and build game more efficiently. Particles are a critical requirement for many immersive games, and are now part of the engine with full editor support.

Lastly, we have done a full rewrite of our graphics engine, paving the road for better performance and scalability. We can’t wait to add many new rendering features on top of it! As a bonus, we included our experimental Direct3D 12 renderer.

This release consists of 2425 commits, with 135208 lines changed!

New Features Highlights 🔗

Prefabs 🔗

Prefabs allow you to assemble entities into building blocks and easily reuse them in any of your scenes. Changes to your prefabs will be reflected on all instances (as long as properties are not overridden).

We even took the concept one step further to empower our users, by having prefabs within prefabs, as well as the possibility to use only part of a prefab when you instantiate it. And of course, removing or rearranging a few entities won’t break your prefab synchronization!

Archetypes 🔗

You can now use any asset as an archetype for another asset. When you change a property of the archetype, the new value will be automatically propagated to all the derived assets, unless you specifically override them. Archetypes can be used with most asset types.

Particles 🔗

You can now create and edit particle systems directly in the Xenko Game Studio. Particles are deeply integrated in the game engine and leverage the powerful effect system and its high level of customization.

While there are still several features on the roadmap, the current implementation is sufficient for most games. The ability to customize almost all aspects of the particle engine allows you to add features tailored to your game’s specific needs.

Feel free to visit our particle documentation.

Features 🔗

The particle engine supports many features out of the box:

Render particles as different shapes like billboards, 3D oriented quads or your own custom implementation
Powerful force fields which offer more control than simple attractors and repulsors
Collisions
Animated attributes such as size, color, rotation
Flipbooks, UV animation and support for the Xenko Shading Language

Modular system 🔗

All aspects of particle systems are broken down into individuals modules like spawners, initializers and updaters, and each of these modules is easily tweakable and customizable. Check out the samples and the Xenko documentation for a detailed walkthrough.

Curve Editor 🔗

The Game Studio now also comes with a built-in curve editor. For now only the particle engine uses curve animation. In the future, it will also power our property animation system and our storyboard system.

New Graphics Engine 🔗

Most of our graphics pipeline, both low-, medium- and high-level, has been almost completely rewritten, and should be ready for the future.

The low-level API has been changed to more closely resemble DirectX 12 and Vulkan. For a list of breaking changes, please see below.

The high-level pipeline has been completely reworked, to achieve the following goals, most of which we will tackle in the upcoming releases:

Introduce a clean and extensible architecture to easily build new graphics features on (hoping to soon add a Forward+ renderer, IBL lightprobes, RLR, etc.)
New medium-level layer: lightweight RenderFeature, RenderStage, RenderObject, etc.
Easy for users to write small customizations (by implementing RenderFeatures)
Allow multi-threading of all parts of the pipeline
Make optimal use of next-gen graphics APIs
Reduce the amount of "magic" done by the effect system to increase performance
Minimize work by taking better advantage of different update frequencies (PerView, PerMaterial, PerLighting, etc.)
Take advantage of new API (first class support for Pipeline State Objects, Descriptor Sets, etc.)

Stay tuned for technical details and performance evaluation in the near future!

Direct3D 12 🔗

Direct3D 12 has been added as a new build target. While still experimental, it already supports all parts of our rendering pipeline.

You can try it by changing the ‘Preferred Graphics Platform’ in the ‘Rendering Settings’ of your ‘Game Settings’ asset.

Better OpenGL support 🔗

Our OpenGL renderer has been improved and should behave much better (shadows, PBR, etc.). Also, we now deliver OpenGL and OpenGL ES on Windows as build targets.

You can also try them by changing the ‘Preferred Graphics Platform’ in the ‘Rendering Settings’ of your ‘Game Settings’ asset.

Scripts are now components 🔗

So far, there could only be one component per type on an Entity. This was quite cumbersome, especially for scripts, which had to be stored inside the ScriptComponent.Scripts list. It also resulted in many special cases to make them work in the editor (i.e. references between scripts, assembly reloading, etc.).

Now multiple components of a type are allowed. This affects scripts and physics components, and can be used for custom components for which more than one instance is sensible.

We hope this makes your life easier!

Event system 🔗

We added a simple event system that will allow your script to easily communicate with each other.
Check out the EventKey<> and EventReceiver<> classes.
You can create an EventKey from your sender scripts and consume events using EventReceiver from other scripts.

Game Settings overrides 🔗

The Game Settings asset has been improved: You can now have different settings depending on the platform or GPU.

For example, you might want to set different off-screen resolutions for your game on Android depending on the GPU model. Or you could use one of our new Direct3D12, OpenGL or OpenGL ES renderers on Windows.

Version 1.6.0-beta 🔗

Release date: 2016/03/15

How to upgrade 🔗

Simply open your older projects with new version of GameStudio. It will probably fail to compile your assemblies since API changed little bit, but you can still continue.

Then, save back your project in GameStudio. You now can open your project with VIsual Studio and try to fix your game code with latest API changes.

Enhancements 🔗

Assets 🔗

Engine 🔗

The KeyedSortedList now implements ICollection instead of IList annd is more consistent with CollectionDescriptor.

Game Studio 🔗

Support for prefabs, add a prefab editor
Create derived assets and support property inheritance
Added a curve editor to edit animation curve
Layout is saved on a solution basis. When reloading a project, Game Studio will try to present the same layout and reopen all assets that were edited (this include scenes, prefabs and sprite sheets).
Add a confirmation dialog to enable saving newly created script automatically.
Add a confirmation dialog to enable reloading modified assemblies automatically. This is necessary for the script to appear in the list of components that can be added to an entity.
Physics gizmos are shown by default.
Preview of an asset can be displayed even if this asset is being edited.
Project folder can be opened in Windows explorer from the launcher with right-clicking.
Properties of derived asset are displayed in gray, unless they are overridden. In this case they are displayed in bold.
Rework scene initialization in the scene editor: the scene will be available almost immediately, and content (model, etc.) will be streamed in as soon as they are (asynchronously) loaded.
The entity fixup wizard has been removed. Now when an entity is deleted, all references to it or to one of its component is reset to null.
The gizmo and camera menus are now displayed in the top-right corner.
Entity hierarchy is synchronized (automatically expanded) with the selected entity in the scene.

Graphics 🔗

New D3D12 renderer (experimental)
New Windows OpenGL and OpenGL ES renderers (experimental)
Rewrote most of the low- and high-level graphics code to have better performance and better take advantage of new graphics APIs
Properly separated rendering in 4 phases: Collect (collect & cull), Extract (copy data from scene to renderers), Prepare (prepare cbuffer data & heavy computations), Draw (emit draw calls)
Introduced concepts of RenderFeature (entry point for extending rendering), RenderStage (effect selection), RenderView and RenderObject
Render sorting logic can now be customized (culling will be soon too)
Low-level API has been rewritten to match better new API: CommandList, DescriptorSet, DescriptorHeap, PipelineState, etc.
Introduced concept of RendererProcessor which are responsible for pushing component data to rendering
Many other changes, that will soon be covered in documentation

Input 🔗

Improved GamePad event management to resemble the keyboard API.

Issues fixed 🔗

Game Studio 🔗

Fix Scripts thumbnail generation during project launch.
Fix Settings window sharing columns layout with property grid (#341).
Fix default IDE settings incorrectly reset to null.
Fix a crash occurring when duplicating an object quickly after selecting it.
Fix an issue with the message box incorrectly resizing.
Tooltips are always visible even if the control (menu, button…) is disabled.
Fix several issues with undo/redo.
Fix drag and drop of components into properties
Sometimes the Game Studio was not asking to save when closed with some changes in a project.
Fix some issues related to folders in scene editor.
Redo does not re-open asset picker anymore.

Graphics 🔗

Tangents generation was invalid and might have resulted in various swaps

Physics 🔗

Improved collision detection reliability
Fixed collision filter groups
Fixed enable/disable component behavior

Breaking changes 🔗

Graphics 🔗

Extending rendering is quite different from before. Please check SpaceEscape and other samples to have a better idea while we prepare documentation.
Many methods of GraphicsDevice have been split off into a second class: CommandList
Added objects such as PipelineState, DescriptorSet and DescriptorHeap to better match new graphics API
Game now contains a GraphicsContext which gives access to the current CommandList
GraphicsDevice.BackBuffer and GraphicsDevice.DepthStencilBuffer are gone. Use GraphicsDevice.Presenter.BackBuffer to access the actual backbuffer.
In addition to RenderContext, there is now a RenderDrawContext. Some methods have been changed to expect the latter.
ParameterCollection has been rewritten to be much more memory and performance efficient (data is now stored directly in buffers).
Transferring values from application to shaders and computation of effect permutations used to be done through various inefficient ParameterCollection overrides. This should now be done using RenderFeatures.

Physics 🔗

PhysicsComponents are now split into 3 different types (Rigidbody, Character, StaticCollider) which can be added multiple times in an entity.
PhysicsElements are now removed, including the Collider, Rigidbody and Character classes. They now are merged into the new components.

Known Issues 🔗

iOS on ARM64 iPhones encounters crashes after a few second. We are currently investigating this.
Sometimes duplicate contacts are detected by the physics engine

First Fix Update of 2016!

Fri, 15 Jan 2016 00:00:00 +0000

Happy New Year's! We resolved to keep updating Xenko to give our users a polished, easy-to-use engine.

So for the beginning of this year, we are focusing on smoothing out some major issues reported by the community. As always, we really appreciate your input.

Async Debugging 🔗

There were some problems debugging async functions due to a problem in Mono.Cecil. We fixed that!

Now, you'll be able to look at local variables of any async functions. Also, the usage of the namespace in the watch panel is implicit and you can step over any await calls just normally.

Windows 10 Certification 🔗

We fixed several small issues preventing Windows 10 apps created with Xenko from being compatible with Store certification.

Now you can submit your awesome apps/games to the Windows Store. Can't wait to see your creations!

Skybox Compilation 🔗

Skybox compilation required a DX11 GPU (compute shaders) preventing some of you from using it.

We moved to a pixel shader version to ensure GameStudio works fine with older GPUs as well.

List of other improvements made 🔗

Fixed issues with displayed values of rotations changing after validation
You are now able to easily edit the 3 components of a vector simultaneously using the lock icon.
The convex hull generation is now working along with the new Skeleton Asset.
The Connection Router iOS script required to compile shaders on iOS devices has been fixed.
Added support for proper resizing in Windows Universal Apps.
Added support for OpenGLES devices that do not support packed depth-stencil-formats
Added the missing XenkoDefaultFont required by the profiler system.

Xenko 1.5 Beta Released

Thu, 17 Dec 2015 00:00:00 +0000

As promised in our last blog post, we have released some exciting new features for Xenko. This includes a new animations system, support of fbx cameras, a new search bar for the assets view, physics collider shapes at run-time, a simple performance profiler and much more.

New Features Highlights 🔗

Skeleton asset 🔗

A new Skeleton asset (*.xkskel) has been introduced. Both models and animations now hold a reference to a skeleton. This allows to reuse the same skeleton definition in multiple assets and to retarget models and animations to different skeletons.

Skeletons can be created alongside other assets, when importing an FBX file or other model format.

Root motion support for models, cameras, lights, etc. 🔗

Animations now apply root motion if they have no skeleton, or the ‘Root Motion’ property is enabled on the animation asset. The animation will then move the entity itself, instead of the skeleton’s root bone.
This is especially useful to import animations of lights, cameras or unskinned models, without the need to bind them to the bones of a skeleton.

The FBX importer will now also import animations of various camera parameters (near-plane, far-plane, field of view) and apply them to the CameraComponent of the animated entity. More properties may be supported in the future.

New animation update system 🔗

The animation system now internally uses a new UpdateEngine to update objects. This allows us to animate arbitrary properties of entities, while accessing them in a highly efficient way.
It will be the foundation for a future animation curve editor inside the GameStudio.

The new ‘Animated Properties’ sample demonstrates how to create animations of any property from a script.

Simple Profiling system 🔗

It is now possible to visualize profiling information of all the game systems and custom profilers directly within your running games.
To get started, use the Game Profiler built-in script, attach it to an entity and when the game is running press LCtrl-LShift-P.

Physic debug shapes at runtime 🔗

It is now possible to enable the rendering of physics collider shapes during runtime.
The debug shapes are normal entities and they must be enabled for each physics shape that requires it.
The best way to start with this feature is to use the Physics Shapes Render built-in script and attach the script to any entity that has a Physics Component and when the game is running press LCtrl-LShift-P.

Asset View 🔗

The Asset view has been improved to help you better organize and manage your assets.

The view options are gathered in a single menu accessible from the asset view toolbar.

You can display all the assets in the current folder only, in the current folder and its sub-folder. The third option let you display the assets and the sub folders.

You can also sort your assets by name, order, type or modification date.

New asset filter bar 🔗

With the new asset filter bar, you can filter your assets by name, tag, type or a combination of those. Each ‘filter tag’ can be disabled by a single click or removed from the active filters.

To add a filter, type in the filter bar and matching filters will be displayed. Click on the one you want to add it to the list of active filters.

Only the assets matching the active filters will be displayed in the asset view. Note that type filters are inclusive, while name and tag filters are exclusive.

Folder support in asset view 🔗

If the ‘Assets and folder in selected folder’ options is selected, the first level of sub-folder will be displayed in the asset view. You can drag and drop assets inside them. You can also copy/paste complete folder structure.

Copy-paste assets with their dependencies 🔗

You have now the ability to copy assets with their dependencies. To do that use the new entry ‘Copy with dependencies’ from the asset view context menu, or press Ctrl+Shift+C.

For example, if you copy/paste a model with its dependencies, you will get a copy of this model along with a copy of all its dependencies (skeleton, materials, textures)

Border and Center support in sprite sheet editor 🔗

For ‘Sprite2D’ sprites, you can move the position of the center by selecting the icon in the toolbar of the sprite editor. Grab and move the cross to the desired position.

For ‘UI’ sprites, you can change the borders by selecting the icon in the toolbar of the sprite editor. You can then resize each border (left, top, right and bottom) separately in the same way as the texture region, by grabbing and moving one of them. Note that the icon lets you ‘lock’or ‘unlock’ the sprite borders while resizing the texture region.

New built-in scripts 🔗

We added a few more built-in scripts with this release such as an FPS camera script and First player controller script. To use them, just click on “New Asset”, “Script source code”, select the desired script and attach it to an adequate entity.

Precompiled Sprite Fonts 🔗

Font rights are quite restrictive and it is quite common that only some persons of the project have access to the font files. This was preventing some people to build the game.
To solve this problem, we created a new type of asset, the precompiled sprite fonts. It is an asset taking as input an image and containing all the glyph information required to render the set of character specified. Inside your games you can used it exactly like a standard sprite font.
To generate a precompiled sprite font, the owner of the original font file just have to right click on an existing static font and choose “Generate Precompiled Font”.

That’s all for us this year, folks! Have a great holiday season, and we will be back early next year for the next updates on Xenko!

Note: For more details about the changes, see our Release Notes.

Huge Update! Paradox Name Change!

Tue, 01 Dec 2015 00:00:00 +0000

With the end of the year upon us, we are starting to get excited for Paradox’s official release for next year. With a new year comes a fresh start, so we’ve decided to update the Paradox name to more fully encompass what we think is great about our game engine and what direction we want to move toward.

New Name: Xenko 🔗

So, on to the big news! Paradox is officially changing its name to Xenko.
We wanted to show our roots a bit more since we are one of the few Japanese-based gaming engines.

Xenko was inspired by the Japanese word, Zenko 善光. The Japanese characters signify perfection and light. Sticking with the Xenko theme, we will strive to improve your experience with the Xenko engine (ah, feels good to say the new name).

We know this is a big change, and we truly appreciate your patience as we have been honing in on this transition.
Please note that support and download access to any previous Paradox releases will end on December, 25th, 2015.

We will also be releasing a new version that reflects the transition to the Xenko name. We invite you to download it here.

And before you ask, yes, this new release can be used without affecting the old Paradox releases and contains migration tools so you can continue to work on your Paradox projects with Xenko. The newest update is a transitional release, so it will be mostly similar to the latest version of Paradox (1.3.4) in terms of features.

New Features With This Release 🔗

Users Can Now Edit Documentation 🔗

We're so glad to have added this feature that allows users to share information about how to best use Xenko. We know our documentation is not entirely complete yet, so we are really looking forward to hearing and sharing information through the community.

The process for adding to Xenko documentation is real simple. ‘Improve this Doc’ in the top right hand corner and you will be able to edit our documentation. If the user-submitted information passes the verification process, we will add it to the documentation.

Automatic Symbols and Source Code Download 🔗

Being open source is great, but only if you can find the sources matching the binary version you are using. From now on, Xenko will download the right sources and symbols for an optimal debug and programming experience so you don’t have to worry about doing it yourself.

The process is simple. All you need to do is open Visual Studio options, go to Debugging > General, and check “Enable Source Server Support”:

Coming Later December 🔗

We currently are planning to release updates for the following features later this December:

New Animation System 🔗

We've added a new animation system that allows you to animate any game property throughout the engine. Animating models is great but why limit animation only to the models? With the newest version of the engine, you will be able to animate material color, UI transparency, and generally any property of your game!

Simple, In-Game Profiler 🔗

As good as a game engine can get, at some point, you're always going to be limited by the hardware's performance. To help with this, we've added a built-in profiler so that you will easily be able to identify problems and bottlenecks in your game. Even better, you will be able to turn on the built-in profiler at any point during the process of making your game.

Debug Physics Collision Shapes At Run-Time 🔗

Debugging physics is never easy. To streamline this, you will be able to display all the physics collision shapes at any time in your game.

Built-In Scripts 🔗

Writing scripts takes time and is not necessarily accessible to everyone. To improve on this, we added some built-in scripts to the engine so that users will be able to do basic operations with ease. Things like animating the camera, displaying physics debug shapes, and adding profiling information can be done in just a few clicks.

Xenko 1.3 Beta Released

Thu, 17 Sep 2015 00:00:00 +0000

We are proud to announce the release of a new version of Xenko, bringing lots of usage enhancements and many bug fixes - over 1000 commits since previous version! We have been working hard to bring to you most of the feature listed on our roadmap.

Also, if you haven't participate to our survey, please take the time to help us prioritize the features you need for your projects!

Assets 🔗

We have been improving many parts to smooth the management of assets in your project.

Faster compiler 🔗

In the previous version, asset compilation could take 5 seconds or more, even if nothing needed to be recompiled. Most of the time was taken by the JIT compilation and initialization of some types in the asset compiler. We have introduced a new compiler process that stays on flight and is able to respond faster to compilation requests. This process shuts down automatically after not being used for a while. This optimization is reducing the total time to recompile a project to less than 1 second, when nothing was changed. We are still looking to improve this compilation step a lot more in a future release!

Game Settings 🔗

A new mandatory "GameSettings" asset allows you to define the main properties of your game:
Default Startup Scene
Resolution
Graphics Profile (DX9, 10 or 11)
HDR or LDR mode
Color Space: Gamma or Linear (more details below)

It will automatically be created when opening an old project with version 1.3.

We plan to add many more options to this asset from now on.

Compilation control 🔗

Until now, all assets of a game package and its dependencies were compiled as part of your game.

Starting with version 1.3, we compile only assets required by your game. This makes game compilation much faster (especially if you have lots of unused assets).

Don’t worry, most of it is done automatically for you! We do this by collecting dependencies from the new Game Settings asset. Since it references the Default Scene, we can easily detect all the required asset references (Models, Materials, Asset referenced by your scripts and so on).

In case you were loading anything in your script using Asset.Load, you can still tag those assets specifically with "Mark as Root" in the editor.

However, we now recommend to instead create a field in your script and fill it directly in the editor. All the samples have been updated to this new practice, so please check them out.

Raw assets 🔗

We have added support for raw assets. You can now easily add your own config/xml files or load proprietary file formats. Raw assets are imported as-is in the game and can be accessed at runtime using the Assets.OpenStream(...) method.

Assets consolidation 🔗

We encourage users to organize their raw assets (such as FBX, PNG, JPG files) in a specific subfolder (just like the samples are doing it).

However, if you prefer to have your raw assets copied side by side with Xenko assets, it is now possible by checking "Keep Source Side by Side" on assets.

When doing so, source assets will be copied alongside the Xenko asset with the same name. Those changes happen when saving the project. In case some irreversible changes happen (i.e. delete or overwrite an existing file), a confirmation will be required by the user.

This option is still off by default when importing new assets, but we plan to make it a project setting if you want to manage project that way for your whole team.

Don’t forget to save new versions of your raw assets at the new location.

Rendering 🔗

Integration of SpriteStudio (OPTIX) 🔗

We added preliminary support for SpriteStudio animations and sprite sheet importing. At this point only few animation keys are supported.

Animation pipeline is very similar to a 3D model with smooth interpolations.

Check out our new Sprite Studio Demo in the samples:

Materials: Vertex stream, Shader nodes… 🔗

In addition to the current color providers supported by materials (texture, scalar, ...), we have added support for 2 new ones:

You can now use a color/values coming from vertex attributes/stream and use them directly in material color providers:

This allows for example to blend two textures in a diffuse material, based on the value of a color coming from the vertex buffer.

Also, you can use a shader directly as a color provider (inheriting from ComputeColor), allowing you to display procedural textures. For now, the list of shaders is not filtered so many shaders are not compatible with the material input. This is something that we are going to improve in a future release. Have a look at the Custom Material Shader sample to check, how this can be used in practice in your project.

Gamma vs. Linear and improved support for HDR 🔗

In the previous version, the rendering of all thumbnails and previews were neither HDR nor gamma correct. Also, working in linear space required to manually check sRGB mode on all textures of your project, which was quite cumbersome. There were also many places where the engine was not correctly distinguishing between gamma and linear space.

In this version, the engine is now able to fully support pipelines that are HDR and gamma correct. You can still switch to a LDR and/or linear color pipeline, if your game requires legacy color handling. Thumbnails and preview should now match the settings of your game (HDR/LDR and Gamma/Linear). At runtime, if a platform doesn’t support SRgb textures/rendertargets (used for gamma correct rendering), the game will switch transparently to gamma colorspace. On these platforms, the rendering will not be gamma correct.

By default, all new games are now created with Linear colorspace. This setting can be changed in the GameSettings:

The texture importer by default now automatically uses the color space defined at game level:

Sprites 🔗

Atlas generation 🔗

We have added support to create automatically atlas texture generated from sprite sheets. This feature is optional and the user can continue generating their atlas manually if they prefer. It supports sprite border size.

Alpha detection 🔗

We have also improve automatic alpha detection of textures and sprites. In addition to looking at the input file type and header, we are detecting actual data of the textures or sprites to detect alpha. This feature will be extended also to other types of texture formats (normal maps...etc.)

Sprite editor improvements 🔗

The sprite editor has been improved in several ways. First, the left pane now let you select the sheet type (sprites or UI) and the color key. To easily set the color key from the image itself, a color picking tool has been added. It is also possible to duplicate an existing sprite so you don’t have to enter the same parameters again and again.

Selecting the area of each sprite in a sheet can be annoying, so we added a magic wand tool to easily create a rectangle that fit the edges of the sprite you click on, using either transparency, or the color key to determine sprite limits.

Scene editor 🔗

We made several improvements to manage the hierarchy of entities. First, the root node representing the scene has been removed. You can now access the graphics compositor and editor settings via the Scene settings button.

Also, to help you sort and filter entities in your scene, we added the concept of folders. You can create folders either at root level, or inside an entity, and move other folders/entities into them. Folders are completely virtual and exist only at design time. The actual hierarchy of entities is not affected by them.

Aligning the camera along coordinate axes was cumbersome. We added a new nativation gizmo to the top-right corner of the scene editor, which allows you to easily rotate the camera around axes in 45° increments. Clicking on the center of the cube a second time, will switch between perspective and orthographic projection. Camera controls have also been improved when working in orthographic mode, to make it easier to move around in 2D worlds.

Finally, the camera menu has been improved to allow you to customize various options related to the editor camera. These options were previously available in the editor settings section of the scene properties. This section has been removed.

The material selection mode, introduced in the previous version, has been improved to allow you to perform close-ups on single meshes of a model. Hovering over the desired mesh and pressing 'F' while in material mode, will now center the camera on it.

Physics improvements 🔗

Physics support has seen a lot of improvements.
The physics system is now loaded automatically - no need anymore to load it manually from code.

Element types 🔗

Physics elements have been simplified. To reduce confusion between object types some element types have been removed/merged with others. Each element type is now represented by separate class (instead of having a type property). This provides a clearer abstraction and easier configuration from the editor. Physics gizmos are color coded by element type.

Linking to bones 🔗

You can now properly link physics elements to bones of a model hierarchy. This makes it possible to create ragdolls, flags, etc. from the editor. Searching for the correct node is assisted by the editor. No need to memorize the name of the node.
You currently still need to set up constraints programmatically. This will also be possible from the editor in the future.
Also, complex entity hierarchies are now well handled.

Async scripting for collision handling 🔗

Collision handling has been redesigned and now uses an async/await pattern. Events have been removed. Instead awaitable APIs are available, improving both internal performance and the readability of your code.

//start our state machine
while (Game.IsRunning)
{
    //wait for entities coming in
    await trigger.FirstCollision();

    SimpleMessage.OnStart();

    //now wait for entities exiting
    await trigger.AllCollisionsEnded();

    SimpleMessage.OnStop();
}

Collider shapes 🔗

You can now declare collider shapes right inside of a physics component, for increased productivity. These shapes will also be affected by the scaling of the entity. Using Collider Shape assets to share shapes among elements is still possible, of course.

A Convex Hull collider shape has been added, providing a shape that is shrink wrapped to a model. For more complex model, a shape is wrapped to each mesh. In the future we also hope to provide complex convex decomposition.

Manage code and scripts from Game Studio 🔗

Scripts are now a new special type of asset.

You can now create scripts straight from the Game Studio, without any need to have visual studio installed if wanted, Just fire your favorite code editor and start making scripts for your game!

Renaming/Deleting/Adding a script from visual studio will be detected after script recompile in the Game Studio.

Renaming/Deleting/Adding a script from the Game Studio will be detected after project save in Visual Studio.

For this release when you drag and drop a script asset into a script component the first script in the code file will get picked up. (this will be improved very soon)

Scripting 🔗

Script Priorities 🔗

Added Script.Priority, that allows you to control how a script will be scheduled each frame. Script will be executed by Priority order. You can change Priority of an already running Script during execution to control accurately the order of execution of your scripts.

Also, all SyncScript and AsyncScript are now managed in the same scheduler and priorities between them will apply (before, all AsyncScript were executed first, then all SyncScript).

Live Scripting improvements 🔗

After our first initial version, we tried to improve live scripting usability with two new features.

When running a game in live scripting while Visual Studio is started, the debugger will automatically attach to the newly started session. Note: Visual Studio might complain when you try to edit files. Disabling Edit & Continue of managed code will fix this issue.

During reload, you may want to keep some specific properties that are usually not serialized (public members with DataMemberIgnore or private/internal members). You can now use [DataMember(Mask = LiveScriptingMask)] on your script fields and properties to achieve this.

Last, GameStudio-side logging has been improved to better show what happens in the remote game process.

Model Node Link improvements 🔗

Model Node Link components allows you to make one entity follow a given model node or bone. They have been reworked and made easier to use.

Firstly, if now target model is set, they will now automatically use the parent entitie’s model. When editing the target node, the editor will now display a list of available model nodes to choose from:

Also, transformation is not ignored anymore. It is now possible to apply an offset, relative to the node.

Lastly, node link information is now visible in the scene tree view for easier discoverability:

Breaking changes 🔗

General: you now need to redistribute your games with VS2015 C++ redist instead of VS2013 ones.
Engine: When implementing a new entity component type, if you were using EntityComponent.Enabled, you now need to inherit from ActivableEntityComponent instead.
Engine: Script execution order was previously undefined but is now controlled by Script.Priority. Please make sure it didn’t affect your game.
Rendering: Remove post effect GammaTransform as the new pipeline is now using sRGB render targets for gamma correct pipeline.
Rendering: Remove LightShadowImportance. Switch to a single configuration done through the LightShadiwMapSize enum.
Rendering: Rename ILightColor to IColorProvider and move to namespace Engine.Rendering.Colors. Add extensions methods (github issue #296)
Physics: Collision events are removed. An async/await pattern is encouraged from now on.
Sprite Sheets: They are now automatically packed. If this affects you, you can simply disable this setting by editing your Sprite Sheet asset.

Version 1.3.0-beta 🔗

Release date: 2015/09/17

Almost 1000 commits are included in this release since the previous version of July. You will find more details in the following sections.

Enhancements 🔗

General 🔗

Switched Xenko to VS2015. You can still compile your games with VS2013, but you will need to ship VS2015 C++ redistributables instead of VS2013 ones.
Graphics platform is not part of user projects anymore, it is either automatically deduced and will likely be controllable from new Game Settings asset
Visual Studio Solution configuration is now switched automatically based on the startup project and vice versa.
On Android, we better detect ADB (check registry, running process before trying to find on PATH)

Game Studio 🔗

Removed the Code section of a package and merged its content into the package top-level
Animation preview now displays current time and duration of the animation, and has a proper scale under the seek bar
Add a button in the asset properties to open the asset editor when it’s available for this asset type (currently only for scenes and sprite sheets)
Some lists in the property grid can be reordered by drag and drop
File and directory properties now accept drops from Windows Explorer
Better handling of assets that can be edited, moved or deleted
Better placement of the checkboxes in the property grid so the indentation is not affected by the presence of a checkbox
The status bar now display background works, such as project build, thumbnail or effect compilation... and indicate progress and result
The output panel will display an asterisk when new messages are logged.
Scene editor: Add the concept of folders to sort assets
Scene editor: Removed the root scene node, and added a Scene settings button to access the scene properties
Scene editor: Add a navigation gizmo to easily reorient the camera
Scene editor: Moved all camera options into the camera menu of the toolbar and removed them from the Editor settings section of the property grid
Scene editor: The tree view will scroll automatically when dragging entities in a long list
Scene editor: Invert up/down and forward/backward keys when the camera is orthographic
Scene editor: Display list of model nodes when editing ModelNodeLinkComponent.NodeName
Scene editor: Display Model Node Link information in the scene tree view
Scene editor: Select newly created entities when dropping asset to the scene
Scene editor: Snap newly created entities when dropping asset to the scene if snapping is enabled
Sprite editor: Add a button to center the view on the current sprite region
Sprite editor: Magic wand tool to easily select sprite region. Works with either transparency or color key, support ctrl+click to include multiple partd in the same region.
Sprite editor: Add a color picking tool to select the color key
Sprite editor: Add buttons to cycle between the different sprite, with proper keyboard shortcut
Sprite editor: Add a button to duplicate the selected sprites
Sprite editor: Sprites can be reordered by drag and drop and can be dropped into a different spritesheet
Sprite editor: More options in sprite context menu
Sprite editor: Keep the position and zoom of the image when changing selected sprite
Sprite editor: Support DDS images (and many other formats)

Assets 🔗

Add ability to include raw assets in a game and loading them with the Assets.OpenStream API.
Background asset compiler for faster asset compiling tasks.
Added concept of "Root" assets (auto collect game assets, and user can manually mark additional ones)
Added a new undeletable GameSettings asset where you can configure various global settings.
Added a "Keep Source Side by Side" to force raw assets to be copied alongside their Xenko asset counterpart while saving.
Switch to FBX SDK 2016 when handling FBX assets

Engine 🔗

Added Entity.AddChild() and Entity.GetParent() extension methods (#251)
Added Script.Priority to give better control of script order of execution. Also interleaves execution of AsyncScript and SyncScript in the same scheduler.
If ModelNodeLinkComponent.Model is null, it now automatically uses parent model
ModelNodeLinkComponent now uses TransformationComponent values to applies an additional relative offset on top of the node transformation
Reworked transformation order so that it is easy to add new components similar to Model Node Link Components (i.e. Sprite link, etc…)
AnimationComponent.Play() now returns a PlayingAnimation, on which you can use await playingAnimation.Ended().
AsyncScripts now provide a CancellationToken that can be passed to async APIs to properly cancel them
AsyncScripts now also have a Cancel method to do synchronous cleanup
Before, every type of entity components could be disabled. From now on, they need to inherit from ActivableEntityComponent.
Added the possibility to reference audio and font assets from scripts
Unify API of collider shapes, procedural models and geometric primitives

Input 🔗

Added support for sensor input

Rendering 🔗

Shader material nodes as color providers are re-enabled in Materials. Refer to the 'Custom material shader' sample for details
Vertex stream in materials can be used as color providers.
Better support for ColorSpace (Gamme vs. Linear) throughout the engine
Improve ToneMap color transform, Add Hejl 2 tonemapping operator. Add AutoExposure/manual exposure and TemporalAdaptation flags.

Issues fixed 🔗

Assets 🔗

Obj + mtl file import support
Fixed .blend assimp import
Assimp imported meshes scale property support.
Custom assets are now loaded correctly when used in the package they are defined in (#280)
Local packages are now correctly loaded after their dependencies
If you use "Keep Source Side by Side" on assets with raw assets, they will be copied alongside the asset while saving the project

Build 🔗

Restored UserDoc functionality
Added support for user's native libraries

Engine 🔗

Fixed an issue when creating StartupScripts in other StartupScripts (#294)

Game Studio 🔗

Animation preview won’t freeze the Game Studio anymore
Display an error message if Game Studio was started in 32 bit mode
Previews and thumbnails now properly take skinning into account
SpriteFont can now be properly referenced in scripts.
There was some issues when importing shader log and undoing that
The layout of the Game Studio was improperly saved
Display properly the name of entities/sprites on the top of the property grid when something else than an asset is selected
Scene editor: Issues in camera control: LMB+RMB allows to pan the camera, fix mouse lock when using middle click, fix right-click on gizmos
Scene editor: Modifying a materials tessellation now properly updates the scene
Scene editor: Orientation of the camera gizmo was sometimes incorrectly computed
Scene editor: Transformations applied on a selection of multiple object were sometimes incorrectly processed
Scene editor: Duplication using Ctrl key while using the transformation gizmo
Scene editor: Prevent a crash that might occur when loading a large scene
Scene editor: Transparency was incorrectly processed in the camera preview

Input 🔗

Input: Properly detect HasMouse on Windows 10, Store and Phone platforms

Rendering 🔗

Fix ImageReadBack latency to force readback on first frame if previous frames were not available.
Ensure recursive materials are generating an log error instead of a StackOverflowException
Fixed issue where not all enabled lights would be rendered (#297)

Shaders 🔗

Swizzling scalars now works on OpenGL platforms
Display a proper error message when variables of different types have the same semantic (#197)

Samples 🔗

Fixed corrupted scene of the ‘Sprite entity sample (#281)

Known Issues 🔗

Rendering: Color used in SpriteBatch is not gamma correct and is considered as Linear It means that if you used a Color to modify a sprite with SpriteBatch, the sprite will appear a bit brighter.
Rendering: DynamicFonts are not yet gamma correct.
Rendering: Shadow maps are not rendered correctly with orthographic projections
Input: Windows Phone touch inputs are sometimes not consistent with other platforms.
UI: EditText is not implemented on Windows 10, Phone and Store

Rescue Drone: Tech Demo

Thu, 10 Sep 2015 00:00:00 +0000

During CEDEC 2015, we have published "Rescue Drone", a new real-time tech demo. It leverages on the latest rendering improvements made in Xenko, such as Physically Based Rendering.

Roadmap and Survey

Thu, 13 Aug 2015 00:00:00 +0000

Discover the latest Stride 3D roadmap and participate in our community survey to help shape the future of our open-source game engine.

Roadmap 🔗

We just published our roadmap online: view roadmap.

We are excited to share our future plan and work with the community.

You will be able to see the short term (few months) future plans relatively precisely, and some longer terms plans we have. The tag colors indicate progress on each features.

Our release cycle is once every 2 to 3 months, and we will try to include as many new features as we every time. Of course we will also release patches when faster fixes are needed.

We will keep updating the Trello roadmap on a regular basis an constantly tune it.

We are passionate about building this engine and prioritize features that makes it a great tool to make games.

Thus hearing the voices of our community is important. Please vote on the features and participate to our survey below!

Survey 🔗

We created an online survey that should take around 5mins to complete:

Participate to Survey (English)

Participate to Survey (Japanese)

Since we are constantly refining Xenko roadmap, having your opinion will help a lot to better fit your needs and to make Xenko better.

History and Daily Commits on GitHub

Thu, 30 Jul 2015 00:00:00 +0000

One year ago, we open-sourced Xenko on GitHub when we released our first beta. This allows our users to understand how the engine work, use it more efficiently, not be blocked by bugs and contribute with the development.

However, until recently, Xenko code was manually filtered and published to GitHub. The process was inefficient and time-consuming, resulting in delayed updates.

Also, since all commits were squashed, our community couldn't see code history, branches, commit messages, activity and daily improvements made to the software. Changes would only be visible after releases.

In addition, integrating GitHub PR and community activity back in our source tree was not well streamlined very well with our workflow.

We decided to spend some time automatizing this commit filtering process and applying it on the last year of history (since 1.0.0-beta01).

This history is now live on our GitHub repository, and you can expect almost daily commits from now on.

We are very excited to make our development more transparent and visible to the community!

This GitHub repository is now archived. You can access its successor, Stride, at this link https://github.com/stride3d/stride.

Xenko 1.1 Beta Released

Tue, 28 Apr 2015 00:00:00 +0000

Everyone on the Xenko team has been working hard to bring you new features and tools, including the Scene Editor, PBR, and PostFX. We are proud to announce that Xenko 1.1 Beta version is now available for download.

Highlights 🔗

Here are the new features on the new and updated version 1.1.0-beta:

Physically Based Rendering with Layered Material System
A brand new scene editor that is now the central piece of Xenko to assemble your game levels, test the rendering, script your entities.
Scene rendering compositor, offering a new way to define precisely how to render scenes in your game, apply post effects...etc.
Easy-to-use and powerful post-effects API coming along many built-in effects (Depth Of Field, Bloom, Lens Flare, Glare, ToneMapping, Vignetting, Film Grain, Antialiasing...)
New implementation of Shadow Mapping, supporting SDSM (Sample Distribution Shadow Maps with adaptive depth splits)
Scripting System, to easily add behavior and data to entities
In Visual Studio, when you edit .pdxsl shaders, there is now Error Highlighting and F12 (Go to Definition) to make shader editing as smooth as possible.
A new launcher, that can manage several versions of Xenko SDK side-by-side

We have been working to get as many mobile platforms to be included in this release but not all are fully supported yet. Some samples may not work yet so we ask for your patience. The whole team is hard at work to make sure that everything will work on the next update.

Details of upcoming releases will also be posted soon so please keep an eye on this blog!

Release date: 2015/04/28

New Features 🔗

Launcher: New launcher can now manage several versions of the Xenko SDK
Studio: Introducing a brand new scene editor
Studio: The scene editor is now the central component of the Studio
Studio: The asset log panel now display logs (errors, etc.) of the seleced assets and their dependencies
Studio: Packages now have properties that can be displayed and edited (to set the default scene and some graphics settings)
Studio: Editor and asset compiler are now x64 compatible.
Effects: New built-in post-effects: depth-of-field, color aberration, light streaks, lens flares, vignetting, film grain (noise)
Engine: New Material System supporting PBR materials, multi-layered materials with multiple attributes, including: Tessellation, Displacement, Normal, Diffuse, Specular/Metalness, Transparent, Occlusion/Cavity
Engine: New rendering pipeline compositor allowing to compose the rendering of the scene by layers and renderers
Engine: New Ambient and Skybox lighting
Engine: New light culling and object culling
Engine: New implementation of Shadow Mapping with support for SDSM (Sample Distribution Shadow Maps with adaptive depth splits)
Engine: New scripting system, to easily add behavior and data to entities.
Engine: New ComputeEffectShader class for compute-shader live compilation and dispatching
Engine: New entity background component to add a background in a scene
Engine: New entity UI component to add an UI on entities of the scene.
Graphics: Add a shared 2x2 pixel white texture on the GraphicsDevice (extension method)
Input: Add the possibility to hide and lock the mouse using LockMousePosition function
Mathematics: New SphericalHarmonics class
Physics: Renamed PhysicsEngine into Simulation, the engine now supports one separate Simulation for each scene.
Assets: New asset type RenderFrameAsset
Assets: New asset type ProceduralModelAsset

Enhancements 🔗

Assets: Yaml now uses a shorter qualified name without culture and keytoken.
Assets: Added AssetManager.Reload(), to reload on top of existing object
Assets: During asset compilation, improved logging to always display what asset caused an error
Assets: Assets can now have “compile-time dependencies” (i.e. when a Material layer embeds/uses another material at compile-time)
Assets: Add non-generic versions of Load and LoadAsync methods in the AssetManager
Assets: A Get method that allows to retrieve an already loaded asset without increasing the reference counter
Assets: An Unload method overload that takes an url as parameter instead of a reference.
Assets: Asset merging (reimport) is now more flexible
Assets: Add support for sRGB textures
Assets: Add support for HDR textures
Assets/FBX: Add better support for FBX scene unit and up-axis
Assets/FBX: Automatically generates normal maps if they are not present in a 3d model
Assets/FBX: Do not merge anymore vertices belonging to different smoothing groups
Build: Roslyn is now used to compile serialization code (instead of CodeDom)
Build: Improved logging of asset build
Build: Parallelization of the build has been improved.
Core: “Data” classes don’t exist anymore. Now uses AttachedReferenceManager to directly represent design-time and runtime representation of an object with a single unified runtime class.
Core: Add Collections.PoolListStruct
Studio: If an asset or one of its dependency has a compile error, properly add a failure sticker on top of thumbnail, and details in the asset log
Studio: Inside a scene, entities, components and scripts can reference each others.
Studio: If a script can’t properly be loaded (i.e. due to missing types), be nice and try to keep data as is for next save.
Studio: Reduce number of threads by sharing build system for assets, scene, preview & thumbnails (with priority management)
Studio: Shaders are compiled asynchronously (glowing green effect) and compilation errors will be visible (glowing red effect); various shaders are precompiled for faster startup.
Studio: Improved performance by using binary cloning instead of YAML.
Studio: Many visual improvement of the Studio user interface
Graphics: Add GraphicsDevice.PushState/PopState to save/restore Blend, Rasterizer, Depth states and RenderTargets
Graphics: Add Rasterizer wireframes states
Graphics: Add support for using new UserDefinedAnnotation for Direct3D11 API profiling
Graphics: Add support to generate additional texcoords from an existing vertex buffer in VertexHelper
Graphics: Add possibility to add a back face to the plane geometric primitive
Graphics: Add the possibility to bind TextureCube and Texture3D to the SpriteBatch
Effects: Infrastructure for recording shader compilations in a Yaml asset and regenerate shaders on different platforms (no UI yet)
Engine: The local transformation of entity linked with a ModelNodeLinkComponent is now taken in account in final world matrix calculation
Engine: Added ScriptComponent to easily add behavior and data to entities directly inside Xenko Studio
Engine: Materials are defined on Model, but can be overridden in ModelComponent
Engine: Add access to the SpriteAnimationSystem from the script context.
Mathematics: Add MathUtil.NextPowerOfTwo
Mathematics: Add Vector3 operators with floats
Mathematics: Add BoundingSphere.FromPoints from an native buffer with custom vertex stride
Mathematics: Add BoundingBoxExt for intersection between frustum and bounding box
Mathematics: Move all GuillotinePacker implementation copies to a single implem in Mathematics
Mathematics: Fix Color3 to Color4 implicit operator
Mathematics: Add Color3.ToLinear, Color3.ToSRgb, Color4.ToLinear, Color4.ToSRgb methods
Mathematics: Add swizzle extension methods for vector classes
Mathematics: Add explicit conversion method from Int3 to Vector3
Mathematics: Add MathUtil.Log2 method
Mathematics: Add extension method WithAlpha to Color class. It creates a transparent color from an opaque one
Physics: Added scaling parameter for Convex Hull Shape asset.
Physics: Added LocalRotation in collider shape asset description.
Physics: Removed Sprite workaround, added better default values to shapes.
VisualStudio: Improve highligting and navigation for pdxsl files
VisualStudio: Improve error messages when .cs file generation fails

Issues fixed 🔗

Assets: On OpenGL ES 3.0+ targets, HDR textures were converted to LDR during asset compilation.
Assets/FBX: Animation containing data for only some of the component the Translation/Rotation/Scale are now correctly imported
Engine: Correctly initialize transformation component rotation to the identity quaternion
Engine: EntityManager.Remove was destroying the hierarchy of the entity
Input: Fix the key down status when the game lose and gain focus under Windows
Input: Correctly translate control/shift/alt keys
Graphics: Implemented BlendStateDescription.Equals() and make a readonly copy of BlendState.Description.RenderTargets (so that user can't modify it). Fixes #139
Graphics: Various improvements and bugfixes to OpenGL renderer
Graphics: Add safeguard to avoid engine crashing when generating extremely big font characters
Graphics: Fix discontinuity problems in geometric primitive UV coordinates
Graphics: Fix crash when creating an unordered texture array of size greater than one
Graphics: Fix the calculation of Buffer’s element count on DirectX
Mathematics: Matrix.Decompose output now a correct rotation matrix free of reflection
Mathematics: Fix bug in Matrix.Invert when determinant was too small
Mathematics: Fix in Color3.ToRgb method
Mathematics: Fix bug in Gradian property of Angle class
Physics: Fixed PhysicsDebugEffect shader, debug shapes should now render again.
Physics: Fixed issues related to creating collider shape assets in the Game Studio.
Shaders: Add missing GroupMemoryBarrierWithGroupSync keyword to shading language
Shaders: Fix order declaration of the constants and structures in generated shader
Shaders: Remove generation of key for shader parameters with the groupshared keyword
Studio: Many fixes on the undo/redo stack
Studio: The build log panel gets the focus only once per build
Studio: Fix a crash when undocking the Asset log
Studio: The Studio now have a minimum size at startup
Studio: Some entries in the settings menu were not working
Studio: Fix the sound preview when the source file of the asset has been changed

Breaking changes 🔗

Android: Android projects should be compiled against Android API v5.0 (only a compile-time requirement, runtime requirement is still Android 2.3+)
Assets: The entity asset has been removed, entities should be created inside a scene.
General: Previous Xenko 1.0.x projects cannot be loaded in this new version
Engine: Deferred lighting was removed. We will later add support for Forward+ and Deferred GBuffer shading
Engine: ScriptSystem.Add has been renamed ScriptSystem.AddTask. Add is now used only to add scripts
Engine: Sprites of SpriteComponents are now rendered in 3D. Their size is defined by the scale of the entity
Engine: UI should be configured via entities and UIComponents and not via the UISystem anymore
Engine: VirtualResolution has been removed from Game and should now be set directly in the UIComponent
Engine: Direction of Oz axis have been inversed in the UI to have an RH space
Graphics: ParameterCollection are now grouped together in a ParameterCollectionGroup at creation time. This object can then be used in Effect.Apply().
Physics: Collider Shape Asset and Physics Component have been simplified, their asset version is now not compatible with the old version.
Physics: Debug shape rendering has been replaced by editor gizmos.
Shaders: Previous generated code for pdxfx is broken and must be regenerated
Studio: Changed naming conventions of imported assets.
Studio: The studio and asset compilation process are now running only on 64bits machines

Known Issues 🔗

Platforms: Shaders can’t compile due to lack of a proper workflow on other platforms than Windows Desktop (this will be fixed soon)
Platforms: Android and iOS platforms are currently not properly supported (this will be fixed soon).
Platforms: iOS x64 is not yet supported (this will be added soon)
Assets: Reimporting a Model asset (i.e. FBX) might have issues when merging materials
Assets: ModelAsset scaling and orientation works only for .FBX, not other formats supported by Assimp library
Studio: Scripts are not automatically reloaded by the editor. Closing and re-opening it is needed in order to see new scripts.
Studio: Renaming default scene won’t properly update reference. Please set again the reference in project properties.
Studio: DDS images cannot be viewed in the Sprite editor
Studio: Collections in assets properties cannot be edited nor displayed in multi-selection

Scene Editor and Advanced Rendering presented at GDC

Thu, 05 Mar 2015 00:00:00 +0000

We have been quiet for the past two months working hard on many new features in Xenko that we are presenting this week at GDC 2015.

A new scene editor
A new layered material system with physically based rendering quality
A new live scripting system, with a smart compilation reloading and hot-swapping of running scripts, using the Roslyn compiler
A simple and powerful PostEffects API coming along many builtin effects (Depth Of Field, Bloom, Lens Flare, Glare, ToneMapping, Vignetting, Film Grain, Antialiasing...)
A scene rendering compositor, a new way to define precisely how to render scenes in your game, apply post effects...etc.

All these features will be available in a new version in the coming weeks. We will need a bit more work after GDC to polish things, write proper documentation and add new samples so that you will embrace more easily all these new APIs. As this release is bringing some major changes, we had no choice than breaking some of the existing API, mostly related to the Entities and components, but you will see that It is coming with much greater benefits!

In the meantime, we are presenting some sessions here at GDC, but you can also grab our presentations here:

An overview of Xenko: A brief introduction of what is Xenko, new features and what is coming next (Download link here)
Advanced Rendering: Some details about the new Material System, the Post Effects API and the Scene Rendering Compositor (Download link here)
Beyong Uber Shaders: A sneak peek about the Xenko Shading Language (Download link here)

We will also release shortly a video showing the rendering of a Robot with the new PBR material system and post effects that we presented here at GDC.

Forums Opened, New Release With Image-Based Lighting

Tue, 11 Nov 2014 00:00:00 +0000

Discover the latest Stride release featuring Cubemap Image-Based Lighting and join our newly opened forums for discussions, support, and collaboration.

Forums 🔗

Due to popular demand, we have just opened a shiny new Xenko discussion forums!

We hope this place will become an important place for our community to discuss, help each other, collaborate, improve Xenko and show us some of their work.

Even though Xenko Team will follow discussions and might answer, we currently won't provide any official support here and might not answer your bug/feature requests (a forum is not well suited for that).

Please use Xenko GitHub for bug/enhancement requests, and our AnswersHub website for Q&A.

Cubemap Image-Based Lighting 🔗

Over the next few months, on top of working on a level editor, we also want to improve the rendering quality. We know Xenko can scale well from mobile to high-end and we want to prove it!

As part of this effort, this release includes image-based reflection lighting, with parallax correction.

It supports multiple cubemaps: they will be accumulated during a specific deferred rendering step, similar to prelight rendering.

Feel free to try it easily with a new dedicated sample, that you can create with only a few clicks inside Xenko Studio.

Spotlight Shadowmaps 🔗

On top of our already existing cascade directional shadowmaps, this release adds support for spotlight shadowmaps.

Improvements 🔗

We have done numerous bugfixes and improvements (see full details in changelog).

Amongst them are a new UI slider component, physics has been modularized, Windows Phone/Store support has been improved (PCL support, properly build packages), GameStudio property grid should behave much better, etc...

Version 1.0.0-beta03 🔗

Release date: 2014/11/11

New Features 🔗

Engine: Add cubemap components to place cubemaps in the scene or render them at runtime.
Graphics: Add skybox renderer from a TextureCube (similar to background renderer).
Graphics: Add cubemap reflections for deferred rendering.
Graphics: Support of shadow mapping in forward rendering for spot lights. Only 1 cascade is supported at the moment.
Samples: Add CubemapReflection sample.
Samples: Add spot light shadow in ForwardRendering sample.
Shaders: Add several cubemap shaders for sampling, reflection, parallax correction etc.
UI: Add new UI element: Slider
Website: Xenko Forums has just been opened. Feel free to use it to discuss about Xenko, help each other, collaborate and show off what you did with Xenko!

Enhancements 🔗

Studio: Property grids have been reworked to be more efficient and easily extendable.
Studio: Numeric input controls have been improved.
Physics: Physics assembly now depends on Engine (instead of the opposite). Soon Physics (and some other modules) will become optional.
Input: Allow emulation of several touch pointers at a same time with mouse different buttons.

Issues fixed 🔗

Assets: Fix shininess import from FBX files.
Core: EnumerableExtensions.LastIndexOf() wasn't working properly (#62).
Game: Properly support windows with height 0 when AllowUserResizing is true (#65).
Game: GameForm is created with a black background, to avoid initial flickering while Windows is being initialized (#54).
Input: Alt+F4 is now properly working on Windows Store/Phone platforms (#74).
Input: Properly maps all extended keyboard keys on Windows Store/Phone platforms (#84).
Input: Fix several crashes and bugs in GestureRecognizers and mouse button states.
Misc: PCL can now be used in Windows Store/Phone platforms (#72).
Samples: SimpleDynamicTexture was using expected screen size instead of actual screen size, resulting in incorrect picking in fullscreen mode (#75).
Shaders: Geometry shaders are forced to transmit SV_Position stream to pixel shaders.
Shaders: Compositions (especially arrays) couldn't be used in child classes of the one containing their declaration. Function and member calls weren't correctly resolved.
Studio: Fix preview and thumbnail of materials with normal map.
Studio: Fix binding errors in the property grid (#29).
Studio: Fix undesired hue changes and loss of precision in extremal values in the color picker.
Studio: Fix "Show in explorer" on assets.
UI: UIImage borders were not properly rendered when image had Orientation.Rotated90.

Breaking changes 🔗

Graphics: Remove Rotated180 and Rotated90C from ImageOrientation enumeration for code simplicity and efficiency purpose.
Graphics: Change ImageFragment.Region type from Rectangle to RectangleF and corresponding batch draw function API (SpriteBatch/UIBatch).
Graphics: CopyRegion now contains additional parameters for subresource indices and destination offset.
Graphics: RasterizerState and DepthStencilState constructors are now private to match other Graphics classes. static New() should be used instead (#83).
Physics: Physics engine initialization has changed since now Physics is a optional module. (please check updated samples)
Physics: Added Convex Hull simple wrap shape and complex decomposition as well.

Known Issues 🔗

Physics: Complex convex hull decomposition can be a very long process and there is visual feedback for it.
Physics: Convex hull shape debug shapes in game studio are not rendering very well, although the asset will be OK.

Xenko is Going Open Source

Fri, 17 Oct 2014 00:00:00 +0000

We are thrilled to announce that Xenko is going open source on GitHub. This is an important step toward the empowerment of game developers. We hope that this will make you more confident in using Xenko. You will have also an unique opportunity to contribute to the project and see by yourself how Xenko engine is working.

License 🔗

Xenko is now delivered with two licences types:

Binary Release version
Source version

Binary Release version 🔗

Xenko binary release (as distributed on our website, with unmodified signed assemblies) is under the "Xenko 1.x version" License Agreement.

It allows you to create games and distribute them freely and royalty-free, as long as you use the signed binary runtime.

Source version 🔗

Most of Xenko source code is released under the GPL v3 License (unless otherwise stated).
A few specific parts (stated explicitely in the source header) are released under MIT, CPL or Apache 2.0 (usually matching license of original contribution).
Some libraries (i.e. SiliconStudio.Core) will probably be converted to MIT later.

It means that if you use Xenko built from sources (either unmodified or modified), you must publish source of your game, as well as any changes to Xenko that you might have done (as per GPLv3 license).

Even for Binary Release version users, it allows to easily browse the sources and understand what's happening inside Xenko.

If you want specific license terms (i.e. use a modified and/or self-compiled version of Xenko for your project), feel free to contact us at contact@stride3d.net

Contributions 🔗

We gladly accept external contributions. Feel free to submit us pull requests and we will consider them for inclusion.

Contributors will need to sign electronically a Contributor License Agreement, available here (based on Harmony). It allows us to use your changes in the commercial version, and relicense code easily (in case we decide to go MIT at some point for example).

Otherwise you are free to fork, as long as you maintain GPL v3 License.

New Platforms 🔗

We are also pushing a new release 1.0.0-beta01. This release is most notably adding support for two new platforms:

Windows RT/Store
Windows Phone

It means that you can now target easily several major platforms:

Windows
Windows Phone
Windows Store
iPhone
iPad
Android Phone
Android Tablet

You will be able to upgrade the platforms on your existing project by simply using the contextual menu Update Package\Update Platforms on a package in Xenko Studio.

New Samples 🔗

We are also delivering 3 new samples:

SimpleTerrain that demonstrates how to generate an entity model/mesh at runtime by displaying a heightmap terrain
SimpleDynamicTexture that demonstrates how to dynamically upload CPU textures to the GPU
RenderSceneToTexture that shows how to render your models in a render target from another camera point of view and display in a texture

Roadmap 🔗

Towards the coming months, we are expecting to deliver lots of new features!

This is a short list of the things we have in the pipe:

A full scene editor
An improved animation system
Real-time dynamic scripting from Xenko Studio and Visual Studio while the game is running (on Windows, at development time)
Several advanced new rendering techniques and post effects.
Support for more platforms (OSX, Linux...)

As we have done so far, we will try to provide a sustained delivery of new versions, with lots of small fixes and enhancements along the bigger features, as soon as they are ready (even in an alpha stage).

At some point, we will open a user voice to collect your votes. Don't hesitate to post your thoughts on our answers hub!

Release notes 1.0.0-beta01 🔗

Release date: 2014/10/17

New Features 🔗

Assets: Materials can be compiled into a shader without being attached to a mesh. Use the key MaterialAsset.GenerateShader in your pdxfxlib file to allow this feature.
Engine: Add support for Windows Store and Windows Phone projects.
Misc: Assemblies are now all signed.
Studio: Create Windows Store and Phone Projects.
Studio: Deploy Windows Phone project directly from Game Studio.
Studio: Add and remove platforms of existing game. Force to regenerate platform specific projects.
Studio: Choose what platforms to create when starting from a sample.
UI: Add support for MouseOver on Windows (mainly MouseOverState property/event in UIElement)

Enhancements 🔗

Samples: Load material and lighting configuration for the stand in ForwardLighting and DeferredLighting.
Shaders: Incorrect shaders are no longer cached preventing NullReferenceException errors at compilation time.
Studio: Generated solutions are created with VS2013 as default.
Studio: The 'sprite' editor can now be used on UIImages too.
UI: Improve default design of Button and EditText.
UI: Make the EditText's caret blink and dissociate caret/selection colors.
UI: Add support for mouse selection in EditText on Windows.
UI: Create default design for ImageToggle.
UI: UIImages are now regrouped into UIImageGroup the same way as SpriteGroup. The runtime-time and assets classes share the same hierarchy.

Issues fixed 🔗

Assets: Orientation of meshes from the assimp importer is now correct (#22).
Assets: Mesh and materials are correctly associated during assimp import.
Materials: Material always contains a diffuse part even if their color is black.
Samples: Exhaustive shaders permutations for DeferredLighting.
Shaders: The default shader is correct even when there is no parameter to generate it (no diffuse, no specular...).
Shaders: Fix specular in deferred shading.
Shaders: Correctly rename class in AmbientMapShading.pdxsl.
Shaders: Fix issues related to geometry shader creation.
Studio: New LightingAsset asset can be created in GameStudio.
Studio: Unsupported assets are ignored when trying to be imported (#42).
Studio: Fix issue with asset thumbnails sometimes not being updated.
Studio: Some properties of the Material assets displayed with wrong/missing controls.
UI: Fix problem in Canvas MeasureOverride method when measured with infinite values.

Breaking changes 🔗

Assets: SpriteGroup asset field 'Sprites' has been renamed 'Images' (.pdxsprite files can recovered by renaming the field inside the file).
Assets: UIImage assets does not exist any more and have been replaced UIImageGroup assets. The old .pdxuiimg files cannot be easily recovered. The new .pdximage files can be easily created using the GameStudio 'sprite' editor.
UI: EditText's EditInactiveImage and EditActiveImage properties have been renamed InactiveImage and ActiveImage.
UI: Simplify ToggleButton. It now behaves like a Button with persistent states.

Known Issues 🔗

iOS: On slow phones, app might be too slow to start with Visual Studio attached (it gets killed by iOS). We will rearrange our initialization sequence.
iOS: Rebuild might sometime not use latest version.
Samples: Due to the way we now create platform-specific projects, samples specific icons on non-Windows platforms are currently gone. Later, a project setting page in Game Studio should make this setting available again.
Samples: Since there is no accelerometer Input API yet, Accelerometer sample is currently removed.
Windows Store/Phone: UI EditText and Game Resume/Destroy cycles are not implemented.
Windows Store/Phone: SharpFont.dll is still compiled against .NET 4.5 (might not pass certifications).

Xenko 1.0 Alpha Released

Sat, 06 Sep 2014 00:00:00 +0000

A new version is available for download. Run the Xenko Studio to download and install the latest version.

In Progress 🔗

General: Integration of Spine
General: Preparations for open-source release
Issue: Installed in c:\ProgramData (#2)
Issue: InvalidOperationException: No screen modes found (#7)
UI: Improve layout of GameMenu sample.
UI: Improve grid children measure process (fix some layout bugs).

Version 1.0.0-alpha07 🔗

Release date: 2014/09/04

Issues fixed 🔗

Studio: Exiting the Xenko Studio was generating errors.

Version 1.0.0-alpha06 🔗

Release date: 2014/09/04

New Features 🔗

Integrated release notes in the welcome menu
Welcome to the new workspace!
Integrate release notes in the new workspace
Engine: Reload automatically shaders at runtime when they are modified on the disk (Windows only)
Shaders: New DiscardTransparentThreshold shader. Set the threshold below the one a pixel will be discarded.
Shaders: New shaders dealing with normal and tangent skinning.
Materials: Add UseTransparentMask parameter key in material to disable alpha blending and use the alpha channel as a mask of the texture. Use AlphaDiscardThreshold parameter key to set the desired threshold below the one a pixel will be discarded.
Assets: Support for TGA and PSD files for textures.
UI: Add horizontally align text in EditText using property TextAlignment.
UI: Add mouse wheel delta value since last frame using property IInputManager.MouseWheelDelta.
UI: Add image stretch type StretchType.FillOnStretch and modify StretchType.Fill behavior (previous StretchType.Fill mode is now implemented by StretchType.FillOnStretch).

Enhancements 🔗

General: Visual Studio Express 2013 can now open Xenko Projects (with some limitations) (#4)
Engine: Change default Windows output type to Windows Application (#8): By default, a console is only opened when there is a message, assemblies are created in debug and the debugger is not attached.
Engine: Add anisotropic texture filtering on mobile platforms that support it.
Sample: AnimatedModel. Add lighting to the model. Use default Xenko pre defined shaders.
Sample: ForwardLighting. Add transparent meshes.
Sample: Set the same orientation for all samples on Android.
Studio: Modal windows are not displayed in the taskbar anymore
Studio: Improvement in the sprite editor: possibility to drop image files in the interface, improved region selection rectangle.
Studio: Performance improvement in the editor, particularly in the sprite editor
UI: Allow 0-sized strip definition in Grid.
UI: Allow mixing of relative/absolute element positioning in Canvas.
UI: Allow user to modify values of the UIRenderingContext.

Issues fixed 🔗

Build: Android project fails to build (#3)
Studio: GameStudio was using 100% of one CPU core (#1)
Studio: Splash Screen always on top (#6)
Studio: Fix GameStudio crash when importing assets using the add files button (#9)
Studio: Build log is now displaying build feedback
Studio: Fixed the Hue selection in the color picker
Engine: Reduce effect change detection footprint (for example when changing the lighting configuration of the scene).
Engine: Reuse rendering states.
Shaders: Fix incorrect normal and tangent skinning in shaders.
Shaders: Fix converter Hlsl to Glsl.
Input: Fixed InputManager crash when window size is reach 0.
Physics: Character Controller was not working properly on iOS.

Stride Blog is Online

Fri, 05 Sep 2014 00:00:00 +0000

Welcome to our new blog!

You will be able to get the latest news from the Stride Team about the development of Stride.

The Stride Team.

Stride Game Engine

Investigating SPIR-V for the shader system - Part 3

Preface 🔗

Why not using a library ? 🔗

The 3rd experiment 🔗

The tree 🔗

Scanning code 🔗

Building blocks 🔗

Abstractions 🔗

Benchmarks 🔗

Conclusions 🔗

Announcing Stride 4.3

Download and Upgrade 🔗

What's new in this release 🔗

What has changed since Stride 4.2 🔗

Bepu physics integration 🔗

Vulkan compute shader support 🔗

User-defined Assets 🔗

Ongoing efforts to build projects from Linux and Apple desktops 🔗

Efficient API to manipulate meshes 🔗

Open project with Rider and VSCode from the GameStudio 🔗

Interface processor 🔗

And more minor changes 🔗

Fixes 🔗

Also good to know 🔗

Funding and Resource Allocation 🔗

Call for Skilled Developers 🔗

Join Us on This Journey 🔗

Links 🔗

Acknowledgements 🔗

Long-time Stride supporters 🔗

Gold Striders 🔗

A Look Inside Distant Worlds 2: Developing with the Stride Engine

Intro 🔗

Engine and General Development 🔗

Why did you choose Xenko/Stride over other alternatives for Distant Worlds 2? 🔗

How much modification was needed to adapt the engine for your needs? How difficult was this process for the developers involved? 🔗

We noticed references to both Xenko and Stride in the build. Are there specific reasons older files were retained during the transition? 🔗

How frequently do you update the engine for your project? 🔗

Did you create issues on the Stride GitHub repository? 🔗

What were some notable technical hurdles in using Stride, and how did you overcome them? 🔗

User Interface 🔗

Which library did you use for UI elements in Distant Worlds 2? 🔗

What led you to choose the current UI solution over others? 🔗

Were there any features you found lacking in Stride for UI, and how did you address these gaps? 🔗

How is the research screen (e.g., item order, dependencies) created? Are these elements procedurally generated, or are they manually crafted? 🔗

How did you create the research graph, including arrows and other visual elements? 🔗

Artists and Asset Creation 🔗

How did the artists find the asset creation process when working with Stride? 🔗

What are their thoughts on the physically-based rendering (PBR) pipeline in Stride? 🔗

Did you encounter any challenges or limitations with shaders, and how did you address them? 🔗

Level Design and Prefabs 🔗

How was the level creation process using Stride for your team? 🔗

Was the Prefab system easy to use for level designers, and did it meet your expectations? 🔗

Did the component system in Stride prove to be intuitive for designers? 🔗

DLC and Content Expansion 🔗

Could you briefly outline the steps involved in creating a DLC for Distant Worlds 2? 🔗

How do you detect whether a DLC is installed or not for a player? 🔗

Performance and Optimization 🔗

The game achieves impressive performance, especially during large-scale fleet battles. How did you manage to optimize for several simultaneous battles, each with many ships and fighters? 🔗

Are there any specific techniques or approaches you'd recommend for simulating large-scale scenarios like fleet battles? 🔗

AI and Game Systems 🔗

Did you require any kind of editor extensions? How did you implement them? 🔗

Which serialization method did you use for saving games? Was it a database, YAML, or a mix? 🔗

What AI libraries did you use? What techniques were used for AI, such as for fleet formations, battle decisions, or engage/retreat behaviors? How was diplomacy handled? 🔗

Future Use and Recommendations 🔗

What types of projects do you think the Stride engine is perfectly suited for? 🔗

Are you planning to use Stride in the future, beyond maintaining Distant Worlds 2? 🔗

How can the Stride engine be improved to help the modding community? 🔗

Conclusion 🔗

Links 🔗

Investigating SPIR-V for the shader system - Part 2

Preface 🔗

How it works currently 🔗

The idea for SPIR-V 🔗

Implementation 🔗

The easy way 🔗

"I should rewrite it from scratch..." 🔗

Buffers and instructions 🔗

Generation 🔗

What is a `DiagnosticAnalyzer`? 🔗