You mean make the internal Shader and ConstantBuffer classes part of the public API. Correct? This would allow someone to implement their own custom effect system if they wanted.
That has come up before… the main complexity is that it would be limited to only a few platforms where it was available. Also we would have to finally support GLSL shaders as there is no automatic translation from MojoShader for this.
Yeah, performance difference with properly handled cBuffers is significant, of course it requires some learning and I realize it is feature that wouldn´t be used by everyone but some project could definitely use it.
Yeah, anyway thank you for using SharpDX API, I am really not fan of OpenGL (Thus mojo).
I know those are not “major features” but I’d love MSAA to be activated on Windows 10 (WinRT couldn’t but Windows 10 should be doable AFAIK, and MSAA really makes a difference on big screens) and fixing the initial WP8.1/WP10 rotation bug, which makes all games written for that platform look very unprofessional.
Along with this I would like some extensions to ContentManager/Content importers for live downsampling/adaptive loading.
On Windows store you can post a single .appx for all devices. In that case a texture could simply skip loading one or more mipmap levels to adapt to the 200Mb limit on mobile devices with 512Mb ram (and/or devices with small resolution, HiDef/Reach profiles).
Similarly a SoundEffect could drop one channel on the fly, mix/convert to mono (slower), and on extreme cases down-sampling + low-pass filter to remove aliasing (a half-band filter + halfing sample rate is a simple case). All this might not be possible/efficient on other formats beside PCM.
You can implement SMAA, FXAA (not sure why you are not fan of 3.11) and CMAA… not sure about TXAA, I don´t posses license. Imho framework development shouldn´t focus on actual features that can be implemented by dev independently on framework as long as framework doesn´t limit it in some way (looking at you XNA stencil…).
Tesselation shader is different stage of shader - since you were talking about DirectX I suppose you mean Hull/Domain shaders? But yeah, why not (altho I would kinda hope/expect it would come together with GS support).
I wasn’t aware SMAA could be implemented and I’ve never heard of CMAA. I’ll do some research on those. Every version of FXAA I’ve seen just looks ugly in my opinion.
As far as I know, TXAA has some very specific requirements in the graphics pipeline that other techniques don’t (aside from an NVidia GPU). Plus with the licencing I doubt it would be feasible for Monogame to implement.
In Directx the Geometry shaders came in under DX10 and the Tessellator (yes the Hull and Domain shaders) was DX11, so I was thinking they might be considered separately and wanted to make sure they would be considered together here.
Promoting ecosystem - it would be great to have a central place to discover compatible packages. E.g. how easy it is to find out that there is a port of Recast and Chipmunk available?
Some VR support could be interesting for a few people (not me personally).
Honestly, the thing that causes me most problems is the shaders. I only develop for iOS/Android. I wish I could just pass in some GLSL code and have this work - instead of having to compile the HLSL which gives me a lot of problems. In the future if I require Windows support I wouldn’t mind writing HLSL separately for that.
If I know my hardware/targeted platforms support features - I can’t have it just work because Monogame doesn’t support it due to “Platform x” not having the capabilities. Also sometimes I have GLSL that works fine but when I translate it to HLSL it doesn’t run/compile in monogame - even though it works fine in XNA. For an example: I have had issues with vertex texture fetch.
Support for hardware instancing something I would really like along with an upgrade to OpengGLES 3.0 features. I would hope this is higher priority than Metal support.
There are a few other things, but the issues above give me the most problem.
I believe OP was referring to raw GLSL using plain old OpenGL calls to load and compile as opposed to offline compilation with the Pipeline.app. I personally only need OpenGL as well so I looked into making an Effect subclass to wrap the calls but there just isn’t enough exposed.