I’d suggest revamping of SpriteFont. Right now, it is very locked. Probably that is the reason why both MonoGame.Extended and Nez have it’s own BitmapFont classes (though maybe I am wrong and SpriteFont is fundamentally different concept than BitmapFont).
At least, it would be great if SpriteFont could be created in the run-time.
Possibility to reuse depthstencil buffer between RTs. It would also be great to use it as a shader resource. This way there would be no need to render custom depth buffer in deferred rendering etc.
That’s related to the changes from XNA3.1 to XNA4:
Each rendertarget now has an associated depth buffer: no more DepthStencilBuffer type
About possible memroy waste worries, Shawn answers:
Several of you expressed concern that this design could lead to wasted memory, as you can no longer share a single depth buffer between many rendertargets.
Not at all! The key shift here is from an imperative API, where you explicitly create depth buffer objects, manage their lifespan, and tell us which one to use at what times, to a declarative API, where you tell us what depth format you want to use, and we figure out how best to make that happen.
Some interesting thoughts follows on blogs.msdn.microsoft.com/shawnhar
Possibility to reuse depthstencil buffer between RTs
Do you mean use the same stencil or just depth ?
What if you need a ‘custom depth buffer’ like a linear depth for example, instead of the standard z/w with your deferred renderer ?
It is already “shared” between RTs when doing MRT when computing the desired depth mode (linear, z/w, 1-z/w etc)
If you mean sending a depthbuffer to be used with an effect on a new RT, if you pass the computed/resulting RT containing the depth along the data to a shader, so it can read it from the current depth, and also restore it (as a deferred renderer does at the end of its process when merging all the rendered RTs to the final texture)
1 Like
I mean using the depthstencil buffer between RTs like in DX10/11 by creating one DepthStencilView and reusing it between targets (e.g. draw some geometry the deferred way, and then draw some more geometry the forward way). Then restoring depth from a custom depth buffer can just be omitted.
If you want you still should be able to create a custom depth buffer (e.g. maybe you need another method of encoding depth because of precision issues), but it shouldn’t be required anymore.
By sending it to the shader, it is possible to create a shader resource with your DepthStencilView and read stencil values inside the shader. Just leave the old XNA4/DX9-style thinking and use all of the benefits that DX11 offers. 
But we will never get this feature if MonoGame continues sticking to the “XNA way”. As well as ComputeShaders, etc
As of now, Steam survey does not show any stats about DX9… starting from DX10 to 12. Time to move on.
1 Like
Not sure if this is in but “Automatic live reloading of content in running game” sounds great to me. It’d be a great time saver.
Also ability to write GLSL shaders and use them as .fx with MonoGame would be high on my list as I have done most of my shader programming in GLSL.
Finally, I see MonoGame has no ability to add Json or Video files in Content banks?
These would be great to have as I usually use Json for config, save and level files (not really fan of XML for these things). I’ve seen people use Newtonsoft Json, but I am not sure how cross-platform it is.
And of course videos would be useful for animated cutscenes in my game, I think I saw somewhere that this is not available just yet.
That is not something a game framework should implement, however you are free to implement it yourself.
I don’t think that feature is inherently something a game framework should not implement. It would be pretty cool if MG supported hot reloading in some way. For desktop we could have a class inheriting from ContentManager that can watch the source files (meaning the .xnb files in your project bin folder, not the files they were built from obviously) and notifies the user when assets change.
Yeah, that’s what we’d use. You think it’s not worth implementing/too low effort? I already checked and FileSystemWatcher is in .NET Standard 2.0.
I am against adding any sort of API for hot swapping on MG side, its easy enough to implement already as is.
IMO “it’s too easy” is not a good argument to leave a feature out. In fact, it’s a good reason to implement it because of the low hurdle. As long as it’s useful that is.
There are multiple ways to implement it and its not platform specific.
I think a better way to put “multiple ways to implement” is “different possible solutions”. For file watchers, if MG provides such a thing, there’s really no reason for people to implement their own version of it. You get notified when assets change, there’s maybe different ways to implement it, but that’s the functionality you want. If you want some extended features you can build on top of that. That’s completely different from e.g. a Tiled implementation, because there’s lots of possibilities for the API and what exactly is supported. If MG implements that one way, some people might not like it and implement their own. IMO that means it’s out of the scope of MG.
I also think that list of requirements should be looked at case-by-case and not used as a hard measure. For example you mentioned font processing/displaying in the GitHub issue: there’s a ton of different ways to render glyphs, but it’s essential to most games, so it makes sense for MG to implement it some way.
Just to add my somewhat-related thoughts to this discussion… I can’t think of another example, but does MG have some way of limiting features to debug builds of a game? I know there’s the DEBUG flag, but that doesn’t get passed through so it would require switching out the debug/release MG binaries, right? Because with a feature like this, I could imagine not only would you not want it running in release mode, but you would probably want to remove it altogether to reduce the assembly size.
If we’d add a class inheriting from ContentManager that simply has an event for when assets it loaded changed, it would be very lightweight. MonoGame currently does not have a system for excluding/including certain features from a build. We could of course do that using custom preprocessor symbols.
XML has attributes, not JSON, so in order to handle the “conversion” to a class, it is not as trivial nor as reliable as you think.
The purpose of hot reloading of xnbs is mainly required by editors, right ? Not in-game ? It would be a nice feature, but I can see many games built with MonoGame, more than editors (2 maybe 3 projects). And as within an editor, when modifying a world object or a shader, the app knows which file has been changed, it is more a thread safe content loading problem at runtime than a FileWatcher on a whole directory (which is not as reliable as it is said)
To be honest, true. It makes more sense to have the IDE take care of changes. I was thinking perhaps it could be a separate MonoGame extension instead to help devs implement the live reloading feature in their engine.
Actually, after working a bit with Audio, I think I’d give that a vote towards a better audio system as I had some issues
A reliable IDE for Linux would be nice. MD 6.2 decided to crash anytime I start a new project.
Haha, that request is completely out of place here 
I vaguely remember that crash being because of the Git integration and i think if you disable the addin it doesn’t happen.
Anyway, there’s VS Code and Rider. I’ve never liked MD myself.