Stride engine startup overhaul

[Doprez]

Is there a chance at Stride allowing a major change for how configuration is done? Specifically things like the graphics or windowing where there are a of of pre-processor commands to determine what the engine should use.

I personally despise if defs in code and would love to start switching things over to a more dynamic approach for example:
Texture.OpenGL.cs

#if STRIDE_GRAPHICS_API_OPENGL
/// <summary>
/// Abstract class for all textures
/// </summary>
public unsafe partial class Texture

to something like
OpenGlTexture.cs

/// <summary>
/// Abstract class for all textures
/// </summary>
public unsafe class OpenGlTexture : Texture

And then at run time I could make change to the GameContext or a new settings object that will allow the user to simply change the rendering backend with an enum or something similar to make it allow for users to add their own backends in the future. I was doing a ton of work trying to make the windowing more modular for users to take control through code and this was something that came to my mind as a possible change/improvement.

The above is a bit of a drastic example since I doubt graphics backends should change much in short periods of time but the ability to do so can still be useful for following the code path when debugging source in a less archaic way.

I fully understand that is would be a massive breaking change but I think the benefits will be huge for modularity, future plugins and code first approaches. I am also willing to take on this workload myself as a large task if it would be approved from a future PR.

Pros:

• runtime modularity
• easier to follow code paths for debugging
• possibility for injecting custom abstract classes

If this gets approved I will have the following steps laid out to get this started:
[] Gather specific examples like the above Texture change that would need to be mapped out and updated
[] plan out what a settings class will look like or what changes could be made to the GameContext
[] Start?

[Doprez]

Some more reasons I despise the current way of debugging and adding code was the following files:
GamePlatformDesktop.cs

Everything in the grey text loses code completion and any debug information. This would be fine if it was its own file but since it inherits from GamePlatform any changes there means I now have to change IDE context to be able to properly test.

GameWindowWinforms.cs

Same issues here but now with any changes to the GameWindow class and its the whole file that depends on this.

[xen2]

There is no way around the WPF/WinForms (except maybe splitting it in a separate dll), as it exists only on some platform.
However, that's something we could improve:

It is greyed out because default selected runtime is net8.0 rather than net8.0-windows7.0. I didn't check it yet, but maybe if we swapped the order in which we define the TFMs, it could select the net8.0-windows7.0 by default, which would be a much better choice for us to inspect code.

[Doprez]

Yeah, I was thinking of having different packages that included the needs for different Game startups or their window hosts.

In this scenario, I am ok with it being SDL. I thinks its the one that needs the most love currently. The complaint here was purely when modifying the inherited classes we would need to switch manually in order to properly test it which was mildly annoying

[xen2]

For the Graphics API choice, I agree it's a bit cumbersome to have all those #ifdef and target files (it caused us a lot of headache in the past).
Also, being able to switch dynamically has some advantages.

However, bringing everything as a dynamic choice also has some downsides:

• Code would have a lot of casts everywhere (basically, DeviceD3D11 would always need to cast Texture to TextureD3D11). All the graphics code would look a bit harder to read and work with.

• Perf issues due to all those indirection (I think it was quite bad on Mono mobile at the time we made this choice and mobile CPUs were not as good, it might be better now though). Kind of a waste, esp. on platform that have only a single graphics API (most of them).

• Runtime would be harder to trim (i.e. Windows version of the engine would need to embed OpenGL, D3D11, D3D12 and Vulkan bindings/code).

• Dynamic graphics API switching, while nice on paper, is

  • Very rarely switched by user, so not worth so much a huge dev/Q&A effort (as explained in next point)
  • Quite hard to implement in a real game (since everything needs to be destroyed and recreated, incl. any dynamic GPU buffer. They can't be copied easily like a framebuffer resize as they belong to different API. It is something that's hard to generalize and make automatic, not even considering side effects/bugs that will likely come up (possibly much later in the game, memory leaks, etc., and of course not much Q&A tested since not used much).

  So in practice, most games/software require you to restart in order to effectively switch API (this saves lot of dev time for a switch that is not frequent.) And this use case is something we could already support with current approach (we can easily do a Stride.Graphics.dll appdomain resolver to point to proper runtime based on user settings).

Anyway, I am open to discussion, but having worked on it, I wanted to highlights those points.

[Doprez]

I would have to lay out all of the changes required to understand better myself. I feel like we could "easily" get around the casting issue with the right design. Definitely easier to say in my head I'm sure.

The other 2 issues maybe could be resolved with requested but separate packages? Same as you said with the windowing stuff with different .dlls.

At this point the work is massive for a minor benefit without a full team lol. Ill leave this on hold for now but I will still try to see what I can do with the windowing at least since I feel like that work would be smaller and I have a better understanding of that currently.