Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
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

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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.