Not sure if this is what you're looking for, but here's a quick tip:

In the SpriteBatch.Draw calls that take an origin vector, the origin is specified in source resolution, so no matter how the sprite is scaled, the origin will remain the same. This caused me all sorts of trouble but once I got used to it, it actually makes the code much simpler when scaling to multiple resolutions.

Here is a fun fact. The X in the XNA logo is morse code.

float aspectRatio = (float)1024 / 768; or 1024.0f / 768.0f

 otherwise it will cast to int and return 0.

Check out the different overloaded version of the SpriteBatch Begin() function and you'll different useful versions of it.  One of them allows you to save the state of the graphics device which gets reset again when you call the End() function.                                                  

This isn't necessarily related to XNA but more towards game programming.  If you're creating a ton of objects that are updated and drawn the system can slow down to a crawl within minutes and you'll find yourself getting less than 1 frames per second.  A good strategy is to develop an object manager that recycles the objects that you're using when they die or are removed from the game world.  This way when you need to get a new object, instead of calling new and use memory allocation all over again you can just get the references from the manager, reset a few properties, and get a "new" object without the cost of allocating new memory on the heap.

 

EyeCrust... I love you :) That's a great idea.

As for me... Uhm... When you're creating a 3D game, and such have lots of level-geometry and models running around, using "foreach" to render all of the meshes is a bad idea. This is because whenever you hit a foreach, it actually creates allocates a new object, which results in many, many unnecessary object allocations per second.

If efficiency is a must, don't use foreach. Make your own way of looping through all the meshes.

EyeCrust:

... without the cost of allocating new memory on the heap ...

Just for the record, the cost of allocating things in .NET is near nothing ... almost literally just incrementing a pointer.  The real cost of "new" objects comes when the garbage collector runs and tries to reclaimed unused objects.  This is particularly true on the xbox360. 

I've gotten killed by GC before.  My main conclusions were:

- don't use String.toLower() and

- don't use collections.

 

Based on the profiler and performance monitor, using 4 technique collections per render was giving me 4000ms of GC per collection.
 

Jamezila:

- don't use collections. 

Erm GL trying to write a game with more than a handfull of objects then

Jamezila:

- don't use collections.

That seems a little over the top to me - collections are useful! If you're going that far, why not just say "don't write any code at all", which would run incredibly fast, but not be very interesting :-)

Certainly there are some things you can do with collections (as with any complicated code) that will cause lots of garbage. The tricks is to understand how to use them well. This is a good place to start:

http://blogs.msdn.com/etayrien/archive/2007/03/17/foreach-garbage-and-the-clr-profiler.aspx
 

I'll change to:

- don't use collections for reference values where said collections are instantiated several times per frame

 

And fyi, I think I've managed pretty well in spite of being deathly scared of foreach.  A long time ago, in a land far far away, people got along just fine with arrays :)

Shawn, I read your blog all the time; I read your post on optimizing for readability, performance, etc.  I believe readability is important, and think a for(i = 0; i < array.length; i++) loop is just as readable as a foreach loop.  However, when doing a bit of snippet pasting, I (irresponsible young C# developer) accidentally introduced about 4000ms of GC at least once a minute which had a substantial effect on gameplay--I had to run the Performance Monitor and CLR Profiler to find the culprit foreach calls.

I just think it bears mentioning that [irresponsibly] using foreach, unlike using straight up arrays, can lead to a few days of lost productivity and hair-pulling.

 

Well, instantiating collections several times per frame is far different than enumerating them!  You wont get anywhere near 4 seconds of garbage collection time per minute by enumerating collections, but you will get 4 seconds per minute if you are allocating several megabytes of memory per frame.  The belief that "foreach" is slow is misguided in the majority of cases: http://blogs.msdn.com/brada/archive/2004/04/29/123105.aspx

I also suggest reading the msdn patterns and practices guidelines on collections that are referenced from that page.