Recently I’ve been working on a game that loads stuff using the contentpipeline.
Now I know that I should convert png, jpg,…-files to xnb format to reduce the usage of GPU memory in game (even though it’ll take longer to load the xnb’s).
Now I’ve come to the point where I’m loading data for certain objects in the game. The data of the objects are stored in an xml file. One of the object that I’m deserializing for example is “WeaponData”, wich contains simple serializable fields like WeaponName (string) Damage (int), ReloadTime (int), …
Now I can choose to simply deserialize the xml at runtime or I could make a contentprocessor that converts the xml-file to a xnb and then load the xnb in game using the ContentManager.
So my questuin is; should I make contentimporters for xnb files, that are actually just xml files? Does it have any performace impact? What advantages/disadvantages are there?
It’s exactly opposite from this. .xnb files might take up more space than a png but they’re optimized for load time. And GPU memory is the same unless you enable compression in the Pipeline Tool, in which case the .xnb will take up less GPU memory. Note that .jpg and .png are compressed file formats, but they cannot be rendered directly by GPUs and therefore have to be decompressed before uploading the image to the GPU.
MonoGame has built-in support for serializing and deserializing classes to/from xml, you don’t need a custom importer. Benefit is that loading content is faster.
I’d like to learn more about the pipeline compression. I have tried googling around a bit but haven’t been able to find much about the standard compression, only DXT compression. We have several PNGs that are bulit from about 5mb into something close to 300-500mb XNBs. I’d like to learn about the different options pros/cons and what’s required to use them (image resolution requirements and such).
It’s my understanding that the Content Pipeline tool almost performs more of a decompression. It lays the pngs out flat in an effort to trade disk space for much faster load times. This way data can be loaded and sent directly to the GPU with minimal processing.
Right, but there are several TextureFormat options for the process. The default being “Color” (fully uncompressed with all features for alpha/color/etc). There are a few other options, such as Compressed or DxtCompressed. DxtCompressed will still make a larger XNB (because it’s not a super compressed PNG, etc etc), but it stores the image bits in such a way that it’s fairly more effecient (4x4 grids with bit references and such - you can read about this with some simple googling). The issue with DxtCompressed is that it’s very lossy (the image looks pretty bad afterwards, unless it was already a pretty grainy or non-vector-ish image to begin with). So, I’d like to learn more about the other options so I can select what will be best for my assets in terms of storage and load times.
Compressed is the platform default. The other compressed formats are all comparable. For desktop you should do either DXT or uncompressed (Color). If you’re only worried about file size, turn on compression on the root project node in the Pipeline tool. That will compress all .xnb files. DXT compression is useful if you want to reduce GPU memory usage, because that can be sampled without decompression on desktop.
The bigger concern is file size, yes, but also GPU memory usage. In any given level of our game (a relatively simple 2D platformer) is currently loading in close to 1GB of assets (XNB images). In PNG format, these assets are something like 40mb. I understand that’s not a fair comparison, but I know other games don’t require >1GB video ram to run a simple 2D game heh
I will take a look at the root-level compression option for sure. Is there any documentation or some such I can read about the pipeline tool compression / related material?
Enabling root-level compression took the whole game from over 2.5GB to a little over 100MB xD Everything still looks fantastic and I didn’t have to modify any images or anything. So, problem super solved it would appear heh, thank you! Although, I’d like to know what is happening there, and if there are any downsides I’m unaware of, etc.
The downside is that loading content takes longer because it’s decompressed by the ContentManager. The compression used is LZ4. It’s as simple as a flag in the .xnb file and all content after the header is compressed.
Good luck!