Core renderer rewrite for stability and functionality

[Nebula-Developer]

Rewriting the renderer

Yoru Engine is in a complex state currently, where parts of the core logic are inconsistent, non-cross-platform, and the likes. The following classes are going to be targeted in a new branch for rewriting certain mechanics, the primary focus being more renderer-agnostic:

• Element - Needs complete rewrite
• Application - Missing event listeners
• Transform - Utilising System.Numerics Matrix4x4 or similar

New drawing system

Yoru Engine from heart was written with the purpose of targeting a SkiaSharp canvas across multiple platforms, allowing for consistent and straightforward drawing. This simplicity will remain, although Elements will no longer draw directly to a SkiaCanvas, but will instead send draw commands to a CommandPool (or something similar) to allow for dynamic draw command manipulation and switching. This renderer-agnostic method will bring more scalability into Yoru Engine, allowing it to spread to other renderers like SDL, Vulkan, etc.

More information about the CommandPool and future of elements, applications and renderers will be provided once there is a clear direction to take Yoru Engine in.

[Nebula-Developer]

After careful consideration, I've decided to keep Yoru Engine in line with SkiaSharp, meaning that all core functionality will pass through the library, but some logic (potentially matrixes) will be custom.

I will determine whether the idea of a CommandPool will still be used, as it is a difficult concept to intertwine with the current state of Yoru Engine.

[Nebula-Developer]

The first changes will consist of Appliation modifications and enhancements, mostly surrounding the event logic and configuration.

There are mostly two ways of doing this:

• Have a dedicated 'ApplicationConfig' class or similar which:
  • On load will apply the appropriate values
  • Stay as a property of the Application allowing for the values to change
• Have all properties be within the Application class

The style of configuration that will be opted for will determine how configuration is handled for other classes like Element, eg.

Additionally, an important change will be modifying how Transforms work, so that they are extensible and not restrained to a parent/pivot based anchoring system.

This will allow for more flexibility in creating GridElements, or just general elements that respond to their parent or children in different ways.