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.
There are two general problems with shader compilation at runtime.
Some platforms don’t support compiling shaders at runtime on the target device.
Shader compilers are generally really slow for non-trivial shaders.
These issues may never be fixed entirely which is why MonoGame and XNA (and even Unity) choose for offline compilation as the default path. This decision is made with portability to all the target platforms in mind.
I was the technical reviewer for the Apress MonoGame book and based on that I feel more press, documentation, and samples would go a long way. I prefer Monogame over Unity and would definitely like for it to get more attention. Amazon released their game engine recently and I still couldn’t find a reason to switch over.
Is there something like a Patreon project for monogame?
It’s not a feature by himself but if MonoGame surpass the features of XNA some kind of an official wiki (in wikipedia style) would be nice.
There is some documentation on github, some on this site and you can find many in internet.
Problem is that some are outdated, incomplete, in diffrent format, some assume you already did the previous 42 parts of the tutorial, …
With a wiki MonoGame would have a documentation which is up-to-date, has a consistent format, linked to related topics on the same site.
I know it’s a lot of work but everyone can help. unity has also a wiki
That was the MonoGame wiki for 3 or 4 years and it was always a total mess. It was always out of date, the information was good and bad, formatting totally different from page to page, etc.
I used to think a Wiki is great for docs, but that and a ton of other experiences told me it was not.
They are versioned with the code… so a feature change can me matched with a doc change.
Docs get reviewed like any other code change.
We finally have reference docs.
The big problem is that no one cares to write good docs. No matter where we put them… the lack of good docs is because no one writes them. And we have tried for over a year now to get people to help:
In that time maybe 2 or 3 people have helped with docs here and there, but no big efforts for big chunks of getting started documentation.
IMO until myself or one of the other core contributors decides to spend 3 months only writing docs… it will never get done. No one else really wants to help in that capacity.
Oh, I didn’t know about the history of MonoGame documentation
I’m new to MonoGame and already searched for some information about it (also checked links above). The most I learned from that site: http://rbwhitaker.wikidot.com/xna-tutorials
If a wiki did’t worked, maybe a structure like this gather more helping people. Some given main topics in which helping people can contribute some small tutorials/explanation to s specific topic.
The new documentation is close to that structure. Maybe add some main topics and a visual
hint that these are not written yet (like in Wikipedia). Easier and faster way to edit them would be nice too.
If I learned some more and released my first mono game I’m confident that I will write some docs.
EDIT:
Something else to add, as a XNA extension: a pitch argument in Texture2D.SetData, like:
> public void SetData<T> (
> int level,
> Nullable<Rectangle> rect,
> T[] data,
> int startIndex,
> int elementCount,
> int pitch
> )
index i of array “data” is shifted by “pitch” after each row of rectangle “rect”
One feature I would like to recommend is template releases for each platform in VB. I personally use the language and am currently running my VB game using a custom (and un-updated) template (which is windows only).
On top of my suggestion I have to ask, are there any disadvantages for programming in VB rather than C#? Thanks!
We hope to support VB as much as possible along with F# and C#. The only complexity will be if VB is supported on some platforms like iOS, Android, PS4, etc.
In general no.
You could say using VB with MonoGame is more difficult as most all of our users are C# developers, so that puts you at a little disadvantage. Having to manually convert C# sample code and tutorials to VB as you go.
Performance wise VB and C# generate similar IL for most features and perform about the same in most cases. There might be a small edge in performance in C# as it gets more attention than VB and has some performance features like unsafe code which are not available in VB.
If your game is not heavily dependent on performance and you don’t mind most all the tutorials and samples being for C#… then VB is totally fine.
-Extended sampling options when creating spritefonts, something similar to photoshop’s “Smooth, crips, strong, none” font sampling settings would be awesome.
-I know I mentioned in another post but for sake of having it at one place: better support of processing HDR image content, currently I wasn’t able to compile .hdr using pipeline tool (had to use XNA). Since .hdr is getting outdated (and there are some problems with gamma and offset) I wish for .exr. But I completely realize this is big “can of worms” since https://github.com/openexr/openexr gave me quite decent headache.
Both are supported by the library we use for image importing. If you can open an issue on GitHub about it with at least one or two examples of .HDR and .EXR images we can look to fix the issues and support it.
I was using like old year pipelinetool from download section on site, I should keep closer look at git, newest version looks wonderful so far and exr successfuly compiled. My bad, sorry.
I converted all the templates to VB in 4.5 with an installer even though no guarentee they all work…I cant test the Mobiles or the Windows Universal and havent enough experience to use the pipeline extension but when i converted it did however compile so i believe the template is working and fully functional…
