Removing the Content Pipeline

[lithiumtoast]

The MonoGame/XNA Content Pipeline has been fairly controversial and a source of frustration for many. The Content Pipeline (for MonoGame.Extended) will be removed in future and possibly replaced with something easier to use if the features of the Content Pipeline are necessary to ship games.

[padesso]

What do you think of importing assets via a Visual Studio extension? Does this couple monogame development too tightly to Windows, and specifically VS?

[lithiumtoast]

I would prefer to have an extension to MSBuild through .props and .targets for integration with Visual Studio / Rider. That's what MonoGame already does: https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework.Content.Pipeline/MonoGame.Content.Builder.targets

[padesso]

Does that imply that users would simply add resources to their VS/Rider project and they get processed at the build step?

[lithiumtoast]

Well yes/no. I would imagine something like a manifest file or a glob search pattern in a JSON file would be required akin to .mgcb file to know what assets are to be processed. This manifest file would then populate the solution explorer in Visual Studio using the .targets & .props. An investigation would need to be done to see if the workflow of CRUD of assets in Visual Studio would map to non-Visual-Studio workflow. I would like to support the tool as a standalone command-line interface (CLI).

[ghost]

Is the removal of content pipeline confirmed by the monogame devs? I'm a beginner and just started monogame and...I actually love the content pipeline. The tool is easy to use. Importing assets in the code is really easy.

What probleme do people have with it?!?

[lithiumtoast]

Is the removal of content pipeline confirmed by the monogame devs?

No, this is just for MonoGame.Extended which is morphing into Katabasis. Katabasis already has removed the content pipeline from it's FNA fork, but Katabasis is still experimental.

I'm a beginner and just started monogame and...

Welcome.

What probleme do people have with it?!?

1. Creating custom importers/processors is annoying as there is limitations. Sometimes you want to extend the Content Pipeline to do X but it can only do Y. For example, taking a bunch of smaller individual sprites in seperate files and packing it into a sprite sheet (texture packing) is not a use case which neatly fits the API of extending the Content Pipeline. To make it happen you have to result to janky workarounds which have their own consequences / side effects. This is XNA hertiage "meatloaf" which is one of the reasons why Katabasis is an ongoing project.

2. The content pipeline relies on reflection for loading assets at runtime which is okay on desktop platforms but janky / slow / limited support on other platforms such as mobile or console. Source generators could be used instead with .NET 5 / .NET 6 similar to System.Text.Json, but support for .NET Core / .NET 5 / .NET 6 is not officially supported in FNA. FNA does support NativeAOT for .NET 5 / .NET 6 but that compilation model usually strips out the information needed for reflection in C# unless manually opt-in by hand for every type you know in advance will need reflection (pain in the ass). It's better all together to just not use reflection moving forward for multiple reasons.

3. The most annoying thing for most people is that the MGCB Pipeline UI tool and the CLI tool does not understand NuGet packages. You have to manually place / copy the NuGet packages' binary files to a correct location or manually edit the .mgcb file to a location where the binaries exist. This is a major pain point for the MonoGame.Extended project, see https://github.com/craftworkgames/MonoGame.Extended/issues/626#issuecomment-720449736.

[mrhelmut]

Weighting in as a MonoGame admin to note that the content pipeline isn't going anywhere. EDIT: see comments below to avoid confusion.

[lithiumtoast]

@mrhelmut Just to clarify, as far as MonoGame.Extended is concerned, it will be removed. Meaning, avoiding it all together and removing any code in MonoGame.Extended which uses the content pipeline.

[mrhelmut]

Fair enough. I just wanted to drop by because some users seem to be confused in regard to which "Content Pipeline" is being removed from which project. Sorry if it added even more confusion.

To be more specific:

• the Content Pipeline isn't getting removed from MonoGame
• Content Pipeline references are getting removed from MonoGame.Extended

[damian-666]

Note about Sprite Atlases, fonts, and content limitations mentioned in here. One might find workaround for those kind of limitations in Nez without having to fork MG. But he takes the xnb content and embeds it in his core DLLs. So his build process and content manager are highly customized. I prefer the content as is, so I can touch fx file, build and run but I dont use much raster assets, I generate those at runtime. Just hoping compute shader will be available in MG for GL, and DX desktop and ARM mobile, in the main fork...now im not sure if its needs the fork using shader conductor. I saw that PR aimed for 3.9 though. I love to see all ths code flux tho.

[mrhelmut]

Just hoping compute shader will be available in MG for GL, and DX desktop and ARM mobile, in the main fork...

They will, but it's a pretty demanding PR to merge because it has a lot of consequences on private console implementations which may or may not be able to use ShaderConductor. So before merging it, we need to make a bunch of preparatory work on not visible projects.

[damian-666]

thx ,i think if i begin to use those shaders and stick w just desktop and mobile, then I could try his fork and hope he advances the most essential new net 6 MG stuff the other way into his fork, if he can do so and with less worries about breaking changes to console devs

[biffbaff64]

The MonoGame/XNA Content Pipeline has been fairly controversial and a source of frustration for many. The Content Pipeline (for MonoGame.Extended) will be removed in future and possibly replaced with something easier to use if the features of the Content Pipeline are necessary to ship games.

I really don't know why MonoGame doesn't use a system similar to what LibGDX does with its AssetManager. So much less messing about and so much easier to use. The Pipeline is genuinely putting me off, particularly as I've hit issues with trying to import .TMX files.

[differenceclouds]

Any updates on this? I'm really just interested in importing Tiled files without compilation. Loading a modified tiled file during runtime would be very nice...........