MonoGame Future Support

I know this may be a tough question to answer, but can we expect for MonoGame to be supported on the next generation of consoles? I’m guessing Playstation 5 is about two years away (Fall 2020) and with how long it can take to develop games I’m wondering if I can expect to be able to port my MonoGame projects to PS5 and the next XBOX…

1 Like

Yes, yes you can expect it.

Ok, awesome news! Thanks! :slight_smile:

“I hope my game will run on the Windows18 and the Xbox XI !”

Come on… MG does not yet support DX12, not Vulkan… nor DX11 completely as it does not support all its features…
Start to catch up with nowadays techs.

1 Like

Here is a question for you, if MonoGame kept its existing graphics API and added Vulkan/Metal/DX12 support, what benefit would the devs / end users see?

Here is my answer, from the perspective of 3D games as I don’t care about 2D.

Endusers:
More 3D games, faster/more efficient use of their hardware, more eye candy (more than 80% of games purchase are based on eyecandy)

Devs:
Time saved by not loosing time trying to recreate and optimize an effect that would be more efficient with compute shaders
Closer with “nowadays” technologies and realtime effects.

MG Team:
Fixing already existing bugs is time consuming: no commit in the next 16 days. So, “adding” new APIs require more members as time is can not be dilated. CQFD.

Apart from the “infinite flight” game and a very few others shipped games I don’t know of if they ever exist, Monogame seems confined to 2D games and hobbyists.

I wish the team good luck, but I need to abandon Monogame, it was fun to use and learn some things, but I’ve reached its limits concerning 3D performances. If I ever want to ship my game I need more latitude with shaders, spending more time on the game whereas spending it on “how to do this or this without ComputeShaders”.

End of story.

I said “if MonoGame kept its existing graphics API”…

MonoGame is an open source implementation of XNA, and as such it needs to be XNA 4 graphics API compatible, as well as keep supporting older devices (and Vulkan and DirectX 12 don’t work on them). At some point we’ll be able to switch to them, but probably not for at least a couple more years.

That is incorrect, you would actually more than likely get slower running games since the XNA graphics pipeline basically uses DX9 one, and forcing something like Vulkan API to act like DX9 isn’t useful at all. And some stuff just wouldn’t work since some stuff in Vulkan are immutable so if we wanted to change them the entire app would basically be forced to reboot.

DirectX 11 and OpenGL 4 I think support it (I might be wrong on this), so move to the new graphics APIs would probably not fix this. Adding an API for this could probably be achieved by modifying the shader compiler stuff.

There are few of them on here: http://www.monogame.net/showcase/ I could probably think of a few more but I need to prep for something.

No offense, but your post does come off as ignorant.

1 Like

Here is a question for you, if MonoGame kept its existing graphics API and added Vulkan/Metal/DX12 support, what benefit would the devs / end users see?

Zilch. Unless being thrust into the driver-hell that Vulkan is apparently trapped in for perpetuity counts as a beneficial experience. Probably be able to get the same experience 2 years from now.

DirectX 11 and OpenGL 4 I think support it (I might be wrong on this)

GL 4.3+, anything less lacks SSBOs (roughly equiv. to DX11’s UAV) and without those compute is just plain silly.


Time saved by not loosing time trying to recreate and optimize an effect that would be more efficient with compute shaders

I’ve been working with compute since the dawn of CUDA - it’s anything but a magic bullet. It’s more often a PITA of histos, fenwicks, and chokepoints that barely wins out over OpenMP in a narrow range.

You still have to write a CPU fallback and that’s going to remain the case for many more years unless you have some incredibly narrow target (like console XYZ). nV has also only recently started getting on async-compute, so you really can’t do as much as you think, the greater majority of even recent hardware lacks async and that hurts.

You need an incredibly narrow problem, like GPU particles, for it to actually be a no-brainer. It’s much more powerful at design-time than runtime.

spending more time on the game whereas spending it on “how to do this or this without ComputeShaders”.

Compute in both GL and DX is incredibly trivial API-wise. OpenCL and CUDA are trickier but they still take far less than 8 hours to get rolling with. All of the hard is in making algorithms fit that much parallelism without requiring so many prefixes/histos/syncs that regular threading ends up faster.

If you actually need it (and can actually use it) then it shouldn’t be a problem.

2 Likes

You answered yourself to the fact monogame is stuck with an old API. Nothing to argue.

I’m not saying to force a dx9 or 10 or 11 game to be force to use Vulkan/dx12 if it was not designed for it from the start.
I say it is impossible to get these API’s speed improvements right now. Doom has +20fps with vulkan than with standard OpenGL on my computer… More time to do more things.

I see only 2 games which would probably need complex shader to make complicated effects like lightshafts or PBR. I’m talking about advanced effects like the shafts from Fallout4, or realtime global illumination which is slow without compute shader… Doom uses compute shader FYI.
But the facts are there, not many 3D devs because there is not many 3D devs attracting others.

I dont think so, you defend your cause and that’s normal, but I don’t see any game nor developper here trying to achieve a AAA grade rendering because they know from the start of their project that it can’t be with monogame.
I need this kind of effects, and with monogame it is simply impossible without making too much compromises with speed. And players don’t like slow things…
Being aware of what cannot be done with monogame and moving to something that allows me to do it is not a proof of ignorance at all, but wisdom. There is a time to go on with things and another to admit things are too slow/impossible.

Being blinkered in your world of “XNA must stay compatible” closes the debate.

@AcidFaucent3d I already work with Cuda at work and I know all of this :wink: I would have found really cool being able to use what I already master at work with monogame.

@Alkher MonoGame is an open source implementation of XNA… you know, the entire purpose of the project right now is to mimic XNA as close as possible…

At some point, the project will change its goal to become “XNA 5”, but that time is not now.

1 Like