I recently did some work for the pure OpenGL runtime (build system is already working, but only robust for old glsl versions because it uses glsl-optimizer). The current runtime is a bit different because MojoShader does some specific things. I got it running, but currently have some issues that I haven’t really investigated yet. PR: https://github.com/MonoGame/MonoGame/pull/5354
I’ve already talked about this a lot on the forum, but here we go again
When we have both the HLSL -> GLSL translation and the pure OpenGL runtime in place MG can drop MojoShader and expand with things Mojo doesn’t support like geometry and compute shaders. Regarding the new API’s, from pure OpenGL it’s easy to go to SPIR-V (the Vulkan shading language) using glslang and from that to MSL (Metal Shading Language) using SPIRV-Cross (experimental). Since as a MonoGame user you don’t write MSL or SPIR-V directly, but HLSL or GLSL our effects parser can stay in place mostly as is meaning nothing changes for the end user (but at this point you can write your shaders in GLSL too! So that covers most of the shader side of things.
Of course then there’s the MG runtime side. The API needs to be designed and implemented for all three backends which is a lot of work. There’s no one really working on this right now. If there’s anyone that has some experience or interest in working with Vulkan or DX12, don’t hesitate to contribute if you’d like!
That’s great that developers won’t have to re-write their shaders!
After playing with Metal for quite some time, I have been reading the Vulkan specification and following along by building a C++ application. There is definitely a common pattern between Vulkan, DirectX 12 and Metal that can be abstracted into a new MonoGame API.
I am against Dx12, Vulkan since it’s unreasonably hard to achieve performance benefits and questionable if most monogame applications are even a good fit.
Plus it makes it near-impossible for 99% of the community to work with the source code, since it is much more complicated than dx11. Plus, we would need libraries like vulkansharp etc., which have not been tested extensively and are potentially unreliable.
Not mentioning the fact that most computers right now are not eligible in terms of hardware to even use dx12/vulkan and the fact that the target audience of 99% of monogame applications shouldn’t need great hardware, since - let’s be real - 2d is where monogame can outshine Unity and co.
Main benefits of the new APIs are potential async operations and better support for CPU multithreading requests, but it’s hard to combine that with the default “true-and-tested” rendering paths of the classic XNA / Monogame application (aka: Update your simulation -> render stuff (with spritebatch) -> repeat).
I think if some masochist (me) wants to work with dx12 monogame might not be the right place.
It’s all optional, the classic API will stay right were it is. We just provide the alternative for people that want it. I agree it’s not very great for direct consumption but the newer API could be used to build higher level frameworks or full-blown engines on. And it’d also be nice for people that just want to give it a shot
Understandable, but MonoGame will eventually need to make the jump. Backwards compatibility for XNA 4 API will obviously be a must. From there own outwards, developers can choose to use trusted and familiar XNA 4 API or try out the new API which I like to think of as XNA 5, but obviously can’t call it that. Without considering potential performance gains there are some new features that can be included in the new API which is not available in XNA 4 such as tessellation, geometry shaders, and general purpose GPU compute capabilities.
Pretty sure Tom expressed that he doesn’t want to use any third party wrapper for pretty much this reason. Instead there would be a custom built bindings using the Platform Invoke (P/Invoke) service that would interact with Vulkan and DirectX12 by marshalling data between C# and C. Metal however is by design a Obj-C API so that complicates things quite a bit. Would need to look to Xamarin for guidance on how they P/Invoke with Obj-C APIs.
Old hardware will get replaced over time. But yes, 2D game developers are probably not going to be pushing the limits of the graphics hardware on average. However, I don’t think MonoGame should just be a 2D framework. It just happens to be a great framework for 2D development with or without some extensions such as Nez. With better hardware and new low level rendering and compute APIs such as Vulkan, DirectX 12 and Metal, developers have the possibility of creating create great 3D games for mobile devices.
I guess that idea was before Xamarin got acquired by Microsoft then? If it is acceptable to use Xamarin.iOS for Metal bindings that would save a lot of time!
Getting acquired by Microsoft doesn’t change anything with regards to supporting all iOS APIs in Xamarin.iOS. Xamarin will always add support for the complete iOS API with each new release, and won’t intentionally cripple API support for some reason.
