Take the tour ×

WP7 textures are supported in the Reach-Profile that WP7 devices falls into. But XNA converts all my ressources upon adding them to a project to RGBA8, that's insane, the displays of WP7 devices are 16 Bit!

Information: WP7 SDK 7.1 (XNA 4), Visual Studio 2010

Question part 1: How can I add a RGB565 texture to a XNA project and what is the correct way to load them inside a game?

Question part 2: Is there a reasonable 16 Bit texture format (within Reach) that supports alpha with MORE than 1Bit?

Question part 3: Is the normal rendertarget (I think that's what the screenbuffer is?) already 16 bit?

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

Question 1: When adding a texture with the default Texture - XNA Framework content processor it gives you three choices in the Texture format property: Color, Compressed and No Change. You must set No Change and use a source texture that is already in a 16-bit format; for example a PNG image or a DDS image. Or, you can do your own content processor and force change of all your textures to 16-bit (although it is a bit overkill).

Question 2: The available 16-bit formats are 565 (no alpha), 5551 (1-bit alpha) and 4444 (4-bit alpha). Or, you can use DXT5 that has 32-bit alpha, although this will kill your soft gradients and give them a blocky appearance.

Question 3: Maybe, maybe not. It depends on the hardware and OS version. Some phones set 16-bit by default, but ALL of them support 32-bit. So, to make sure you have a 32-bit backbuffer, go to the constructor of your Game class and set this line:

graphics.PreferredBackBufferFormat = SurfaceFormat.Color;
share|improve this answer
Please also add how to load the textures (or where I have to define as which format the file is interpreted) for question 1 (the last line of the question), everything else is perfect –  NopeAndNever Sep 30 '11 at 10:13
Whoops sorry, talk about obvious. –  NopeAndNever Sep 30 '11 at 10:39
add comment

RGBA8 textures on a 16-bit display device are not so insane. The graphics device may very well be performing all of it's calculations at a higher precision internally, then dithering down to 16-bit for the final display (this is not an outlandish concept - 3DFX did it in 1996). RGBA8 can also be faster to operate on, to sample from, etc, as it's just a matter of accessing one byte from a byte[4] array; with 16-bit - because the size of each colour component doesn't map to any native data type - the driver will need to so some (very slightly, but overhead can pile up) tricksy stuff with bit shifts and bit masks.

share|improve this answer
Primary problem in this case is that afaik XNA 4 only likes uncompressed RGBA8 (big,slow) or DXT compressed data (which loads fast but looks... ugly on non 3d textures) and uncompressed data on a mobile game that should be smaller than 50 MB is insane I have a size budget, but I get your point that 16 bit is processor-unfriendly, yet this answer ignores all questions :-D –  NopeAndNever Sep 30 '11 at 9:31
mh01: The memory wasting is a problem far worse than the little overhead that the bit masking operations produces. And depending on the hardware, there's no way to know if the full-screen dithering made by the GPU will be slower than sampling from 16-bit textures. @NopeAndNever: no, XNA 4 supports other texture formats. Lemme explain in a longer answer. –  r2d2rigo Sep 30 '11 at 9:53
Ok, thanks, please do so. –  NopeAndNever Sep 30 '11 at 10:00
add comment

Your Answer


