Future multiplatform support and general direction

[SirePi]

Just throwing here some thoughts, ideas and evidence about the direction that Duality would need to take to reach "official" multiplatform capabilities

1. Duality is basically already a .net standard environment
2. OpenTK is approaching version 4, initially described as having support to .net standard
3. OpenTK will drop glControl and similar UI elements, with no plans to do so in the immediate future - issues for the editor
   
4. OpenTK's will not be .net standard, but require either framework or core, this I believe means that the launcher/platform distinction will no longer be possible
   
5. Silk.NET can actually support .net standard, and appears to be quite similar to OpenTK in terms of API; biggest difference is in terms of reliance on pointers and unsafe methods
6. Apparently Silk.NET is also working on a UI framework, and supports Vulkan
7. There's other frameworks around as well (i.e. Veldrid), but that definitely means that we'll have to basically rewrite the whole platform

This said, I think that losing the platform projects IMHO is not that big of a deal (sorry @ilexp 😄 ).. I mean, it's a neat feature but in all the time it has existed I never saw another platform implementation other than the default ones. (and maybe drop one abstraction layer?)

[ilexp]

This said, I think that losing the platform projects IMHO is not that big of a deal (sorry @ilexp 😄 ).. I mean, it's a neat feature but in all the time it has existed I never saw another platform implementation other than the default ones. (and maybe drop one abstraction layer?)

Why would you drop the platform layer in Duality? The whole point of it is that this is the only part where something has to be changed or re-implemented when switching graphics / audio frameworks underneath, or add an alternative one for a different platform. So.. this is actually a great example why it's good to have it?

[SirePi]

I just remembered that you can have a .net core class library 😄 I was somehow under the assumption that .net core == executable, and so you would have to combine the platform and launcher projects in one. Nvm then, everything became a bit more simple 🙂

[Rick-van-Dam]

Well usually when you use .net core you have a executable but its not a requirement :P

[Rick-van-Dam]

So the only thing thats blocking is the GLControl @SirePi? If we can get around that we could use the new opentk and change everything to netcore?

[SirePi]

Technologically speaking, yes
Practically speaking, they changed a bunch of things in the new OpenTK, and I have no idea where to find them or some substitute, if the concepts are still even present at all. (i.e. contexts... AudioContext, IGraphicsContext etc...)
These are the biggest points I couldn't manage to translate yet.

Unfortunately there's basically no documentation yet, so it's even difficult to try and find a "hello world" example to see how things are supposed to be done now.

But again, besides this, I think .net core is the way

[ilexp]

Unfortunately there's basically no documentation yet, so it's even difficult to try and find a "hello world" example to see how things are supposed to be done now.

Last time I checked I had some doubts that the new OpenTK is in a stable form yet, mostly since so much stuff was changed at once. Not sure this was a strategically great decision, since the big refactor probably broke most custom forks beyond mergability and added a barrier for others to update, basically starting over with no large projects using (and battle-testing) it.

That said, this last time has been >= 6 months, maybe >= 12 months.

But again, besides this, I think .net core is the way

So the only thing thats blocking is the GLControl @SirePi? If we can get around that we could use the new opentk and change everything to netcore?

Talked about this already in the chat, but mirroring this here: Going forward, it seems we have two options regarding OpenTK:

1. Update to the new version and create a custom GLControl equivalent to make it work in the editor.
2. Port our existing OpenTK fork to NetCore

If we were to do this right now, I'd go with option 2. With the highly extended API surface and even WinForms support, it's probably doable with a reasonable amount of work, and more importantly, it does not introduce any new unknowns.

Beyond that, exploring any other framework is of course an option too, and one that we can easily do side-by-side by providing an alternate set of alpha / beta backend plugins that people can use if they want. It's also a very big topic with potential implications from the long-term editor UI (#274) side, when switching over to MAUI with .NET 6 becomes an option. Since we've already got a lot of big changes going on right now, maybe we should postpone that part though.