MonoGame Feature Wishlist

If you had one vote for the next major feature in MonoGame what would it be?

Some things already on our radar:

  • Xbox One support.
  • Support for Metal/DirectX12/Vulkan.
  • Complete XAct support.
  • New networking APIs with support for Steam/GameCenter/GooglePlay/etc.
  • Automatic live reloading of content in running game.
  • Make the low level Shader API public.
  • Add support for Geometry shaders.
  • MGFX compiler for Linux and Mac.

What other ideas do you have for new features in the coming years?

It’s much easier using a straw poll: http://strawpoll.me/6525950

Well i’m not looking for votes on the stuff above… we can do that later. I’m looking for new ideas beyond the ones I listed.

I edited my original post to make that more clear.

Extended control over shaders. Geometry shaders and ability to control cbuffers would be nice.

You mean make the internal Shader and ConstantBuffer classes part of the public API. Correct? This would allow someone to implement their own custom effect system if they wanted.

That has come up before… the main complexity is that it would be limited to only a few platforms where it was available. Also we would have to finally support GLSL shaders as there is no automatic translation from MojoShader for this.

Anyway… I’ve added this to the list above!

1 Like

Yeah, performance difference with properly handled cBuffers is significant, of course it requires some learning and I realize it is feature that wouldn´t be used by everyone but some project could definitely use it.

Yeah, anyway thank you for using SharpDX API, I am really not fan of OpenGL (Thus mojo).

I agree… I would like to make fixes to the stock effects to take advantage of multiple cbuffers at some point in the future.

We support both for just that reason. :wink:

1 Like

Ability to compile shaders from Linux and Mac.

I know those are not “major features” but I’d love MSAA to be activated on Windows 10 (WinRT couldn’t but Windows 10 should be doable AFAIK, and MSAA really makes a difference on big screens) and fixing the initial WP8.1/WP10 rotation bug, which makes all games written for that platform look very unprofessional.

Make the low level Shader API public.
Add support for Geometry shaders.
if theres performance gains then Support for Metal/DirectX12/Vulkan.

That’d be my pick :slight_smile:

Along with this I would like some extensions to ContentManager/Content importers for live downsampling/adaptive loading.
On Windows store you can post a single .appx for all devices. In that case a texture could simply skip loading one or more mipmap levels to adapt to the 200Mb limit on mobile devices with 512Mb ram (and/or devices with small resolution, HiDef/Reach profiles).
Similarly a SoundEffect could drop one channel on the fly, mix/convert to mono (slower), and on extreme cases down-sampling + low-pass filter to remove aliasing (a half-band filter + halfing sample rate is a simple case). All this might not be possible/efficient on other formats beside PCM.

Could I ask for these to be considered?

  • Support for more AA options (especially for Directx), personally I’m not a fan of FXAA.
  • DX11 Instancing (unless the low level Shader API would cover that).
  • Include the Tessellator with the Geometry Shaders (if it is not already).
1 Like

You can implement SMAA, FXAA (not sure why you are not fan of 3.11) and CMAA… not sure about TXAA, I don´t posses license. Imho framework development shouldn´t focus on actual features that can be implemented by dev independently on framework as long as framework doesn´t limit it in some way (looking at you XNA stencil…).

Tesselation shader is different stage of shader - since you were talking about DirectX I suppose you mean Hull/Domain shaders? But yeah, why not (altho I would kinda hope/expect it would come together with GS support).

I wasn’t aware SMAA could be implemented and I’ve never heard of CMAA. I’ll do some research on those. Every version of FXAA I’ve seen just looks ugly in my opinion.

As far as I know, TXAA has some very specific requirements in the graphics pipeline that other techniques don’t (aside from an NVidia GPU). Plus with the licencing I doubt it would be feasible for Monogame to implement.

In Directx the Geometry shaders came in under DX10 and the Tessellator (yes the Hull and Domain shaders) was DX11, so I was thinking they might be considered separately and wanted to make sure they would be considered together here.

  1. Keeping an eye on WebAssembly and WebGL.

  2. Promoting ecosystem - it would be great to have a central place to discover compatible packages. E.g. how easy it is to find out that there is a port of Recast and Chipmunk available?

  3. Some VR support could be interesting for a few people (not me personally).

2 Likes
  1. Honestly, the thing that causes me most problems is the shaders. I only develop for iOS/Android. I wish I could just pass in some GLSL code and have this work - instead of having to compile the HLSL which gives me a lot of problems. In the future if I require Windows support I wouldn’t mind writing HLSL separately for that.

If I know my hardware/targeted platforms support features - I can’t have it just work because Monogame doesn’t support it due to “Platform x” not having the capabilities. Also sometimes I have GLSL that works fine but when I translate it to HLSL it doesn’t run/compile in monogame - even though it works fine in XNA. For an example: I have had issues with vertex texture fetch.

  1. Support for hardware instancing something I would really like along with an upgrade to OpengGLES 3.0 features. I would hope this is higher priority than Metal support.

There are a few other things, but the issues above give me the most problem.

Is there any plan to support VR?

That as been the goal since the beginning… supporting a GLSL FX file. Making it happen is tricky and few have helped make it happen. You can see the latest on this here: https://github.com/mono/MonoGame/issues/2167#issuecomment-173393568

I believe OP was referring to raw GLSL using plain old OpenGL calls to load and compile as opposed to offline compilation with the Pipeline.app. I personally only need OpenGL as well so I looked into making an Effect subclass to wrap the calls but there just isn’t enough exposed.