MonoGame Feature Wishlist

I vote for making the low level shader API public :slight_smile:

I’d love to see MonoGame start dropping its strong ties to XNA, use its own namespace and start adding support for newer graphics APIs (DX11&12 mainly). Still being stuck on DX9 is a huge downside when wanting to develop 3D stuff.

1 Like

There are some parts of MonoGame that do use a MonoGame.Framework namespace, and a namespace change has been discussed. The downside is that it would be a massive breaking change that would affect almost every source file in everyone’s code.

There have been discussions and some movement on this. We have to come up with a feasible plan that caters for DirectX 12, Vulkan and Metal.

1 Like

I gathered from other threads where that topic came up that you plan to do it eventually, and since there is no alternative other than not doing it at all, I was wondering why you guys keep postponing it :slight_smile:

For the namespace issue: would it be possible to write a project converter?

Because I would also like MonoGame to move away from using the XNA namespace.

I would like that as well, I teach programming and MonoGame to high school students and some students always think that it’s strange that the namespaces start with Microsoft when Microsoft is not affiliated with MonoGame.

We will add it to the list for consideration for the 4.0 release. Hopefully the changes to the dev’s projects would simply be Replace in Files of “Microsoft.Xna.Framework” to “MonoGame.Framework”, and rebuilding content. We would have to adapt our content loaders to cope with existing content that has the “Microsoft.Xna.Framework” typenames as well, since we cannot realistically expect everyone to rebuild all content, especially for released titles.

can I add to the wishlist NOT modifying the namespace? :wink:

The amount of files I’d have to change is really really big, not to mention I could no longer compile both projects with XNA and MonoGame. (I still find more easy to use the old XNA content and I just compile wiht MonoGame when releasing), would introduce incomptabilities between WP7 (where software still can be shipped) and also previous versions of MonoGame (in example, WP8 will probably soon be phased out, but I still have to produce binaries for it).

At some point MonoGame will no longer be just XNA. How we make that jump to our own namespaces will be tricky and possibly messy… but it has to happen eventually.

Still hoping to find some one line change we can do to have the C# compiler know Microsft.Framework.XNA means MonoGame.Framework.

1 Like

It’s only under consideration for the 4.0 release, and we have to take into account that there are still devs using XNA today and sharing the code with MonoGame projects. I believe that one of the reasons MonoGame has succeeded where other XNA implementations fell by the wayside was that we used the Microsoft namespace. If Miguel de Icaza had decided to use a Mono namespace in the Mono implementation of the .NET Framework, I don’t think it would still be around today.

So changing the namespace is a large change, and could potentially alienate some devs, so it is not something we will do without lots of careful thought about all the potential issues it could raise.

Couldn’t we just have a compiler statement like

#if MG
namespace MonoGame
# else
namespace Microsoft.Xna
# endif

That way we can choose the framework we want to work with.

That might work for your project, but we’re not going to ask everyone to do that in every source file in their project. And not all cases can be handled with a simple conditional compile statement like that.

If anyone wants to talk about the namespace rename further lets take that to the existing issue on GitHub:

Type forwarding might be able to help us with the namespace change. We can just forward the old MS types to the new MG ones.

I hesitate between
New networking APIs with support for Steam/GameCenter/GooglePlay/etc.
Automatic live reloading of content in running game
Concerning the second one, did you mean something like datastreaming possibility as well with some threadsafe methods and members ? If so i choose this one.

Just a thought maybe you can get some ideas from were XNA 5.0 would be heading.
If it had been made for c# instead of c++ and one up them.

the dx toolkit its walbourn and hargreaves at it again

It might be a great place to look to find a starting point for hull shaders and such.

New networking APIs with support for Steam/GameCenter/GooglePlay/etc.

Shader compiling for OSX and Linux
We’re starving over here :frowning:

1 Like

For now you you can compile shaders on a remote windows server using a content pipeline extension that @dellis1972 wrote (link). He has a server set up for this that you can use, which is pretty awesome :smiley: Thanks dellis!

1 Like


Not something I specifically would like, but notice some start in the source repo.