This stems from a discussion started in another PR:

https://github.com/mono/MonoGame/pull/4397#issuecomment-169345797

It has been over 3 years since we initially investigated sticking with OpenTK in MonoGame. The OpenTK team at that time promised fixes and renewed development of the library.

Since then there have been improvements, but we still suffer problems with OpenTK functionality and need per-platform work arounds at times.

Is it finally time to give up on OpenTK?

Do we proceed with our own custom binding for SDL2 and OpenGL?

What happens to platforms like iOS and Android where we depend on the Xamarin fork of OpenTK for OpenGL access?

So I and others have been advocating reviving OpenTK several times and I'm happy to hear that the MonoGame core team is making good progress on that front (https://github.com/mono/MonoGame/issues/1528).

Now I hear @flibitijibibo has been working on porting MonoGame to SDL2 with apparently good results. From what he says on Twitter (I hope I'm not misrepresenting what he meant), SDL2 is well maintained and works great on all desktop platforms.

Apparently he mentioned his fork a couple times around here but it wasn't seriously considered because it's a huge change and the perceived cost of merging seems high while the benefits haven't been made obvious

I'm opening this issue hoping that we can discuss the technical & community merits of switching to SDL2 vs. marching forward with the on-going revival on OpenTK.

@flibitijibibo care to point us to your fork, detail what state it's in and how it compares in terms of features/bugs to the current MonoGame?

cc @tomspilman @dellis1972 @CartBlanche

I'd like to start discussing how we can further improve the system by which different platforms are added in MonoGame.

IMO the idealistic goal moving forward should be that we can add additional platforms (like PS4 for instance) without needing to make platform specific modifications to existing files in the public repo. Ideally merging in a platform like XB1, PS4, or WiiU would be as simple as copying a folder of files into the root of the public repo and executing Protobuild.

About a year ago we took two big steps...

Moved to using Protobuild for project generation

The Protobuild change now means zero project file maintenance, new non-platform specific code is quick to add, and no more project file conflicts.

The problem with Protobuild is that all the platform specific info is centralized in one file. This means that if we have a closed source platform like we do with PS4... we have to maintain a patched version of that definition file with additional .ps4.cs files and other platform specific details.

Ideally there should be a way to optionally include additional platform files/settings from the main Protobuild .definition file. @hach-que ??

Partial classes and "Platform" methods

Also a lot of MonoGame platform code is now done with partial classes and "Platform" methods. This is great as most of the platform code is just adding in various .platform.cs and editing the protobuild config file to include them.

We still have big classes like GraphicsDeviceManager that are a #if spaghetti. We should prioritize converting classes like that into platform partial classes.

In places where we smaller #if blocks that are enabling some feature for multiple platforms we should look at add a feature specific #if. For example this case here:

https://github.com/mono/MonoGame/blob/develop/MonoGame.Framework/Game.cs#L325

... we probably need a #if NO_EXIT instead of naming specific platforms. This allows the feature to be toggled on other platforms by changing the Protobuild config.

Extending The Pipeline

A big area where we need to design a new abstraction is within the content pipeline. There are cases where there are platform specific formats and processing that we want to be able to plug into the pipeline instead of being hard coded into the public repo.

In this case I started a separate issue for this (see https://github.com/mono/MonoGame/issues/2781) but it is something that needs consideration.

This PR addresses multiple issues at once because they're all dependent on one another:

• Upgrades Protobuild: Throughout the course of this PR I had to make changes to Protobuild to support the newer APIs and fix various issues across platforms, so that is updated here.
• Remove old XSLTs: With the Windows Universal and tvOS platforms upstreamed into Protobuild, there's no need for MonoGame to keep it's own copies of the XSLT files any more. This PR removes them in favour of the built-in ones. This will assist with #4218.
• Mac now supports the Xamarin.Mac Unified API: It supports both the MonoMac API, XamMac API and newer Xamarin.Mac API (unified). The older APIs are supported by #ifdef'ing namespaces with the PLATFORM_MACOS_LEGACY define. This resolves #4275, but should also fix bugs like #4278.
• WindowsUAP is now WindowsUniversal: This brings the MonoGame platform name inline with the platform name being used in upstream. See https://github.com/hach-que/Protobuild/pull/130 for the name change reasoning.

Right, so I've been working with @dellis1972 on the PCL generator project and it looks like it is close to being done. It now uses a PCL generator solution based on Mono.Cecil called Piranah (which Dean has also updated to run on a Mac) Generator branch for MG can be found here: https://github.com/DDReaper/MonoGame/tree/PiranahPCLGenerator

The generator only uses the WindowsGL build as a template, which seems sufficient for the PCL to be used in a "Bait and Switch" style PCL as a core platform. Platform specific code should always remain in a Platform project (like iOS), where as all common "core" code should be used in the PCL.

Question is now how to provide this framework back in to the MonoGame project so it can be run in an automated fashion. In the branch above (using Protobuild as a template) I've created a new ThirdParty folder for Piranah and put the runtime exe and Dll's in there. There is a commandline file to generate the project manually for test at the moment (need both the WindowsGL project built and an output folder in MonoGame.Framework/bin/PCL created first)

I've also started on a new MonoGame.Portable NuGet package, which is still a work in progress. In testing it needs more platform targets to work effectively.

So next steps?

Right now MonoGame has the following project templates for various different IDEs:

• ProjectTemplates\VisualStudio2010\Android
• ProjectTemplates\VisualStudio2010\Linux
• ProjectTemplates\VisualStudio2010\OUYA
• ProjectTemplates\VisualStudio2010\Windows
• ProjectTemplates\VisualStudio2010\WindowsGL
• ProjectTemplates\VisualStudio2012\WindowsPhone
• ProjectTemplates\VisualStudio2012\WindowsStore
• ProjectTemplates\VisualStudio2012\WindowsStoreXaml
• ProjectTemplates\VisualStudio2013\WindowsPhone
• ProjectTemplates\VisualStudio2013\WindowsPhone8.1
• ProjectTemplates\VisualStudio2013\WindowsStore
• ProjectTemplates\VisualStudio2013\WindowsStoreXaml
• ProjectTemplates\VisualStudio2013\WindowsUniversal
• ProjectTemplates\VisualStudio2013\WindowsUAP
• IDE\MonoDevelop\ (and all the various template files under here)

We can probably make it easier to maintain all of these variants if we generate them - this would have the added bonus that if we want to quickly test the current version of MonoGame that we're working on as an actual app, we can just create a new project from those templates rather than having to actually install the templates into Visual Studio / Xamarin Studio first (especially since all this really is is just fancy text replacement).

With TeamCity we have some powerful NuGet features, including the ability to both package and publish to any feed.

First we need to figure out:

• What builds will we make available thru NuGet?
• How often should these builds be updated?

Then we can begin to setup the build server to support building and publishing them.

I don't believe there's been much discussion of the design of the Pipeline dotnet global tool. I'm interested in helping with that next, as I think that's the last piece that need to be nugetized.

Open Questions

1. Future of Pipeline tool. [EDIT] Resolved: Pipeline is here to stay, while cra0zy is working on his own alternative.

   @Jjagg I am in process of writing something custom for the content builder, among the other stuff, so I'm leaving this to you. I really don't wanna touch MGCB/Pipeline Tool anymore.

   Originally posted by @cra0zy in https://github.com/MonoGame/MonoGame/pull/6905#issuecomment-546690990

   Should we be expecting something to replace the current tooling, or is that just personal preference or maybe an alternative option? (I assume the latter)

2. Name. [EDIT] Resolved: MGCB Editor is currently the top contender, with commands like dotnet tool run mgcb-editor

   As a public package, "Pipeline" is too generic. What name should be used for the package and the command? (Note: our other tools are dotnet-mgcb and dotnet-2mgfx.) For example:

   • Tool: dotnet-mgpipeline
   • Global command: mgpipeline
   • Local command: dotnet tool run mgpipeline

3. Structure. [EDIT] Resolved: The platform packages can't be unified, because we want native UI controls on Windows. We can, however, package them together and have a cross-platform launcher so the experience is seamless across all platforms.

   Should we package platform-specific Pipeline tools, or unify them? Is UI the only thing preventing these from being unified? Presumably shaders can just continue to not compile on non-Windows for now.

   • Platform-specific would be easiest since it would keep the same structure and Eto dependencies. We can publish dotnet-mgpipeline-windows, dotnet-mgpipeline-mac, dotnet-mgpipeline-linux, but this is clearly not ideal.
   • We can switch to a new cross-platform .NET Core UI framework and publish a single cross-platform tool. The most popular appears to be Avalonia.
   • We can use MonoGame.DesktopGL itself for the UI -- either a 3rd party UI framework, or maintain an extremely slim set of controls just for the tools (not a part of the MG framework).

4. MGCB dependency. [EDIT] Resolved: MGCB will be packaged directly into MGCB Editor. The duplicated files aren't too large and shouldn't be much concern for devs.

   How should the MGCB dependency be handled?

   • Just package MGCB binaries into the Pipeline tool as well? Then users who use the Pipeline tool and build with the MonoGame.Content.Builder package (#6905) would have a handful of files duplicated, but it's not a big issue. Is there a concern about the two versions needing to be manually kept in sync?
   • Package MGCB binaries into the Pipeline tool, but don't additionally required the MGCB tool when using the Pipeline tool. Instead use MGCB out of the Pipeline tool. See the Usage option below for more details.
   • Have the Pipeline tool depend on the MGCB dotnet tool. This would be difficult, because if the Pipeline tool is installed globally, then it would have to also install the MGCB tool globally, which is an option we decided to avoid with MonoGame.Content.Builder. This could also be difficult to run locally out of the MonoGame repo, because the Pipeline tool would need to be able to either depend on the MGCB dotnet tool or use the local MGCB project.

5. Usage. [EDIT] Resolved: /register and /unregister CLI commands will be available to associate the app with the .mgcb extension by running pipeline /register (global) or dotnet tool run pipeline /register (local).

   I expect a common scenario to be installing as a global tool, but can we enable more options?

   • As an additional option, I was thinking about being able to specify an option in the MonoGame.Content.Builder package (#6905) to restore the Pipeline tool instead of MGCB. This would make it easier for content designers to just clone a repo and automatically get the recommended tooling. And obviously this wouldn't have to compromise any of the core MonoGame.Content.Builder functionality.
   • Will we need to give up associating the .mgcb file extension with the tool? This doesn't seem like a good option anymore since dotnet tools can be installed globally or locally. Following the potential usage option above, in my own repos I plan to change my Pipeline extensions project into a netcoreapp that can simply call dotnet tool run pipeline on the correct .mgcb file.

I'm assuming that 2MGFX is not meant to compile under Linux. Are there any intentions to change this in the future so that compilation can be done on non-Windows platforms?

We need to finalize the coding style guidelines in this document:

https://github.com/MonoGame/MonoGame/blob/develop/CODESTYLE.md

This is a required step before we can do #1511.

Lets keep all discussion in this thread before any PRs are submitted to change the guide.

There is one thing with the iOS version of MonoGame that always annoyed me and I never really knew why it happened: SoundEffects randomly disappear.

We have a dozen of sound effects in our game, loaded using a single content manager. There are a number of instances created from every effect. When the game is launched, some of the sound effects won't play. For example, I launch the game and the "Click" sound doesn't play (all the instances of it). Then I close it, launch it again and the "Bell" sound doesn't play. Sometimes multiple effects disappear, sometimes none of them.

It may or may not be related, but when the game loads, I get a number of these on the application output:

Failed to get buffer attributes: 

It seems that I don't get any of these when all the sound effects work, but I get many of some of them don't.

Hey! I would love if you can Support Model Animations and RIG Support! like a Method that you can call in the Model class (i hope i come in :))

model.StartAnimation(1);

What version of MonoGame does the bug occur on:

• MonoGame 3.8.1

What operating system are you using:

• Windows

What MonoGame platform are you using:

Cross Platform

If your referencing another project file's DLL, and that project was using .net 3.1, you need to update the Content.mgcb file also. This is not referenced in the updated .MD file here on github, nor on the older information on the website.

Example section that I had to update:

#-------------------------------- References --------------------------------#

/reference:....\DataImporter\bin\Release\netcoreapp3.1\DataImporter.dll

Change to.... /reference:....\DataImporter\bin\Release\net6.0\DataImporter.dll

What version of MonoGame does the bug occur on:

• MonoGame 3.8.0 convert to 3.8.1

What operating system are you using:

• Windows

What MonoGame platform are you using:

• DesktopGL

Documentation is not being deployed from github to the website.

Example: This page https://github.com/MonoGame/MonoGame/blob/master/Documentation/articles/migrate_38.md Is 5+ months old on the last edit, yet the website still doesn't have the (important) information regarding the content file changes when migrating from 3.8.

See here: https://docs.monogame.net/articles/migrate_38.html

The information that is in here is invaluable. I was going to come and try to update the documentation, but it appears someone did 5 months ago, it's just not updated to the website yet.

When my game is placed in a multitasking window on iPadOS, the view is offset down from the top of the screen so there's a blank area at the top and part of the view is cut off at the bottom. The offset becomes larger as the window width is made narrower.

What version of MonoGame does the bug occur on:

• MonoGame 3.8.1

What operating system are you using:

• iPadOS

What MonoGame platform are you using:

• iOS

I've recently updated my Visual Studio and wanted to use the new Monogame extension. I've been away from MonoGame for a while as a bug put me off my project, but I've recently decided to try again. I had been on Monogame 3.8.0, largely working with the Dotnet CLI.

I went to go and install the Monogame templates extension, but I get the error stated above:

"An item with the same key has already been added."

I won't post the whole log file as its full of path traversal (can do on request), but the important bit looks like its here:

12/12/2022 23:30:56 - Microsoft VSIX Installer 12/12/2022 23:30:56 - ------------------------------------------- 12/12/2022 23:30:56 - vsixinstaller.exe version: 12/12/2022 23:30:56 - 16.11.57 12/12/2022 23:30:56 - ------------------------------------------- 12/12/2022 23:30:56 - Command line parameters: 12/12/2022 23:30:56 - C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\vsixinstaller.exe,/appidinstallpath:C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.exe,/skuName:Community,/skuVersion:17.4.33122.133,/appidname:Microsoft Visual Studio Community 2022,/culture:en-US,/noep,C:\Users\craig\AppData\Local\Temp\VSIXfqnnaj1c.vsix 12/12/2022 23:30:56 - ------------------------------------------- 12/12/2022 23:30:56 - Microsoft VSIX Installer 12/12/2022 23:30:56 - ------------------------------------------- 12/12/2022 23:30:57 - Initializing Install... 12/12/2022 23:30:57 - Extension Details... 12/12/2022 23:30:57 - Identifier : MonoGame.Templates.VSExtension.03a6f6d5-6ec0-45ff-a4f6-ec098d51464d 12/12/2022 23:30:57 - Name : MonoGame Framework C# project templates 12/12/2022 23:30:57 - Author : MonoGame 12/12/2022 23:30:57 - Version : 3.8.1.303 12/12/2022 23:30:57 - Description : This extension contains the C# project templates for using the MonoGame Framework 12/12/2022 23:30:57 - Locale : en-US 12/12/2022 23:30:57 - MoreInfoURL : 12/12/2022 23:30:57 - InstalledByMSI : False 12/12/2022 23:30:57 - SupportedFrameworkVersionRange : [4.5,) 12/12/2022 23:30:57 - 12/12/2022 23:30:57 - SignatureState : Unsigned 12/12/2022 23:30:57 - Supported Products : 12/12/2022 23:30:57 - Microsoft.VisualStudio.Community 12/12/2022 23:30:57 - Version : [17.0,18.0) 12/12/2022 23:30:57 - 12/12/2022 23:30:57 - References : 12/12/2022 23:30:57 - Prerequisites : 12/12/2022 23:30:57 - ------------------------------------------------------- 12/12/2022 23:30:57 - Identifier : Microsoft.VisualStudio.Component.CoreEditor 12/12/2022 23:30:57 - Name : Visual Studio core editor 12/12/2022 23:30:57 - Version : [17.0,18.0) 12/12/2022 23:30:57 - 12/12/2022 23:30:57 - Signature Details... 12/12/2022 23:30:57 - Extension is not signed. 12/12/2022 23:30:57 - 12/12/2022 23:31:10 - Capping recursion at 5 directories in each extension root due to 'default limit'. ... much path enumeration occurs ... 12/12/2022 23:31:11 - The extension with ID 'MonoGame.Templates.VSExtension.03a6f6d5-6ec0-45ff-a4f6-ec098d51464d' is not installed to Microsoft Visual Studio Community 2022. 12/12/2022 23:31:12 - System.ArgumentException: An item with the same key has already been added. at Microsoft.VisualStudio.Setup.Engine.Initialize() at Microsoft.VisualStudio.Setup.Engine.GetProducts() at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.IntializePackages() at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.GetPrerequisitesInternal(IInstallableExtension extension, ICollection1 installedPackages, ICollection1 installablePackages, ICollection1 unresolvedReferences) at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.GetPrerequisites(IInstallableExtension extension, IEnumerable1& installedPackages, IEnumerable1& installablePackages, IEnumerable1& unresolvedReferences) at VSIXInstaller.ExtensionService.GetInstallableDataImpl(IInstallableExtension extension, String extensionPackParentName, Boolean isRepairSupported, IStateData stateData, IEnumerable1& skuData) at VSIXInstaller.ExtensionService.GetInstallableData(String vsixPath, String extensionPackParentName, Boolean isRepairSupported, IStateData stateData, IEnumerable1& skuData) at VSIXInstaller.ExtensionService.ComputeInstallableExtensions(IStateData stateData, Boolean isRepairSupported, Boolean isExtensionPack, IDictionary2 skuDataMapping, IList1 installableExtensionsPaths) at VSIXInstaller.App.Initialize(Boolean isRepairSupported) at VSIXInstaller.App.Initialize() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute() --- End of stack trace from previous location where exception was thrown --- at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)

I couldn't see anything about this in the documentation.

Is it possible that something I have pre-existing on my system (the extension isn't one of them I've checked by trying vsixinstall /uninstall) is getting in the way here? I did have the dotnet new templates at one point, though I admit I now can't see them when I look in dotnet new list.

What version of MonoGame does the bug occur on:

• MonoGame 3.8.0 -> 3.8.1

What operating system are you using:

• Windows

What MonoGame platform are you using:

• DesktopGL (or I will be when I get going)