By the numbers - why so big?

r2d2-proton

My content, using JPG's, is roughly 14.4 MB.

However, the XNB version is roughly 515 MB.

About 38 times bigger than the original.

Is this normal What steps do I need to take to reduce the size of this

I'm just begining with my development but if I can't augment this behavior of the Framework I'll have to serverly strip down my game.

Maybe, I'll have to replace Content<T> altogether ( )

Lima Beans

Sorry If i cant be too helpfull, as im not sure if XNA supports the JPEG format or not, you may just not be setting it to use it correctly, but my guess would be that it doesnt support it at all since its a particular compressed format. So the advice I can give would be:

If you want to reduce the size you need to:

Have a smaller image (this is the main thing!)
reduce the bit depth in your image,
reduce the number of channels in your image.

edit: found some info on what is supported in my post below.

Lima Beans

I found this link which goes over the specific format for textures in XNA, which should be helpful in figuring out how to make the most out of your pixels for the least amount of memory =)

http://msdn2.microsoft.com/en-us/library/microsoft.xna.framework.graphics.surfaceformat.aspx

r2d2-proton

Power of 2 is not the problem

I guess I could go monochrome

And that would eliminate item 3.

Since when is an 8kb image large The issue at hand is that the framework is magnifying it 32 times. Microsoft already has the code written to read, write, and modify images in numerous formats. JPG is just one of the many that they do on a regular basis.

George Clingerman

For your JPGs, what Content Processor are you using

Michael Morton

I would suggest doing a batch convert on all of your textures to DDS and use Dxt compression on them. Then you can use the passthru processor (At least thats what i've heard) and your file sizes should be nice and tidy. The content processing time will also be cut down to nothing.

r2d2-proton

Ah yes, pick on my lack of Content processing. . .it's okay, I'll get better :)

Well, quite simply all I did was add the JPG's to the project. Nothing in my project is loading them yet (I had to deal with another problem. . .most of the night LOL).

So I would have to state the default processor that comes with the Framework. Which I might add works with my other JPG's.

I suspect that something is amiss mainly because a completely different set of textures, totalling about 4 MB, is transformed into 9.9 MB. In comparison, my 14 MB is @ 512 MB.

Joe Engalan

My guess is that your JPGs are converted to a non-compressed format and that's just how big it is.

JPG is a lossy compression format. They don't necessarily store pixels in a bit-array format (like BMP, TIFF, etc..). This allows JPG to save considerable amounts of memory. Textures on the other hand need to be accessed in a bit-array format so you can do u,v calculations, pixel based calculations, etc.

If you tried to hand-convert your JPG files to 24bit .BMP files, I would guess that all of your .BMPs would add up to ~515MB. It'd be an interesting test.

r2d2-proton

The original BMP files totaled 355 MB. Hence, why I went to JPG.

Even that is 200 MB less.

Kyle_W

I've noticed the same thing. I had a 2.5 MB JPG turn into a 24.5 MB XNB plus a 2nd ~0.XNB which was 4 MB. I guess Microsoft considers JPG files to be evil.

Lima Beans

Kyle_W wrote:

I've noticed the same thing. I had a 2.5 MB JPG turn into a 24.5 MB XNB plus a 2nd ~0.XNB which was 4 MB. I guess Microsoft considers JPG files to be evil.

Its not Microsoft necessarily, its just life dealing with video cards and hardware acceleration.

My understanding of the jpeg thing, someone please correct me if Im wrong, as I not very sure if I am on the right track ;)

Im pretty sure that the video card needs to access things in a bitarray format, which jpg is not, and video cards only support a very limited few types of compression.

I think that a jpeg is able to be a very small file size because a jpeg viewer is able to use the cpu to uncompress the image, whereas since we want the image to be on the hardware, the hardware either needs to know how to use a compressed jpeg image (which current videocards do not), or we need to uncompress it first, then send it to the hardware (which is what XNA appears to be doing for us hence the huge file sizes).

Joe Engalan

You're pretty much correct. JPG compression is good at saving DISK space. When we're talking about hardware accelerated graphics, all graphic formats must uncompress so that the GPU can have direct access to the bits.

My guess is that a .XNB file is an uncompressed format so that the XNA framework doesn't have to do uncompression on the fly.

If you have 300 MB of texture data, I'd suggest you find a better way to recycle your images or switch to 16 bit images. With huge textures, you may find slowdowns because the GPU memory has to load and unload graphics just to get a scene drawn.

Disk size < in-memory size almost all the time.

Johnnylightbulb

Lima Beans is right -> and if your content is added using the 'Sprite' processor, you won't be using the DXT compression video cards do know how to do. Add your JPEGs to the project and select the 'Texture (model, dxt, mipmapped)' processor, or for the smallest XNB-size on disk do as the others were saying and write your own processor that uses DXT (5 I think) and no mipmapping.

r2d2-proton

I have a few 60+ MB jpeg¡¯s if anyone is interested. Just post your email info and I¡¯ll send them to you

Actually, I couldn¡¯t send the images even if I wanted too because they're not mine.

I thought we were aiming for the 10-Foot experience. Popping up a clip composed of 8x8 BMP¡¯s seems to contradict that goal. Maybe the Xbox output scaling is tremendous, I don¡¯t know since I haven¡¯t done it yet.

But what do you consider to be a big image Sitting on your couch, 7 to 10 feet away, how big should the source image be

I see there are some interesting choices with the Content processing that I can play with.

Lima Beans

I would say the typical size for a "high res" texture in a next generation video game is about 512x512x32 bit which is about 1 meg, and the largest thats typically practical to use is 1024x1024x32 which is about 4 megs.


sometimes people use 1280x720 for UI stuff, and very very rarely ive seen as high as 2048x2048x32 which is around 16 megs.

Really, if your targetting for xbox, you dont want to go much higher than 1280x720 (720p), the reason being, that if you get into a situation where there is more than 1 pixel of texture for every pixel of screen, you can get some rendering artifacts, and your just going to mip it down anyways in that case. Most "high detail" textures are even just fine at 512x512, you then add detail with detail maps, bump maps, etc. Also you can often save memory when you dont need the alpha channel or dont need it at the full 8 bits.