MonoDevelop Content Pipeline AddIn

[dellis1972]

With the new Content Builder work in progress we need to start thinking about how this will be integrated into MonoDevelop so that developers on Mac, Linux and Windows can compile content easily.

Depending on how this goes we might not go down the route of having a separate content project, it should be possible to add resources to the project directly and flag them so they will be compiled by the content builder.

There might be scope for a separate content project as well.

At the moment the plan is to add a new File action of "MonoGameContent" which can be selected for any type of file, add addition file properties to allow the ContentImporter and Content Processor to be set within the application.
We can then hook into the build process to pickup the special content at build time and place the resultant .xnb files in appropriate output directory (preserving the directory structure within the solution, so

Content/Effects/MyEffect.fx

would end up as

bin/$Configuration/Content/Effects/MyEffect.xnb

We can make use of the MonoGamePlatform which is already present in most of the project templates to make sure we compile content for a specific platform. These properties need to be added to the iOS and Android projects somehow.

We will also need a way to specify in the IDE where the content builder is installed and
some way of allowing the developer to set a list of directories which can be used to resolve content processors and importers, this information can be written out to the content builder. This might be at the IDE level or at the project level, but more likely at the IDE level to start with.

We also need a way to populate a dropdown list of Processors and Importers so they can be easily selected. There can be defaults which will be used for known types so a .png when flagged as a MonoGameContent item will automatically get a Importer of TextureImporter and a processor of TextureProcessor.

[totallyeviljake]

How would we add our own custom content builders to this system?

[tomspilman]

Depending on how this goes we might not go down the route of having a separate content project,

Lets see about doing two things:

1. Support content mixed into a regular .vcproj.
2. Support .contentproj.

I suspect if we get 1 to work... then 2 will work as well.

add a new File action of "MonoGameContent" which can be selected
for any type of file, add addition file properties to allow the ContentImporter
and Content Processor to be set within the application.

... and...

populate a dropdown list of Processors and Importers so they can be easily selected.

The difficulty here will be that you need to inspect the importer/processor to know the properties. We can either do that every time you add a file type (sort of how MS XNA does it) or require some other definition file to be added as an 'item template' (VS term... not sure what that is called in MonoDevelop).

My suggestion is to put this issue off until later. Focus first on getting it to build from existing or manually edited project files.

We will also need a way to specify in the IDE where the content builder is installed

I assume it would be part of the MonoGame install relative to where the Addin assembly would be.

set a list of directories which can be used to resolve content processors and importers

It is more complex than this.

In our case our solution includes a project that has custom importers/processors. That project is referenced from the .contentproj and because of that the assembly is built and available for content processing.

We really should support that here as well. Seems like it might be sort of natural really as long as MonoDevelop takes care of building dependent projects first.

How would we add our own custom content builders to this system?

Ideally the same way stock importers and processors are resolved in MS XNA. Thru assembly/project dependencies.

[dellis1972]

I guess we could say if you just want to use the standard content importers and processors then you can add that directly to the project. But if you want to extend then you need to use a contentproj, that would solve the build dependencies issue.

First release will just be the standard stuff we can add the separate project later think.

[tomspilman]

Yea.... lets take small steps towards the goal. You usually know better after you get something working what the next move should be.

[dellis1972]

Just an update on this issue. We have a basic working AddIn which shells out to the content builder. It works on Windows and Linux, Mac is the next stop.

[sabvdf]

Has anything happened on this in the last months?
We'd be happy to help out with the addin if it has stalled...

[tomspilman]

@dellis1972 has a PR up for his code (#1937), but it hasn't been merged yet.

[dellis1972]

@sabvdf the PR I have up (once I fix up a few errors) contains the Xamarin Studio Addin for Windows and Mac. I've not been able to test it on Linux yet as there are a bunch of dependencies like the pvrtc lib and nvtt that need building for Linux.

[dellis1972]

The PR is just about ready to go. (#1937) It only supports texture and spritefonts on Mac and Windows at the moment, but it s a good start. I think Audio should be the next hurdle since that will cover us for most 2D games. Then move onto shader support followed finally by 3D models.

On a side note I've started implementing a proper msbuild task for the content pipeline that should work on mac, Linux and windows without the need to shell out to an exe. That will be in a future PR.

[tomspilman]

On a side note I've started implementing a proper msbuild
task for the content pipeline that should work on mac, Linux
and windows without the need to shell out to an exe.

I'm still unconvinced of the need for an MSBuild task. What advantages do you think it has?

The benefit I see of an EXE:

• When the EXE finishes it lets go of all assemblies... no ambiguity there.
• EXEs work on all platform equally.
• EXEs can be used from any build system or toolset.
• A command line EXE is understood well by everyone.

[nightst4r]

Wouldn't hurt to have an MSbuild task that shells out to an exe? Best of both worlds?

[dellis1972]

MonoDevelop is moving towards an MSBuild architecture, so we will need it
eventually as the build extension we use will no longer exist at some point
in the future (I have no idea when).

Even if we do go with an exe we will still need to resolve stuff like where
mono is, and the path of the MGCB.exe which will be different on each
platform, so we'll probably need just one task to resolve all that for us I
don't fancy writing all that logic in a .target file. Also xbuild is not
full compatible with msbuild (yet) so we just need to be careful.

On 17 September 2013 22:12, Mark notifications@github.com wrote:

Wouldn't hurt to have an MSbuild task that shells out to an exe? Best of
both worlds?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1212#issuecomment-24622818
.

[tomspilman]

MonoDevelop is moving towards an MSBuild architecture

That is good news... it would be helpful if we can share the .target files with VisualStudio and MonoDevelop.

so we'll probably need just one task to resolve all that for us I
don't fancy writing all that logic in a .target file.

That is the problem... you still have to write a bunch of logic in a .target file unfortunately.

The structure of the data coming from the .contentproj has to be "transformed" before being passed to the MSBuild Task or an EXE. The main .target file for the MS XNA pipeline is over 500 lines of script and it depends on 4 custom MSBuild Tasks as well.

This is the current .target file for processing a .contentproj with MGCB.exe:

https://github.com/mono/MonoGame/blob/develop/MonoGame.Framework.Content.Pipeline/MonoGame.Content.Pipeline.targets

Overall fairly short... shelling out to a MSBuild Task or an EXE would leave that file largely the same although a few things would change a bit.

IMO i think we should consider avoiding all this. All i think that the most we need to do is trigger building of content from VS/MD. We should dump the idea of .contentproj and instead keep the content building instructions in a format that is suited for processing. This might also fit into the idea of a stand alone GUI tool for editing content items.

[tomspilman]

Going to close this issue. The addin work Dean did is in place, but needs to be refreshed to support #2441.