Update platform support

[Doprez]

Something that bothers me is the supported platforms advertised on the website.

Windows Universal - Deprecated AFAIK which means no Xbox and hasnt worked properly since 4.0 and maybe 4.1
IOS/Android - I am not confident on IOS compatability and Android seems to have constant issues.
Linux - should probably be listed as experimental or list limitations at least(This has gotten a lot better with Jkaos work but still the graphics APIs seem to be fairly early/ unfinished)
MacOS - This likely hasn't worked since before the M1 chips have existed AFAICT

I know one of the issues is that people have not been around to confirm these still work but ever since the September boom there have been many findings posted in Discord and the Stride issues/discussions on problems found in 4.1+.

I would love to get some feedback on this as maybe some of these projects just need some updated docs or something but either way the average user will just get frustrated as they use Stride and find out things just do not work at all.

Linux limitations

I know about are primarily with shaders. Vulkan and OpenGL only work with Vertex and Pixel shaders and Jkao canprobably speak on some other errors.

SDL fullscreen does not work currently and maybe other issues not found?

IOS limitations

TBD? this may just not work at all from what I have seen in discord

Android limitations

Rendering API needs to be documented as to what works with mobile.
stride3d/stride#2239
stride3d/stride#1657
Other?

MacOS limitations

TBD? this may just not work at all with the current systems in place

[VaclavElias]

Related, and needs to be updated #116.

I can just agree. We must discuss this in our upcoming meeting. @tebjan, your input is also welcome.

@Doprez, probably, we need to ping more people to get a feedback for you.

[Doprez]

I couldnt ping them here but it would be good to get the opinion of Mehar for mobile issues and Jkao for more info on Linux. It would definitely be good to discuss this more I think and you're right, the community meeting would probably be the best place to bring it up.

[Jklawreszuk]

As for the UWP platform, it is worth to take a look at other projects : e.g. MonoGame
AFAIK Microsoft has put developers in front of the fact and the only transit option is to switch from UWP to MS GDK and add DirectX 12 support. However, user FLY1NGSQU1RR3L claims here that it is still possible to upload UWP games to Xbox - probably still the case .
So we can remove the current UWP support from the source code/docs/website, create a new feature request for GDK support, and/or recommend for current Xbox developers to stay at version 4.1 or lower if they plan to create a console game - for other platforms they should choose the latest version of course 😅
If no one is against it, I'll start creating a PR that will remove UWP. 👌

[Jklawreszuk]

As for Linux support, it is worth noting that Stride Engine consists of 3 components:

• Stride.GameStudio - Editor with GUI.
• Stride.Core.Assets.CompilerApp - Compiles assets.
• Stride.Engine - The actual engine / framework of the game. From it projects related to shaders, graphics, rendering etc. come out.

GameStudio

Due to the fact that the first versions of Stride were written in .NET FW, WPF was chosen here.
We should migrate from WPF to Avalonia - currently KryptosFR is handling this here.
Personally, if things move slowly, though I only know the basics of Avalonia I will be happy to help with the rewrite or even start off my own implementation.

We can add a note on the page/documentation that GamStudio is only available for Windows.

Apart from that, it would be useful to remove a couple of dead/or useless components in this editor such as:

• Metrics - I'm waiting for feedback, cause my PR is ready to be merged I think
• Stride Remote Debugger - Not available since Xenko 3.1, but its code is still there.
• Code editor

Also, there already completed Stride.Launcher avalonia port. Shouldn't we merge it into Master branch ?

Stride.Core.Assets.CompilerApp

Since my recent work, there is nothing to worry about here. However, if we want to support development on the Mac it would be worthwhile to add the missing libraries, but I do not have any Apple device to take care of this.

Stride Engine

It seems that both Vulkan and OpenGL apis have been severely overlooked over the years.
When it comes to OpenGL, most of the samples worked fine, except for games using the default skybox - It fails to compile Skybox asset

Eventually I managed to find a solution to compile them, but it fails compile shaders during runtime.
It is possible that HLSL is wrongly converted to GLSL. Glad to see that YKafia is working on SDSL to SPIRV converter directly which should reduce complexity and occurrence of bugs.

There is also an issue that crashes the app after few seconds if your game have TextBlock element (stride3d/stride#2189) - OS doesn't matter

As for Vulkan, more samples do not run - it's also likely that many shaders are poorly converted

---

Here is a brief summary of the current state of support for each platform

	Windows	Linux	MacOS	Android	UWP	IOS
Supports GameStudio?	Yes	No	No	N/A	N/A	N/A
Can compile assets?	Yes	Yes*	No, but only require few adjustments in source code	I dont tested yet on Linux, on Windows probably Yes	No, any platform	Need to verify
Can be run?	Yes	Yes**	Need to verify	Yes**	No, Unavailable since .NET 5	Need to verify

*Except Skyboxes, but that's the matter of OpenGL not CompilerApp itself.

**Assuming if OpenGL api is set (take a note it crashes if TextBlock is added). Not know about Vulkan.

[Doprez]

If no one is against it, I'll start creating a PR that will remove UWP.

Im in favour of removing UWP for 4.2. There have been a surprising amount of people in Discord asking about how to get it up and running with the disappointing realization that it no longer works.

Stride Remote Debugger - Not available since Xenko 3.1, but its code is still there.

Would the Stride Remote Debugger be related to running debug code on Linux or other platforms? I'm also guessing that its something that VS or Rider could do instead?

Code editor

I wouldn't mind removing the code editor but I think it would need to be replaced with an easier way to open a custom IDE when users double click scripts. We will also need to update docs if merged since this will become a very common new user question if clicking on scripts does not do anything.

Since my recent work, there is nothing to worry about here. However, if we want to support development on the Mac it would be worthwhile to add the missing libraries, but I do not have any Apple device to take care of this.

Would it be another topic to see about having a Mac environment that Stride devs could use? Would there be some sort of cloud environment that could be shared among specific devs or could we allocate some funds towards purchasing a base model for someone willing to work on this? This could be an interesting idea assuming we could have a way to securely share it to willing devs.

Also thank you very much for the fantastic response, these notes are insanely useful to have documented somewhere.

[MetalMaxMX]

Hello! I did asked about Stride on Avalonia port on here from @Kryptos-FR PR stride3d/stride#2034

Wondering how would the GameStudio be ported? What's the crucial functionality needed to get a port over there? Just wondering.

Cheers!
MetalMaxMX.

[Doprez]

The big main problem with the current GameStudio is that it is written in WPF, a windows only UI framework. There are likely also some odd scenarios where Gamestudio may be using Windows specific commands or folder paths but those should be relatively easy to find an alternative.
Essentially the entire frontend is the hold up that needs to be rewritten for the port.

Another thing that would be handy to get working is rendering the Stride game onto an Avalonia window for the scene view and the possibility of the game preview. I have dabbled with this a little bit but nothing that I would consider production viable in the current state.
Avalonia with stride rendered into it using the SDL handle
beginnings of the work to allow for different render windows This has some concerns but hopefully once I get back home I can mess with it more to make it more appealing.

final thing that I'm aware of would be the thing that Jklawreszuk mentioned with OpenGL and Vulkan being behind in functionality compared to DirectX. It's usable currently AFAIK but the hope with the Avalonia port would be to entice more people who would want to work on Linux to work with updating and playing with the OpenGL and Vulkan APIs.

[Kryptos-FR]

I'm back at working on the Avalonia port again. It's not visible to you because it is on some branch in a fork.

I realized that working alone on it is going to be difficult so I'm currently consolidating all I did so far and I will update the PR as soon as possible.