Remove bad statements |
Rewrite a bit |
||
| Line 1: | Line 1: | ||
(This article is written in past-tense even though the performance updates have not been released yet) | |||
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 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 Issue == | == The Issue == | ||
Prior to the issue being closed, the game used a single Unity process which ran [[FrooxEngine]] in a MonoBehavior (Unity component). | |||
The | The main issue with this was that if Unity crashed it would take down FrooxEngine with it. | ||
The game when running under Unity was using a C# runtime called "Mono", which was very slow. The | The game when running under Unity was using a C# runtime called "Mono", which was very slow. The performance updates would change the runtime to .NET 9. | ||
== The Solution == | == The Solution == | ||
Frooxius | Frooxius 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 FrooxEngine. | ||
These major Steps were: | These major Steps were: | ||
| Line 16: | Line 18: | ||
* Unity Connectors -> Inter Process Communication (Last stage and final release) | * Unity Connectors -> Inter Process Communication (Last stage and final release) | ||
These updates changed | These updates changed core components of the game, and allowed FrooxEngine to work as entirely standalone without relying on Unity for audio or particles. The game engines were then separated into two separate processes. Resonite now boots directly, and boots it's render engine as a separate EXE. FrooxEngine then sends data into a shared memory file, which the render engine accesses. | ||
This change allowed FrooxEngine (A now separate exe) to have it's code compiled into a new runtime (same code different executor). This marked a major turning point in the game, and also allowed for more freedom when making systems or new content. | This change allowed FrooxEngine (A now separate exe) to have it's code compiled into a new runtime (same code different executor). This marked a major turning point in the game, and also allowed for more freedom when making systems or new content. | ||
Revision as of 11:36, 11 June 2025
(This article is written in past-tense even though the performance updates have not been released yet)
The performance updates are a series of updates made to the game in response to Issue 706.
The Issue
Prior to the issue being closed, the game used a single Unity process which ran FrooxEngine in a MonoBehavior (Unity component).
The main issue with this was that if Unity crashed it would take down FrooxEngine with it.
The game when running under Unity was using a C# runtime called "Mono", which was very slow. The performance updates would change the runtime to .NET 9.
The Solution
Frooxius 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 FrooxEngine.
These major Steps were:
- PhotonDust (Particles update)
- Awwdio (Audio update)
- Unity Connectors -> Inter Process Communication (Last stage and final release)
These updates changed core components of the game, and allowed FrooxEngine to work as entirely standalone without relying on Unity for audio or particles. The game engines were then separated into two separate processes. Resonite now boots directly, and boots it's render engine as a separate EXE. FrooxEngine then sends data into a shared memory file, which the render engine accesses.
This change allowed FrooxEngine (A now separate exe) to have it's code compiled into a new runtime (same code different executor). This marked a major turning point in the game, and also allowed for more freedom when making systems or new content.