I was wondering why the Network State Management Sample uses 1067 x 600 as the preferred back buffer resolution.

Is this a recommended screen size? I see that the XBOX 360 version of the sample also uses that same resolution, is that a good programming practice in XNA?

In my DBP entry game I used the following code, should I stick with this method?

 

1067x600 is 16:9 with a 600 lines high screen. However, that's a terrible resolution, as it's not divisible by 8 on the horizontal scale. Better resolutions for 16:9 include:

1280x720 -- native Xbox HDTV, least chance of scaling artifacts
864x486 -- NTSC style EDTV
1024x576 -- PAL style EDTV
1920x1080 -- full, glorious HTDV, but tile rendered (slower)

So, you're already doing one better than the samples.

You wouldn't believe how long we debated what resolution our samples should use :-)

The main criteria were:

• Should be the same on Windows and Xbox (don't want to clutter samples with platform conditionals)
• Should be a 16/9 widescreen ratio (so as to work on all Xboxes regardless of output aspect ratio)
• Should fit in a window on a 1024x768 PC desktop

After a truly ridiculous amount of argument, we settled on 853x480, which while certainly not perfect, met the above requirements and wasn't too violently offensive to anyone.

But then when we added networking, it turned out the Windows version of the Guide needs at least 600 vertical pixels to avoid getting cropped. Which triggered a repeat of the entire previous debate :-) In the end we left all non-networking samples using our previous choice, but picked 1067x600 for samples that use the Guide, as that is the smallest 16/9 resolution with enough room to display it correctly. This does go slightly off the edges of a 1024x768 desktop, but not by so much that the samples are unusable, and it fits nicely on the more common 1280 wide desktops.

I don't think those resolutions are sensible choices for games (you should probably go with one of the ones Jon suggested), but they make sense for samples where the goal is just to get consistent behavior without any special casing, so we can demonstrate whatever technique the sample is showing with a minimal amount of resolution handling code to clutter things up.

Yes, 1067 and 853 are so easily divisible by 8. It totally makes sense to use those resolutions.

No, wait...

:-D
In your case, I'd have used the PAL EDTV resolution, and cut 24 pixels from the guide.

Who says a resolution has to be divisible by 8?

Back in the day, I learned it was more efficient to do that. And, no, this was not before 32-bit graphics was around, thank you very much :-)

Probably has something to do with frame buffer compression or hierarchical Z or something -- today the only "problem" might be that the device allocates some extra pixels on the side, and clips them out using scissoring, which is basically a non-problem on modern hardware. Scissoring (and guard bands) wasn't always free, though!

Thanks to both of you guys. That was what I was looking for.