The Performance Updates: Difference between revisions

From Resonite Wiki
add page
 
Links
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
The performance updates are a series of updates made to the game in response to [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/706 Issue 706].
The main goal of the performance updates is to separate [[FrooxEngine]] from Unity so that FrooxEngine can benefit from a faster runtime in [https://learn.microsoft.com/en-us/dotnet/core/introduction .NET 9+]. In addition, this allows for easier switching to an alternate renderer in the future.


== The Issue ==
== The Issue ==
The game worked differently before the closing and conclusion of the issue. The game used a single process, that was started by the initalization of the UnityPlayer.exe file. This player would have a unity scene with a script in it that would boot [[FrooxEngine]]. FrooxEngine would be updated by this script every frame, and update things in the scene directly via monobehavior scripts.
Prior to separation, if Unity crashes it takes down FrooxEngine with it. Another problem is that Unity uses a slower runtime called [https://docs.unity3d.com/6000.1/Documentation/Manual/scripting-backends-mono.html Mono] which reduces the performance of FrooxEngine considerably, as it runs FrooxEngine inside of a MonoBehavior (Unity component). FrooxEngine also slows down Unity to an extent as well [https://discord.com/channels/1040316820650991766/1154514007479287942/1382658903682060288 (comment from Frooxius)]
 
The issues with this system were many. Unity is known as an unstable game engine that has many issues. These issues in the past would cause unity to crash outside of FrooxEngine's control (Often even when FrooxEngine wasn't even doing anything). This used to take FrooxEngine down with it, causing the entire game to close.
 
The game when running under Unity was using a C# runtime called "Mono", which was very slow. The idea of the update was to update the game to initally .net 8, but during the updates .net 9 came out and FrooxEngine's runtime was updated to that at the conclusion.
 
Before this series of updates, the game ran on average 15X slower.


== The Solution ==
== The Solution ==
Frooxius in response decided to create a series of updates that were separated into different parts. The main focus of the updates were to separate Unity and FrooxEngine by bringing things simulated partly by Unity fully into Resonite.
Frooxius has devised a series of updates to address this. Each stage brings more systems from Unity into FrooxEngine, allowing more control over them and lowering the dependency on Unity. These are pre-requisites for the separation.


These major Steps were:
The major steps:
* [[PhotonDust]] (Particles update)
* [[PhotonDust]] (Particles update) [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/587 Issue 587]
* [[Awwdio]] (Audio update)
* [[Awwdio]] (Audio update) [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/2430 Issue 2430]
* Unity Connectors -> Inter Process Communication (Last stage and final release)
* Process-based architecture (Inter-process communication) [https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/706 Issue 706]


These updates changed some core components of the game, and allowed FrooxEngine to work as entirely stand alone without relying on unity for audio and particles. The game engines were then separated into two separate EXE files or Processes. Resonite now boots directly, and boots it's render engine as a separate EXE. FrooxEngine then sends data into a shared memory section in the ram, which the render engine accesses.
These updates change core components of the engine, and allow it to work more standalone.


This change allowed FrooxEngine (A now separate exe) to have it's code compiled into a new runtime (same code different executor) and run 15X faster on average as a result. This marked a major turning point in the game, and also allowed for more freedom when making systems or new content.
The engines will be separated into different processes and communicate via a [https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files shared memory file]. Unity will still handle parts of the input, however its main function will be for the rendering.


== Resources ==
== Resources ==
<youtube>https://www.youtube.com/watch?v=9cx2-VtL_LM</youtube>
<youtube>https://www.youtube.com/watch?v=9cx2-VtL_LM</youtube>

Latest revision as of 13:45, 12 June 2025

The main goal of the performance updates is to separate FrooxEngine from Unity so that FrooxEngine can benefit from a faster runtime in .NET 9+. In addition, this allows for easier switching to an alternate renderer in the future.

The Issue

Prior to separation, if Unity crashes it takes down FrooxEngine with it. Another problem is that Unity uses a slower runtime called Mono which reduces the performance of FrooxEngine considerably, as it runs FrooxEngine inside of a MonoBehavior (Unity component). FrooxEngine also slows down Unity to an extent as well (comment from Frooxius)

The Solution

Frooxius has devised a series of updates to address this. Each stage brings more systems from Unity into FrooxEngine, allowing more control over them and lowering the dependency on Unity. These are pre-requisites for the separation.

The major steps:

These updates change core components of the engine, and allow it to work more standalone.

The engines will be separated into different processes and communicate via a shared memory file. Unity will still handle parts of the input, however its main function will be for the rendering.

Resources