Delta Engine Blog

For now I can only give you a little video about XNA Shooter. I hope you like it.

A "little" 1920x1200 screenshot:

These days there are a lot of discussions about XNA, especially in the GameDev.net boards and of course in the official XNA forum by Microsoft.
http://www.gamedev.net/community/forums/topic.asp?topic_id=430119
http://forums.microsoft.com/msdn/showforum.aspx?forumid=846

I also want to mention a great article by the .NET Compact Framework team about the .NET performance on the Xbox 360 with the XNA Framework. The main issue here is the Garbage Collector, which is not generational and theirfore can only collect all the objects in the GC at once and not in 3 levels like in the normal .NET Framework, which can handle a lot more dead objects and more complicated situations.

Here are the links to the .NET Compact Framework on XNA article:
http://blogs.msdn.com/netcfteam/archive/2006/12/22/
managed-code-performance-on-xbox-360-for-the-xna-framework-1-0.aspx
http://blogs.msdn.com/netcfteam/archive/2006/12/22/
managed-code-performance-on-xbox-360-for-xna-part-2-gc-and-tools.aspx

From my experience there are a couple of things you have to remember when developing XNA games on the Xbox 360. All of these issue are not a big deal on the PC, but they can cost some extra time until you get them right. One of the main problems is that if you develop your game on the PC only and then test it on the Xbox 360 only at the end a lot of things may go wrong (bad performance on the .NET Compact Framework, UI elements at the border of the screen, which are just not visible on some TVs, bad Xbox 360 controller support, which is the main input device for Xbox 360s, etc.).

• Test test test. This is the most important tip. Write unit tests and constantly test them on your PC AND your Xbox 360. I keep 2 projects open at the same time (both of them use the same files, but I only develop the PC solution and use the Xbox 360 solution for deploying and testing only). Almost all of my classes have unit tests and I constantly test them until they are completed.
• Don't use foreach loops, especially not in tight render loops. This may sound a little crazy since it does not matter on a PC game and todays CPUs are fast enough to handle the creation and deletion of many thousand objects each frame, which most games don't even need. But on the compact framework you will spam the memory even with things like foreach loops because a new enumerator instance is created everytime you start a foreach loop. After a while there will be a lot of dead objects, which have to be collected. This can take some time and slow your game down immensely. The PC version might run at over 200 frames, but your Xbox 360 version is stuck at something like 30-40 frames. Avoiding creation of new data each frame and avoiding foreach loops (just replace them with normal for loops, it is mostly just 1 line of extra code) can improve your performance by a factor of 100% or more.
• In Arena Wars I never created any data during the game. All objects were created at the beginning of each mission and they were reused (which was no big deal since the game principle did not allow an infinite number of units, it always stayed around the same because you get your money back from dead units to build new units). In later project I did not care so much about creating new objects and I coded just the easy way because unit tests drive you into a direction to quickly develop solutions, which work and are tested, but may not be the best in other situations like for the Xbox 360 .NET Compact Framework. That is ok because we can now use the unit tests to check if other solutions work just they way we expect them to work. For XNA Shooter and XNA Racer (and a couple of other new game projects) I now make sure that most of the game data is created at the beginning of each level and not dynamically during the game.
• Save-Regions on TVs can be a pain in the ass. Just google for Xbox 360 screenshots and you will notice that the GUI (graphical user interface) looks a lot different from most PC games. PC games have often UI at the screen border showing you tips, little buttons and other not so important things. If you do that in your Xbox 360 game all of these UI elements may be cut of on a regular TV. For the XNA Shooter I had to rework all the UI elements because they just did not fit on a TV screen and it was not practical to put them in a bar (like the windows task bar) because it looks so different on the PC and certain TV monitors. Instead I put all UI elements in floating bars, which will be adjusted depending on the screen the user is looking at.
  These are some of the Save-Regions I have encountered:
  
  • PC: 100% visible
  • Xbox 360 connected through a VGA cable: 100% (or close to 100%) visible.
  • Xbox 360 connected to an old style monitor with SCART: around 92% visible.
  • Xbox 360 connected through Component cables to my new Dell 24" Monitor (yeah HDTV): around 93-95% visible (depends on the resolution).
  • Some old TV sets (according to the XNA docs and tips on the web) have a save region of 80-90%, but I never saw the 80% case, that is probably the worst case scenario.
  The important thing is to keep the important UI element in this inner 90% (or 93% if you want to be close to the edges) rectangle. This means instead of using a full 1920x1080 pixel resolution you only use 90% of it (1728x945). Or just start rendering UI elements at about 5% of the screen (x coordinate: 96, y coordinate: 54). This pixel locations obviously depend on the screen resolution, just calculate them in your main class and use them whenever you render UI.
• There are probably a lot more tips I can give, but I'm to lazy right now. Maybe more in a little while :)

Btw: I currently also do a lot of OpenGL development again and I have to say I have totally forgotten about the way you can program OpenGL. It is often a lot easier, it only gets hard if something does not work the way you expect it to be (but thats hard in DirectX too). Well, the most annoying part is of course that you have to wrap all OpenGL methods through PInvoke and that just costs time. On the other hand if you already have a robust framework (like I have with Arena Wars, hehe), it is relatively easy to plug in new features. It also took not long to learn the differences between glsl and hlsl. I do currently also test out the FX Composer 2.0 (alpha), which has a great idea behind it, but it is too much like Render Monkey and that is never a good thing. Render Monkey by ATI is just overcomplicated and hard to use (and was not updated for 2 years, which shows that no one even uses it anymore). The great thing about FX Composer 1 was the fact it was so easy to use and it did only support a very limited feature set. It is not the best tool ever, but it was certainly a lot easier to use than FX Composer 2.0, which will hopefully be improved before NVidia release it.
I have confidence that NVidia will deliver a great tool as always, but they have lost a lot of fans in the last months because of the lack of drivers for Vista, especially for the Geforce 8800, which does not work at all in Vista, but it is the only card on the market that even supports Direct3D 10 (and the new cool unified shader technology in DirectX). The only way you can currently use the new graphic card features is to program them yourself natively with OpenGL ... but my 8800 is in repair anyway, else I would have tried out some of the new features by now.