Progress Update: February 2019


Hi everyone, time for another progress update! Lets cover what has been going on with the project during February.

There have been significant developments on three different fronts: editor, C# scripting & networking. In particular:

  • C# scripting is functional! Support is preliminary but you will be able to load up your C# code and use it to start and control a bsf application.
  • Continued improvements are being made in the editor. Bigger features are the addition of the scene camera settings window, scene object icons, improved sprite texture inspector, improved managed object serialization and many stability fixes
  • Work has started on the networking system planned for v1.2 release. As the first step I’ve introduced a ‘null’ render backend to be used in no-window/no-GPU environments. I’ve also been doing considerable research and planning for the actual networking backend by investigating networking libraries as well as higher level game networking.

And there have been some bonus unplanned features, such as work on multi-scene support :slight_smile: Read down below for a more complete list.

Major additions (Framework)

C# scripting functional

C# scripting has seen the biggest bulk of work this month so far. The biggest changes were:

  • Script binding generator was modified so it can generate separate API for bsf and Banshee as there are some places where the two API’s diverge (although they are mostly similar)
  • Script and Mono libraries were modified so they can run as standalone runtime capable of loading and invoking C# code, which can then be used for starting up bsf
  • You can now run bsf from C#!

Note the C# support is preliminary, but if you want to try it out, you can follow these steps:

  • During CMake configuration set SCRIPT_API=C#
  • Build bsfSharpCore target. This will generate a managed assembly you can link your C# code with.
  • Create a new C# library project in your favorite C# IDE and link it with bsfSharpCore.dll assembly generated from theprevious step
    • The assembly will be in your build folder, under bin/Assemblies
  • Create a Program class with a static Start method, use bs.Application to start bsf similarly how you would do it in C++ (see below for a code snippet)
  • Build your C# library
  • Build bsfSharp target in bsf
  • Run the bsfSharp executable and pass it a path to your C# library
    • The bsfSharp executable will be in your build folder, under bin
    • It should look something like ./bsfSharp path/to/my/library.dll
  • If everything goes well a window should open
// Example C# code
using bs;

namespace bsfSharpTest
    public class Program
        static void Start()
            Application.StartUp(new VideoMode(1280, 720), "bsfSharp", false);

Do note this is very much preliminary C# support. The biggest missing features are:

  • C# documentation is missing. This includes both the API reference and manuals. Until we add it you can mostly follow C++ documentation and can probably deduce the C# equivalent.
  • Not everything is exported to C#. There might be some important stuff that’s missing. I’ll be exporting more to the scripting API as time goes on.
  • Debugging is not supported yet. You’ll need to Debug.Log() for your debugging needs for now.

Null render backend

The framework can now be initialized with no rendering backend (i.e. the ‘Null’ backend). This is useful when developing console applications such as tools for processing assets (such as the bsfImportTool, or running bsf in a server environment with no screen and/or GPU.

This is the first part of the ‘headless mode’ that will be included in v1.2 as part of the networking system. The full headless mode will also allow you to set null audio, physics and renderer backends. I’ll probably be adding a windowless mode as well, for running on systems that have a GPU but no screen (i.e. only render to a texture, or just run compute operations, such as for scientific applications).

To use the null backend, simply set RENDER_API_MODULE variable in CMake to Null. Your app should still run, you just won’t see any windowed output.

Initial multi-scene support

The goal of the multi-scene system is to allow you to have multiple scenes loaded at once. Each scene will be able to render to its own camera (or cameras), and objects from one scene will not physically interact with one another. This is particularly useful when developing tools which might have preview and helper windows and can be used for in-game purposes as well (e.g. a screen showing a camera of another scene).

In the current system each SceneObject has a reference to a SceneInstance accessible through SceneObject::getScene(). Ultimately you will be able to assign scene objects to different scenes, or load scenes directly.

The entire Physics system has been refactored to support this system, and as such the API for things such a physics queries has changed. Instead of executing queries from a global Physics object, you must instead do it on PhysicsScene object, which you can retrieve from SceneInstance object mentioned above.

Before you’re able to use the system I still need to add multi-scene support to the renderer, as well as higher level logic that allows you to load and assign scene objects to different scenes. But getting the high-level design ready and refactoring the physics system were the biggest steps in the process, and the rest should come soon.

Major additions (Editor)

Scene gizmo icons

Gizmo icons for camera and a light

Scene view now displays icons for objects that would otherwise be invisible, such as cameras, lights, audio sources and similar. This allows you to easily find them in the scene at a glance, and also select them by clicking on the icons. It’s a common feature which we didn’t have until now, and it’s nice to get it out of the way!

Scene camera settings

Scene camera settings window

Scene view camera now comes with its own Settings Window, allowing you to extensively customize how the scene view looks. You can change most of the options as on a normal Camera as well as a variety of other scene-view specific options.

This feature also required some improvements to inspector drawing, such as the ability to use auto-generated inspector GUI on arbitrary windows, as well as improvements to C# serialization, allowing you to natively serialize C#-wrapped IReflectable objects. These are things you can use in your own editor extensions as well, and will make future editor work much easier.

Special thanks to @jayrulez who got started with the initial settings window.

Sprite texture inspector

Sprite texture inspector with an animated texture

Sprite texture inspector was updated so it supports options for setting up sprite sheet animation.

A preview area has been added to view the final sprite texture, animated if possible. A similar preview area will ultimately be added to a majority of resource types (such as meshes, animation, audio clips and others).

Minor additions & changes

  • C# Material interface now supports sprite textures
  • Arrays as material parameters are now supported both in low-level API and high-level Material API
  • All RenderAPI capabilities are now enumerated and reported by a RenderAPICapabilities object, instead of it being done in various bits of the framework
  • GUISkin and GUIElementStyle are now exported to script via the script binding generator, removing the burden of maintaining the interface manually
  • Quadtree implementation by @paolopaoletto
  • Camera background color is now properly gamma corrected, resulting in more pleasing colors
  • Import options, render window descriptor and video mode structure is now refactored to be cleaner and avoid many unnecessary setters/getters. They were also exported for use in C#.
  • Various additions to C# scripting math library by @paolopaoletto
  • Fixed C# namespace and project references to avoid confusing Visual Studio which was complaining about invalid namespaces and references, when in reality everything compiled
  • Better inspector layout for particle system and related types by using the new [Inline] and [Category] style attributes
  • EditorSettings & ProjectSettings can now save arbitrary C# objects, to avoid the cumbersome nature of requiring each field of a complex type be stored under its own key/value pair
  • IReflectable types wrapped in C# can now be serialized if they are referenced from managed code
  • Shaping library for BSL was added by @paolopaoletto
  • All Inspector fields now have readable names generated from their identifiers
  • GUITextureField can now accepts both normal and sprite textures
  • VectorField resource is now supported in project library, for use in particle systems
  • Much faster ProjectLibrary entry lookup due to multiple improvements, mainly to avoid slow LibraryWindow refreshes
  • 15+ bugfixes across both editor and framework

What’s next?

New editor release is still a priority, but most major features have been wrapped up. There are a few that remain and then there’s a lot of little fixes, polish and quality of life improvements to be done. I do have a bunch more features I’d like to add to the editor, but I’m trying to focus to first getting a functional version without cramming too many new features in (although it’s hard to resist!).

I’ve been trying to keep up on other parts of the framework while working on the editor, and I believe we’ve been having some nice progress on that front as well. You should be seeing a lot more work on the networking system coming up, as the more complex tasks in editor/C# scripting fronts are done.

C# is now functional meaning the bulk of the work is behind me. I’d primarily like to make improvements to the documentation so we have a complete C# API and manual documentation. I’ll likely be changing our documentation generator so we can get both 1. prettier manuals and 2. Multi-language (C++ + C#) manuals. This is going to be important for the editor as well, as we currently lack ANY editor documentation :frowning: .

And as always, some bonus feature will find it’s way to sneak in :slight_smile: Multi-scene support, BSL 2.0 are all at the back of my mind, as well as some totally new stuff such as improved font support and rich text boxes! But no confirmation on those.

That’s it for now. Thanks to everyone supporting the project, especially the Patrons, your support means a lot!