Support for ARKit would be awesome.
I’d like the ability to “force” a draw call after every update when IsFixedTimeStep = true. I have implemented a “hack” to make this happen and it fixes the hitching or frame skipping normally scene in 2d sidescrollers, but for some reason it seems to impact the keyboard input and causes it to be unresponsive or delayed, Interestingly, the gamepad input is unaffected. Anyway, the ability to turn this on would be great and I think a lot of people developing 2D games would appreciate it!
Classes for skinning animation in 3D models.
3 Likes
It would be nice, if possible, to be able to get the “true” line number of a warning/error in shaders.
Explanation: when using include(s) in an fx file, the line shown in the pipelinetool (and I suppose, by transitivity the line returned by mgfx) is offset by the number of lines in each of the inluded files.
If you have for example a warning for a truncation of a vector in your fx file at say, line 100, and an included file with 27 lines (these values are examples of course) then in fact the warning is at line 73, not 100 (which can be beyond the lines of the fx file)
Or is there an option to use with mgfx ? (–returntruelinenumber ?)
1 Like
Here is a minor one. In spritebatch draw, add dual layer sort options. FrontToBack + Texture and BackToFront + Texture. So if a group of images (A,B,A,B,A,B) drawn on 0.5f layer. It will group all of them on 0.5f then secondary by texture so it can batch it more efficiently so (A,A,A,B,B,B) on layer 0.5f.
I make my vote, on OpenGL ES 3 support. For example if I set the game to HiDef profile, MG should support all features backed up by OpenGL ES 3.
HoloLens/Windows Mixed Reality support.
But a better solution of OpenGL shaders could be maybe even better because the difference between DirectX and OGL is big.
You mean in terms of what’s supported in MG? Because that’s not true.
Though we do need a solution for HLSL → GLSL that works on all desktop platforms.
THIS, I was about to buy a headset and then realised, though I saw a project supporting it, somewhat [not seen actual imagery] and it was a hack job so not ideal at this stage… but having this going forward, would be a neat step when the second generation of headsets arrive…
Biggest things I’d like:
- Swizzle functions on vectors.
- Vector2.YX(), Vector2.XXX() -> Vector3, Vector2.XYYX() -> Vector4, etc
- Broader math operator support across the Color/Vector families
I guess I could just make a PR for those though.
Swizzles were actually pretty easy when I sat down at it: Swizzle-builder + generated swizzles for Vector2, Vector3, and Vector4 including the combinations between them like Vector2.XXXX() -> Vector4.
2 Likes
One feature I’d really like to see is the ability to get an unmanaged pointer to the pixel data of a texture/render target.
This would allow us unsafe users to pass pointer types to unmanaged code (for example, Pango) and allow them to write pixel data DIRECTLY to a MonoGame texture, skipping the use of GetData<T> and SetData<T> which saves RAM and cuts out a pretty big performance hit.
1 Like
MonoGame does not keep a copy of texture data in RAM. Textures are usually only store in video memory (VRAM). So it has to be copied to RAM to be able to get an unsafe pointer which is exactly what GetData does.
We could consider exposing the texture id/handle, in case third party libs require a handle (this came up before with regards to VR support). But that’s not cross platform, so not sure if that’s something we should do.
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.