I was previously using MonoGame 3 (Windows app) and switched to 3.4 (WindowsDX). When I used the new Pipeline tool to generate my XNB files (primarily .PNG fiels), the size of the new XNB files got way bigger, from 100 megs total to 300 megs total. This is because some .XNB files were mere kilobytes built the old way and are now often over 3 megs built from the new tool.
Anything I can do in order to reduce the size of these or is that just the price I pay for upgrading?
In the Pipeline GUI, try changing the TextureFormat field to Compressed or DxtCompressed. Or, alternately, you could just keep using the .xnb files generated by the older content builder.
Thanks for the suggestion, that might work if all my art was in powers of two, but that isn’t the case. I get all kinds of errors like the one below when building my content which leads to barely anything being compressed…
Using DXT Compression
Could not compress texture Microsoft.Xna.Framework.Content.Pipeline.PipelineException: DXT Compressed textures width and height must be powers of two in GraphicsProfile.Reach.
at Microsoft.Xna.Framework.Content.Pipeline.Graphics.GraphicsUtil.CompressDxt(GraphicsProfile profile, TextureContent content, Boolean generateMipmaps, Boolean premultipliedAlpha, Boolean sharpAlpha)
at Microsoft.Xna.Framework.Content.Pipeline.Graphics.GraphicsUtil.CompressTexture(GraphicsProfile profile, TextureContent content, ContentProcessorContext context, Boolean generateMipmaps, Boolean premultipliedAlpha, Boolean sharpAlpha)
at Microsoft.Xna.Framework.Content.Pipeline.Processors.TextureProcessor.Process(TextureContent input, ContentProcessorContext context)
Is there anything I can do to get around this requirement? I don’t believe XNA or previous versions of MonoGame forced this.
Yeah, I noticed that when I tried building a compressed .xnb. I don’t know of any other way of compressing content—I’ve never bothered trying to compress the .xnbs. Sorry about that.
To use DxtCompression you must use a texture which has width and height of power of two. Easy way to do this is to enable “ResizeToPowerOfTwo” under Texture Processor settings.
That resizes the textures though… ie once they’re in the game they aren’t the right sizes anymore. It does shave things down from 300 to 200 megs, but given they don’t look right because they’re the wrong size, that’s no good.
I might just end up keeping an old VS2010 project around and use the XNB files created from there, tried a bunch of different settings for building last night and nothing works as well as the old way. Plus for some reason transparency on a handful of png files no longer works either.
GraphicsProfile.Reach had the requirement that DXT compressed textures have dimensions that are a power of two. GraphicsProfile.HiDef does not have this requirement, but dimensions must still be a multiple of four.
To set HiDef profile, in the Pipeline GUI tool select the top most node in the project and change the GraphicsProfile property.
So using the HiDef profile brings me back to 150 megs (originally 100, then 300 with the new content builder). That’s an improvement but…
On a handful of the textures (most work fine), I get this error when calling content.load.
HRESULT: [0x80070057], Module: [General], ApiCode: [E_INVALIDARG/Invalid Arguments], Message: The parameter is incorrect.
Literally no changes in the code, just changing from Reach to HiDef causes this. I don’t see any reason why it would throw this for one texture but not others.
One year later… looks like the problem is still here.
Including a 100kb png turned into a 4Mb xnb…
Setting to DxtCompressed option, it’s still a 1Mb file
Graphics content gets optimized for getting loaded by the graphics card, it does not try to make content as small as possible. Read up: http://www.infinitespace-studios.co.uk/general/monogame-content-pipeline-why/
Thank you for the insight @harry-cpp, I understand better now what the content pipeline is all about.
But this would lead to a huge size for a finished game.
Now I’m thinking: Would it be a good idea to build all the xnbs from an installer?
Installers are usually having the included data compressed, there really would be no point in using already compressed data. Steam also has a way of compressing games that you download and extracts them once downloaded.
yes, that’s what I was thinking afterwards.
There are so many other things to worry about.
Thank you @harry-cpp for your help =)