I know this has been discussed in the past but I’m still unclear about this option. I understand the compressed texture options, but I don’t understand what the “No Change” option is for.
Whatever one I choose the file size of my assets gets considerably larger. For instance I have a texture atlas here which is a 1.71mb png before it goes through the pipeline. Regardless of if I select colour, or if I choose no change, the output xnb file is approx 16mb.
In fact if I compare the entire texture folder:
Before pipeline - 21mb
After pipeline - 250mb
This is pretty mental, I can’t see that this is intended in all cases. Is there no method to retain the compression the asset originally has?
AFAIK “No Change” just uses the “Color” (uncompressed) algorithm unless the source image can be used in its current format.
As for your files outputting large XNBs: When you compile uncompressed XNB formats, they will come out very large, but will load much faster. When you compile compressed XNB formats, they will store much smaller, but load slower. It’s up to you to decide what’s best for your assets. For example: if you have some assets that are really big, but it wouldn’t be a huge deal if it took a minute to load, it’d likely be a good idea to use compression so your product doesn’t have huge storage requirements. However, if you have some assets that are pretty small and need to be loaded on the fly or some such, it may be a good idea to compile those without using compression.
Seeing a 16mb compressed xnb compile from a 1.71mb png seems pretty crazy. Are you using Reach or HiDef profile? Is your mgcb set to compress? What platform are you building for? If you don’t know how to check these in the GUI tool (select the top-level “Content” object), just open your .mgcb with a text editor and check the lines under “#— Global Properties —#”
Something like…
/profile:HiDef
/compress:True
Also, here’s an article on the subject that I think would help you understand this subject more clearly: http://www.infinitespace-studios.co.uk/general/monogame-content-pipeline-why/
Hi @TheKelsam
Thanks for the info. The issue here is that we are targeting Android and iOS. iOS I believe is okay, because it supports PVRTC, so I may be able to use compression for almost if not all assets. However on Android the pipeline only supports ETC1 which doesn’t support alpha, and also gives some odd artefacts.
Therefore we can only use compression on a handful of assets, basically just a few background textures, so the saving is pretty minimal. From our point of view we’d be happy sacrificing load time for storage size, its a pretty big game with lots of texture sheets, sound effects, voice overs etc. Currently our apk is over 100mb, which is liveable, but doesn’t really give us any headroom to expand.
I’m aware I could just bypass the pipeline entirely, but I’d prefer keep everything going through one place, be fiddly if some assets go through the pipeline and others don’t.
I see. Well, you mentioned that you want to keep everything in the pipeline, and like the smaller size of the source PNG. To this end, you COULD write a custom content processor that would essentially just write your PNG source bytes into an XNB file (it would still just be the PNG data, but housed in an xnb), then you could read that PNG data in MonoGame (MonoGame supports reading textures straight from PNG sources). This would very likely come with a pretty steep load time though.
Loading a Texture2D from image data: http://www.monogame.net/documentation/?page=M_Microsoft_Xna_Framework_Graphics_Texture2D_FromStream
Another idea that comes to mind, which in my opinion is probably not a viable option, but may be something to experiment with: you could compress your assets (like in a zip format or some such), and then unpack them at load time. This would NOT be able to take advantage of advanced gpu-specific compression methods though, and therefore would come with steep load time increases.
Some reading about android compression methods, informing the app store what you use, etc, if helpful: https://developer.android.com/guide/topics/manifest/supports-gl-texture-element.html
It may be worth your time to look through the source on how the pipeline builds texture xnbs for android. I don’t target android myself, so my experience here is pretty limited, but IIRC there was some work in the past to have the pipeline auto-select some compression methods that would be appropriate given the source material and target platform. Example: if your image is 1024x1024 (both square and a PowerOfTwo size), the pipeline would be able to select an android-specific compression method that only works with these types of specific requirements.
1 Like
Ah thanks. I’m daft, don’t know why I didn’t think to add a custom processor. Your right was trivial, essentially just renames the file. And our texture folder is now only 70mb (still uses compression on some bg assets which will increase file size a little). So all in all a huge improvement!
Regarding load times, I don’t actually see a noticeable difference. I’m testing on a pretty old device so it was never that quick, but if it has increased its not such that I can notice.
Thanks again for your help!
1 Like