MonoGame Feature Wishlist

Support for ComputeShader?

I did not find any information on this topic, which leads me to believe it is not currently supported.

Which would be a shame since every modern renderer uses it in one way or another, for me it would be important for light culling for tiled/clustered rendering.

1 Like

It would be nice to have a .Net Core nuget package.

And the possebility to install monogame only using nuget, not the installer. Currently, as far as I know, you can’t build content without the installed version.

1 Like

You can build the pipeline tool from source if you want.

What has blocked us there in the past is getting a solution we could use cross-platform. There just isn’t general purpose solution that works on all our target platforms including consoles.

Our solution so far has been to encourage people to use 3rd party compute solutions and let them deal with the complexities of supporting their target platforms. For example if DirectX is all you care about you can use the features already in SharpDX to support compute.

Really until we fully resolve our shader issues with OpenGL I don’t see myself thinking about the compute side of things.

Support for Microsoft® HoloLens®:

  • Microsoft® HoloLens® Project Template for Visual Studio®
  • Extensions to the MonoGame API (only few required)


The MonoGame UWP Template works with Hololense already. I tried it :slightly_smiling:

All UWP apps work with HoloLens® as a 2D projection.
However, if you managed to get it running as a full screen holographic app, then let me know how you managed to do that with MonoGame.


UI would be nice. The only options right now is outdated Xna frameworks, EmptyKeys which is crazy complex (for me anyway) or rolling out your own. A built in UI framework would be so nice, especially for us new to game development.

That probably won’t happen, at least not in the near future. Squid caught my eye a while ago. It’s a C# GUI backend, it might be a good place to start for a simpler alternative to EmptyKeys.

I think that I would be cool if we could have a buffer for spritebatch just like we do with vertexbuffers.

So something like

SpriteBatchBuffer sbb = new sbb(GraphicsDevice);

public void CreateWorld()
//or could be ssb.Add()
sbb.Draw(mytexture, new Vector2(10,10), Color.White);

public void Draw()
    SpriteBatch.Draw(ssb , Vector2.Zero, Colour.White);

If the buffer saved everything on the gpu, We could get a performance increases when using 2d. It would make it very simple for people who just want to use spritebatch.

Though I am quite sure that many of the features everyone would like to see implemented would be very beneficial, coming from a software engineering background I would like to see the following items addressed…

Complete documentation that is centralized on this site.

What is the sense of producing an excellent software tool if you don’t have good documentation that even a beginner could use to learn it? Simply providing the API documentation, though needed, is not very good unless everyone understands what and how each method or property means and how each works. People new to game programming won’t.

Scanning the Internet for hours at a time to learn how to do relatively simple things with Monogame is sort of a stretch.

A standard user interface namespace that will allow developers to easily implement various user controls. Every game requires visual controls that will allow the player to interact with it. And if you plan on making games for sale this is a definitive requirement.


1: While not present on the official monogame site, I use all the old XNA articles for monogame, plenty of those floating around that it takes very little time to find documentation. for example.
2: It’s not integrated, but is what I use and it’s amazing. The author is quite dedicated to it as well.

Monogame currently uses SharpDx 2.6.3.
As of today the latest stable version os SharpDx is 3.0.2 which should have many bugs fixed (and yes, some news ones too I believe).

Updating to SharpDx 3 any time soon would be a great benefit as it would support dx12 and all the improvements that comes with it in terms of speed, threading, resources, etc. and this would attract more developers (hopefully) to the community.

Concerning the cons: it may have some parts used by MG that have changed, as for example it happens to the new Mathematics library which makes the core dll lightweight.
As always, a lot to do, and no timemachine available for all this, as MG must support OpenGL, Android, etc platforms.

1 Like

Support for importing the FBX 2009 format. This was present in XNA but has been left out of MonoGame.

I am migrating a big project and we cannot change our model and animation pipeline. The system is too brittle and it would take too long for us to get animations working again. So for now we have to keep our old XNA-based content pipeline in a side project, just for the models.

This could be an Assimp feature, not MonoGame which just use it, better to ask Assimp dev team for it.

I think autodesk has a tool to convert them to a newer format.

Thanks. I looked it up and they do have a free converter tool, which I installed and tested. I will look more into it later.

I’ve just tested it yesterday, and for some reason it changes the path to textures used by the model, adding a …\ before it… So I had to convert to ASCII to be able to edit this.

Don’t know if it was already suggested: access to low-level graphics API, ie: SharpDX on windows DX platform, and other API used for others (OpenTK for GL I think, etc) in order to have access to features “denied” by multi-platform choices made, just for those who don’t care about some platforms by choice.

It could be done by giving a reference to (with the example above) SharpDX reference from graphicDevice instance (according to MG graphicsdevice DirectX, device, context and others are all internal, so I guess they can’t be use from a game instance).

[quote=“InfiniteProductions, post:80, topic:6850”]
Don’t know if it was already suggested: access to low-level graphics API, ie: SharpDX on windows DX platform
[/quote]This is already available for DirectX platforms via the GraphicsDevice.Handle property.

1 Like