search

craftworkgames / MonoGame.Extended

Extensions to make MonoGame more awesome
http://www.monogameextended.net/
Other
1.44k stars 324 forks source link

Removing the Content Pipeline #676

Closed lithiumtoast closed 5 months ago

lithiumtoast commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

lithiumtoast commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

lithiumtoast commented 2 years ago

@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 commented 2 years ago

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:

damian-666 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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

AristurtleDev commented 5 months ago

The content pipeline is a controversial topic within the overall MonoGame community, but it is still very much a part of MonoGame development that users can either use or opt to not use.

Given that the content pipeline isn't going anywhere in MonoGame, support should continue for it where possible, however there should be feature parity where assets processed through the content pipeline should also be able to be loaded and processed at runtime.

Closing this ticket