-
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
- SongProcessor
- XNB writing
Tom
- Build infrastructure.
- Command-line tool.
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.