Maybe the new Span<T> from C# 7.2 could help you “cherry-pick” some performance somewhere ?
I don’t want to be pushy, what you are doing is incredible and even more incredible is fact you are doing it for free. Now I realize, is there even donation button I am constantly missing? I just want to ask so I can plan accordingly, what’s current state of:
- Make the low level Shader API public.
- Add support for Geometry shaders.
2 Likes
Yes, there is 
there’s a “Support MonoGame” link in the footer of every page except for on the forum (I guess that’s an oversight). It links here: http://www.monogame.net/donate/
This has been planned for a long time, but no one has gotten to it yet. What’s your use case specifically?
EDIT: Here’s the relevant issue for it: Consider exposing low-level Shader / ConstantBuffer API · Issue #3471 · MonoGame/MonoGame · GitHub
Also no work on this. The issue here is with cross platform shader compilation. MG uses MojoShader to translate HLSL bytecode to glsl and to get reflection data. MojoShader does not support geometry shaders. Last time I checked, none of the alternatives were ready to replace MojoShader.
1 Like
The forum is actually independent from the website… but yes, it needs to be unashamedly more prominent…
1 Like
I, for one, wouldn’t mind having to write shaders twice in order to get them working in other platforms, specially if the benefits are great (as geomtry shaders are)
I already have lots of problems when porting shaders to android and I’ve been using GLFX to solve some of them. With mojoshader sometimes I find that I have to end up juggling code in order for him to make a correct GLSL translation. One wrong line and boom, you end up rendering nothing.
When those problems arise (which is often), I spend less time converting the shader to GLSL manually than trying to find a workaround for the Mojo bug
(no need to say I’d love GLFX support in the stable branch 
)
2 Likes
I’ve found this which may be of some help (or not)
It was used here: Simon's Tech Blog: Recent Update 2014
To write cross platform shaders, shaders are written in my own shading language which is similar to HLSL. Those shaders are then parsed by a shader parser generated by Flex and Bison[9] to obtain a syntax tree to output the actual HLSL and GLSL source code.
1 Like
The optimization stage deciding to kill things is the real problem with a parser. The parser sees that stuff is there but then when it comes to building the list of uniforms/parameters it’s no longer there. Which as far as I could see, in my perusing, that’s the main reason for the way shaders are as they are. They need to get valid information out of the result, which makes it much worse than just translating as an AST must be built and checked.
Nevermind that hull/domain shaders are only mappable between HLSL and GLSL in trivial cases since they diverge.
I’ve been juggling around the notion of making my shader graph stuff work for Monogame. Though eto forms not having a sane way to paint custom controls cross-platform put a big wrench into doing that cross-platform.
As far as I could see when I looked at it the graph would take care of enough of a chunk of what the optimizer does that shader optimization shouldn’t hurt anything since it already detected this isn’t used and this tree of nodes is all constant situations.
Gotcha is that graphs are brittle to external changes. Although a simple snippet is easy to auto-build a node for (ie. a node for calculating new UVs for parallax occlusion mapping) it’s not trivial to recognize or respond to “well now everything is broken” situations. I couldn’t find a case in the asset processor where there were consequential dependencies of that sort.
Still means some write for multiple platforms but it’s at least confined to a node-by-node case.
I guess I could make it all work in WPF and then leave it to those braver than I to sort out how to cross-platform that sort of thing.
Maybe the way yo go for Monogame will be make one shader compiler for each platform, which i think would sign the end of monogame: there is already little spare time for contributors to improve the current version.
Maintaining many versions may lead to divergence, moreover when more contribute to the version they are interested in at the dispense of others.
But as technologies evolve, if monogame does not enter in the wagon it may stay a 2d framework. There is already dx12 and monogame does not yet provide all the stuff of dx11 (and dx10 as Geom. Shader were already available)
The only way to go i can see is to propose to install the technology we need: you wanna make some dx12 features with win10, monogame only install the framework (the common stuff from xna: vectors, matrices etc) and the dx12 part that is needed to compile your shaders.
You need to do something with linux, install monogame for linux with opengl related compilers.
Maybe the support of mobiles can stay in one package, as they share the same graphics card (not sure but it is opengl right?)
This way, breaking changes when a new opengl or directx arise only impact the concerned technology and not all of them, which can stay alive and running
Maybe i’m not clear, tell me if anything is garbage, i just woke up with these ideas 
1 Like
For low level shader API: Some optimization. Geometry shader, now that would have many uses for me tho generally experimenting with what I can actually do.
1 Like
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.