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.

PRE-MORTEM: SCHIZOID

What an interesting webcast this is: Jamie Fristrom & Bill Dugan (from Torpex Games) are commenting on their whole experience to bring Schizoid to the XBox Live! Arcade.

I do agree to what they have said about C#:

• the C# vs. C++ discussion for game development is like "C++ vs. Assembly" many years ago. With C# you forget about pointers, and that alone says a lot. Plus, performance, speed, etc. is becoming less and less an issue as many games, demos and samples demonstrates, and
• you don't need to use external languages for scripting (of course, you can do it if you want to), since you can use c# itself as a scripting language (as I said on this blog and on others' blogs).

In short, C# will rule (read my first posts).

What I don't agree -at least, partially: and I know Benny is also gonna hate me for this, is that Test-Driven Development is great for creating "proof-of-concepts" and prototypes -so as to bring your ideas close to the "real" thing quickly (and get some nasty bugs on the initial stages), but from a design viewpoint, relying only on tests to write the "final" implementation/output from scratch could be messy for the final stages and as a base for future projects (one could deem it as a "too aggressive" way of programming, again, only the final product, not the proptotypes).

I mean, you may find yourself in the need of changing many places to get the final product as well as to create future products (like "this class should be responsible for rendering this and that" -instead of the original class- and things like that) . And that could worsen, the bigger the game project, IMHO, of course.

With this I'm not saying "this approach is better than those", "don't use a rapid approach" or things like that. Instead, I'm saying "balance" is the key to a well-designed software. One should find its own approach -mostly if you're going solo, ... the one that you are most comfortable with, but it doesn't mean you have to use one and only one approach. In fact, your way of designing and programming games could be a mixture of methodologies derived from the type of project, available resources (including staff), time/stage/deadlines, and budget (estimated and current costs and ditto for funding).

Why "balance"? Because as these guys' just said (non-textual quote) "if you plan and discuss too much you face the risk that your project gets cancelled ..." (it doesn't matter whether you were implementing it or not), to what I must add, "... but if you plan too little you face the risk of having to redesign a lot of code at later stages."; both extremes could complicate things up in the end. So get the balance, optimus, equilibrium ("sounds" like a yoga class).

Now, I want to listen the round of questions, so bye ... for now!