MonoGame Feature Wishlist

26

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

27

We have tried a wiki…

GitHub - MonoGame/MonoGame: One framework for creating powerful cross-platform games.

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.

The docs are now here:

http://www.monogame.net/documentation/?page=main

… the benefits so far:

  • 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.

1 Like
28

Oh, I didn’t know about the history of MonoGame documentation :frowning:
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”

something like cudaMemcpy2D ( CUDA Library Doc.

29

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!

2 Likes
30

We’re working towards that now. The plan for 3.6 is to have a new cross-platform project template generator that lets us more easily support a bunch of cross platform templates (see Add project creation tool by hach-que · Pull Request #4295 · MonoGame/MonoGame · GitHub).

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.

1 Like
31

Is there currently a way to use .fx files / shaders? More specifically is there a way to pass textures into a shader? Thanks!

(I’ve been trying to do this and always get a a solid green screen)

32

-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.

33

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.

34

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.

35

@Tom I guess the first item should be crossed off the list :smiley:

36

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…

37

@Damien_James_Gibsoncan you post a link to a gist (gist.github.com) of the vb project file. I should be able to tell you if everything is in order.

38

i know they will load via vb, i just dont know that they will compile, as i dont know for certain that Xamarin/MonoDevelop compiler will accept certain things in the VB language… and for the windows universal and the pipeline, i just dont have ability to compile the win universal to make sure all the syntax is in order … or know whats going on with the pipeline to put it into an app to test it doesnt throw errors somewhere…

However if you wanna look into them, i posted a link on my thread to both a template installer(auto puts it into the VS template folder) and a binary.rar that has the literal template files directly.

Also to answer your question earlier about disadvantages to VB over C#, well my above is one of them… I know that Xamarin doesnt like to play well with VB on linux and mac and this is specificly why i am unsure they will all work 100% totally fine…

39

I would really like it if there was a simple solution to embedding a game in a WinForm control. Obviously I’m glossing over a lot of details, but my thought process is something akin to:

Create some interface, IGamePlatformFactory, that is implemented by GamePlatform.
Create some winforms control that implements IGamePlatformFactory.
Create an overloaded constructor for Game that allows an IGamePlatformFactoryto be passed in, with the empty constructor calling that with a new GamePlatform.

This would likely also involve interfac-izing everything that GamePlatform touches (like GameWindow).

1 Like
40

uhh it sounds like you are looking for GraphicsDevice… which the SwapChainRenderTarget helps along with simulating that a bit…

41

What I missed the most is:

  • binding multiple buffers to graphics device,
  • hardware instancing.

Both is working under DirectX platform, but not under DesktopGL platforms.

42

I vote for making the low level shader API public :slight_smile:

43

I’d love to see MonoGame start dropping its strong ties to XNA, use its own namespace and start adding support for newer graphics APIs (DX11&12 mainly). Still being stuck on DX9 is a huge downside when wanting to develop 3D stuff.

1 Like
44

There are some parts of MonoGame that do use a MonoGame.Framework namespace, and a namespace change has been discussed. The downside is that it would be a massive breaking change that would affect almost every source file in everyone’s code.

There have been discussions and some movement on this. We have to come up with a feasible plan that caters for DirectX 12, Vulkan and Metal.

1 Like
45

I gathered from other threads where that topic came up that you plan to do it eventually, and since there is no alternative other than not doing it at all, I was wondering why you guys keep postponing it :slight_smile: