NETWORKING COMMING UP NEXT!

The one we all were probably waiting for ... and is comming along nicely!

Some features we will find:

• Reliable UDP, ordering, etc.
  Packages can be sent to a specific player and to all players on the session.
  360 players can join Windows sessions and viceversa.
  Player-to-player voice.
  "Lobby" management so as to sync games (isReady and isEveryoneReady properties).
  and much more.

Some we don't by now: Game invites, Leaderboards, etc.

Some we probably won't (or at least in the middle run):

• Ranked matchmaking.
• Achievements.
• Raw sockets.

A couple of great questions:

• ¿Dead Reckoning? Nope. This version will provide basic functionality, so you should build upon it by yourself.
• ¿Beta Public Release? Maybe in a couple of months (more good news!).
• Didn't get the answer about the kind of suscription to play networked games (silver or gold), maybe gold? Sorry about htis one.

Btw, if after building the game you try to host/join a session but get an unhandled exception, just recompile your code and try again ... :)

GAINING SOME PERFORMANCE ON XNA GSE

Man! I really need to get Shawn' slides ... very useful info and tips to program game using XNA GSE, both for Windows and the 360. He covered many areas, like graphics, math, threading and profilin tools.

Hereunder you will find some bullets:

• Graphics: Shawn mentioned things like the spritebatch, then shaders, materials and effects, and finally renderstates. Some conclusions: use the GPU the most you can, don't forget to set SpriteSetMode, undesrtand the 360 system's calls and avoid the use of states blocks.
• Math: is incredible how one can gain some performance by passing structs by reference and inline some computation. About the latter, constructs can be manually inlined (an example was provided). Those of us who have experienced .NET Framework 3 and 3.5 do know that the way this is handled in those versions of the .NET framework is quite handy.
• Threading: a must! To take advantage of this feature on the 360 one have to understand how the cores and threads per core are organized as well as the fact that one must manually assign threads to the 360's cores (this is not done automatically for you). Also take due note that the Content Manager is not thread-safe and input handling is not threadable on windows (meaning, it has to run on the main thread, always).
• Profiling Tools: there is not much help on the 360 to identify bottlenecks, thus, profile on windows and do some inference (of course, remember the way the compact framework deals with the GC and generations).

There were more points to mention about Shawn's presentation plus plenty of smart questions, but you'll have to watch the webcast later to get all of them ... ;)

Phew! ... a 30 minutes brake. Thanks so much! I need some rest ...

THE 10 RULES TO AVOID UNWANTED PERFORMANCE COSTS

"... measure, measure, ... , and measure". Yeap, that was what Rico Mariani said during the fourth webcast. The sooner you diagnose, the better.

The spirit associated to the above-mentioned "axiom" is driving your application to pay the costs of using managed code at the proper time, where and when you can afford those costs.

All the slides where quite interesting, and many relevant things were stated like:

• "not all the dots are created equal" (this is related to "inlining").
• structs are not as weel handled as reference types (although structs are sometimes preferable).
• exception handling constrains optimization, and
• many more.

Finally, there was a great comment, the proof for non-believers that managed code is suitable for game design are all the games that were created for the 360 using managed code (through XNA GSE, of course).

Well, now is Shawn's turn, so gotta go again.