It seems it is currently in progress: Features · GitHub
(sorry for the spam)
I won’t be doing any responses to BGFX related stuff anymore after this.
Than you can count BGFX C# wrapper as another layer so you would still have more layers on the BGFX side, which would still make it slower.
My criticism was that BGFX is fairly unknown and that not many people know it, so there wouldn’t be many contributors, so your solution is “Thats OK”…
My criticism was that BGFX doesn’t support game consoles, not who supports more platforms.
Vulkan also has C# bindings… it doesn’t make doing the port a whole lot easier.
Take it easy 
The C# wrapper is as simple as BGFX’s interface: couple P/Invoke functions.
Don’t tell me it will be slower, I don’t believe it. BGFX is a thin, close to the metal kind of library.
BGFX has 2334 stars. Monogame has 3810.
Considering Monogame is targeting a much broader audience than BGFX, that’s a lot of stars.
BGFX has few opened issues while Monogame has more than 700…
Technicaly it’s very high quality, higher than Monogame to my judgement (no offense)
BGFX has build its reputation by itself, while Monogame is where it is because of XNA legacy.
BGFX implements every graphics api, which means it implements the one used in game console as well.
Why not just try compile it and see?
Why don’t you guys just look at it? I did look at it closely, I have evaluated it, and my judgement is that it’s just the best graphic lib out there.
Let me tell you my feeling right now: the problem you guys seem to have is not technical, but political.
You had a closed mind atitude right from the beginning, and I feel like I’m fighting against the Status Quo rather than technical constrains.
1 Like
I think there is already a lot of work to do on monogame in its current stage to improve it and a few time for the developers.
So all in all, introducing a new api is not just “put this dll instead” and all goes error free. There will certainly be problems not foreseen, and still not much time for contributors to develop and correct them.
It is not eliminated. Rather it is not in the pipes for now 
Or someone can fork monogame and try bgfx
- Support more feature levels in GraphicsProfile.
1 Like
Is this a hidden DX12 reference? 
Thank you @Alkher for your post.
I know I have overreacted, but there are some attitudes I just can’t stand.
I would agree making MG more mature & stable is definitely the priority.
Cheers
Two small things that would make Monogame move forward a lot faster:
-
A red colored ‘Bug’ label should be created in the bug tracker, and assigned to every issue corresponding to a bug. I’m surprised there isn’t any, and this should overall help the community to have a transparent list of bugs.
-
I feel like most bugs are being reported by users themselves. What would be needed is a set of official technical samples that would be used as a reference, which would cover the most use cases possible, and collect various metrics, by hardware ect…
We can always create a dedicated website with such a feature… if it helped…
I’d love to have a portable way to use strings without garbage collection. In the XNA times there was this:
however it doesn’t work on UWP, and probably won’t in NET Core. No idea about Android/iOS
I know this does not probably belongs to monogame, but using strings are crucial to most games, and probably #1 source to garbage collection and performance degradation (or maybe it’s just my games 
). Maybe into MonoGame.Extended ?
I love MonoGame and using it to teach students game development skills. The one major issue that I have from a teacher/school perspective is that the installation only applies to the person logged in at the time of install (myself/admin). I would like the option to install MonoGame on a classroom computer and have students log into the computer with student (non-admin) accounts.
Thanks,
Scott
1 Like
The difficulty here is that Visual Studio templates are per-user as they live in the user’s Documents directory. When Visual Studio is launched for the first time by a user, it creates the required directory structure in the user’s Documents directory, including an empty ProjectTemplates directory.
That is where custom templates should be installed. There are global templates in the Visual Studio installation directory in %ProgramFiles(x86)%\Microsoft Visual Studio \Common7\IDE\ProjectTemplates, so I might see if we can install MonoGame project templates in there. That would also neatly solve the issue of finding the user’s Documents directory when the installer is running as administrator.
(1) A test suite that does full API coverage to serve multiple purposes, regression testing, API validation, performance testing, and also serves as the ultimate code sample
(2) Working MSAA
(3) Tooling that leverages Monogame built with Monogame to enhance game development tooling for things like rigging, animation setup, etc.
(4) More integration with the Visual Studio IDE to further enhance productivity
(5) Gradual evolution of support libs under a different namespace with no changes to the core (either in namespaces or API because that’s what makes Monogame a success). As for practical API tweaks to the core API, some of this can be done with overloads, some with extension methods, etc.
And this next bit should be up to the community:
I’ve noticed a few educators posting here. Why not assign your students projects that cover the basics of 3D that serve as useful gaming utilities. In the good old days of OpenGL there were samples for things like graphic primitive, texture operations, … camera view plugins so you could visualize camera params within your running application etc., would be nice to have a monogame variant of this sort of thing.
Having a bunch of these utility modules would go a long way to helping with workflow and should be a separate community initiative.
My simple and small wish would be:
- To have DrawLine, DrawRectangle, DrawCircle, DrawPolygon, DrawEtcpp in SpriteBatch itself
- To be able to declare Fonts per Image/ Fonts per Font object instead of a file
- The Standart Projects should have the Ability to use Visual Studios Image/3D Editor(i know that VS does have this feature its just plainly impossible to use, but why is beyond my understanding)
4 Likes
That would be a wonderful feature.
For the draw-routines… That’s exactly why there is MonoGame.Extended.
Just saying. In case the poster didn’t know.
1 Like
Some people don’t want to use a framework that works on top of MonoGame (MonoGame.Extended is named that way because it uses MonoGame, it does not actually have to do anything with MonoGame, it’s like Nez),
Yup. That’s right cra0zy. Thanks for pointing that out.
I meant to post that info in case the poster didn’t know about MG.Ex; If he want’s that functionality specifically in MG that’s a valid request of course.
I think that’s an excellent idea, or maybe in some other class included in MonoGame if SpriteBatch doesn’t make sense.
Saw the Ex Libary already just didnt know there was this functionality in it; I installed it because i needed BitmapFonts and saw that it had new overloads for the SpriteBatch. Love to have this feature 