-
Notifications
You must be signed in to change notification settings - Fork 5
Content Build Pipeline
A port of XNA 4.0's Content Build Pipeline is currently in development. This will allow assets to be compiled into optimized binary formats for all platforms supported by MonoGame without requiring XNA Game Studio 4.0 to be installed on a Windows PC. The asset compiling will be done when the project is built, and supported in both Visual Studio (2010 and 2012) and MonoDevelop (Windows, Mac OS X and Linux).
Every class, enum, method and property has XML Documentation. This documentation has currently been populated from the public XNA 4.0 documentation. All private members should also have XML Documentation to aid MonoGame developers and to keep everything documented.
All code adheres to the MonoGame Coding Guidelines.
The bulk of the public API has been at least stubbed out from the public [XNA 4.0 documentation](http://msdn.microsoft.com/en-us/library/bb200104(v=xnagamestudio.40\)). Some parts of it have been implemented, but there is still a lot to be done to flesh out the full implementation.
It is currently for Visual Studio on Windows only. Mac OS X and Linux project files will need to created.
Sly
- Audio importers/processors
Built-in System and Math content type writersXNB writing
Tom
Build infrastructureCommand-line toolCommand file for MGCBVisual Studio Integration of MGCB.- Effect Importer/Processor/Writer.
Ray
Dean
James
The best way to build and test improvements to the content pipeline is to use the MonoGame Content Builder command line tool.
When you open the solution it includes references to the pipeline and framework which makes development of stock content features fairly easy. For testing you might find it easiest to use a response file which you can edit in notepad.
See the preliminary documentation for further details.
The XNB file format has been documented by Microsoft. We will implement those documented object formats in version 1 of the content pipeline.
The fourth byte denotes the target platform for the XNB file. Currently this has three options:
- 'w' for Windows
- 'm' for Windows Phone 7
- 'x' for Xbox 360
The plan is to add additional options for the platforms supported by MonoGame.
- 'i' for iOS
- 'a' for Android
- 'W' for Windows Store Apps
- 'M' for Windows Phone 8
- 'o' for Windows OpenGL
- 'd' for Windows DirectX 11
- 'X' for Mac OS X
- 'l' for Linux
- 'p' for PlayStation Mobile
- 'n' for Google Chrome Native Client
- 'r' for Raspberry Pi
Version 1 of the content build pipeline will generate uncompressed XNB files only. Compression options may come afterwards. XNA's compressed XNB files used LZX compression, denoted by the high bit (0x80) in the sixth byte being set. The only other used bit in that flags byte is the low bit (0x01) to denote Hi-Def content. There are six spare bits in the flags byte, so we could use another bit, e.g. 0x40, to denote an alternative compression scheme. The bit would be unset by default, maintaining compatibility with the existing compression format. If the bit is set, it could denote a platform-specific compression format (a compression format that works best for that platform).
Any further changes may require an increment of the XNB format number (fifth byte). This would allow us to modify any field after that byte, but is something that would have to be discussed and agreed upon before implementing.
MP3 files in games is a licensing nightmare. As seen on the MP3 licensing website, games that distribute more than 5000 copies are liable for a $2500 licensing fee.
http://www.mp3licensing.com/royalty/games.html
This directly affects any developers who would use MP3 files in a game, free or paid, and would be even worse if the MonoGame content pipeline produced the MP3 files that were distributed with the game.
The guys who make Construct 2 have written some good articles clarifying the licensing issues with distributing music in games. This is a link to the fourth article, though it is good to read the three earlier articles linked within as well.
https://www.scirra.com/blog/65/even-more-about-audio-licenses-on-the-web
They explain quite well why they do not support MP3, and all the same reasons would apply to us as well.
MP4 AAC is a well supported playback format, but we would have to be careful there too. Distribution of AAC encoded files is no problem. Distributing an encoder would incur licensing fees. Construct 2 works around this distribution requirement by using the AAC encoder distributed with Windows 7 (not included with XP or Vista). This has its caveats though, as the Windows 7 AAC encoder is not the best quality. Mac OS X provides AAC encoding through the CoreAudio framework.
AAC licensing information
http://www.vialicensing.com/licensing/aac-overview.aspx
Android supports OGG files, for which there are no licensing issues for distribution of encoded files or encoders. Unfortunately iOS does not support OGG playback.
WMA (for Windows 8, Windows Phone 8 and Windows DirectX11) should not be an issue because we can use APIs included with Windows to create the WMA files, and I believe there are no issues with distributing WMA files.
We should support creation of the following music formats in our content build pipeline:
- iOS: Support creation of AAC via host-provided APIs.
- Android: Support creation of AAC via host-provided APIs and OGG.
- Windows (8, Phone 8, DirectX 11): Support creation of WMA via host-provided APIs.
- Mac OS X: Support creation of AAC via host-provided APIs.
- Linux: Support creation of OGG.
- PSM: According to the PSM site, the PSM runtime supports MP3 playback (1 or 2 ch, 44100 or 48000 Hz, 128-320- kbps).
We can still import WAV (Windows/OS X/Linux), MP3 (Windows/OS X) and WMA (Windows) using OS-provided APIs as the OS provides the decoders. Linux gets the short end of the straw as the OS provides no encoders or decoders, so import and export options are quite limited, most likely down to MonoGame providing a WAV decoder.
In all cases, we allow playback of all formats supported by the platform, and the licensing of any MP3 content is up to the developer if they choose to do so.
Adding support for passing through a ready made song would be simple. For this, we do not need to worry about encoders or decoders either. It will have to be a format the target platform supports, but that will be trivial to enforce. It also puts the onus for licensing on the developer and keeps us liability free.
The main point here is that we don't prevent the developer from using license-encumbered formats, but at the same time we don't help or promote the developer potentially getting into a sticky licensing situation. MP3 is the only format I know of that has licensing on distribution of encoded files. The other format licensing issues are with us distributing encoders and decoders.
According to the PSM dev portal, PSM supports playback of sound effects with the following parameters:
- Num Channels : 1 / 2
- Sampling Rate : 22050 / 44100 Hz
- Sampling Bit Depth : 16bit only
- Linear PCM only
The SoundEffectProcessor should enforce these restrictions when building content for PSM.
To generate ATITC textures, we may require the user to supply their own compressed textures or to download the Adreno SDK themselves and provide our content pipeline with the TextureCompressor.lib supplied in the Adreno SDK. This is due to licensing restrictions on redistribution of parts of the Adreno SDK. ATITC is subject to a patent and there are no alternative texture compressor tools available.
On Linux platforms, we may come across this issue where S3TC (DXT1,3,5) support requires extra packages to be installed by the user. Psychonauts (and other games) needs GL_EXT_texture_compression_s3tc