I’ve seen some sluggish performance in the VS2010 ide, and thought i’d share how i improved performance:

1. Go to Tools —> Options drop-down menu
2. Click Environment —> General from the list
3. in the VisualExperience box:
4. Uncheck “Automatically adjust visual experience based on client performance” 
5. Uncheck “Enable rich client visual experience”.
6. Press OK then restart visual studio.

That doesnt seem to make everything super fast, but it does help make it not-so-slow =D

-JasonS

If you’ve ever had to do something like this:

if(someObject is MyType)
{
var myClass = someObject as MyType;
myClass.DoStuff();
}

then give this a try in critical (perf) sections instead:

var myClass = someObject as MyType;
if(myClass!=null)
{
myClass.DoStuff();
}

it reduces your cast operations to 1 instead of two, and offers similar readability.

enjoys

-JasonS

we are about 2/3 through our post e3 “fix up” month, and thought i’d share a tiny bit on what we are doing:

What was wrong with our E3 demo:

The e3 demo was pretty, but had some technical issues:

1. world objects were atomic only:
   this means buildings were a single, opaque object.  not because we only support atomic objects, but I didn’t want to spend time finishing the implemenation of composite objects until we were sure about the entire workflow, which leads to: 
2. the game object system was not extensible:
   our “Element” system (atomic and composite) was high performance, but extending it was not easy: a single manager class that needed to be extended as a monolithic singleton.   not good for supporting various game object categories.
3. the visualization system was a nightmare:
   well not a nightmare really,  the system worked, but was overly complex architecture, plus difficult to extend.  We have a deferred rendering pipeline, and the rendering system was designed with only that in mind.   So extending rendering for use with particles, etc was difficult. 
4. rendering suffered performance issues:
   CPU stalls waiting for the GPU,  plus mysterious cpu spikes of up to 30ms shows significant risk in the current rendering architecture
5. misc system design issues:
   the particle system and physics system were fairly poorly designed (lacked required features) and need some architecture changes 

Tomorrow, I’ll start talking about the steps we are taking to resolve these issues.

-JasonS

I’m working on rendering infrastructure right now, and came up with an idea for how to store and sort renderPackets based on criteria efficiently using a binary heap.

What’s the BCL got?

That’s great, but I remembered seeing an MSDN article on a new BCL collection called SortedSet<T>

Nice features

It’s pretty sweet.  As this CodeProject article describes, it has a neat Sub-Tree filter that can be used to partition the view, and it has good CPU performance with O(LogN) time.

Not good enough

Unfortunately, it seems like the BCL team is lapsing a bit on QC:  SortedSet<T> is implemented using classes for Nodes, not structs.  This has massive, harmfull, repercussions on CF.NET, and therefore makes SortedSet<T> unusable for a core, high-performance game system.

What’s to be done?

Thankfully, I can salvage the goodness of SortedSet’s features by implementing my own version of the class using a struct Node[] array as storage.  It’ll take a little time, but I can use the BCL API’s as reference, and that will give me a SortedSet that offers good CPU and GC performance.

-JasonS

I’m very interested in knowing/learning about the .NET CLR and it’s (in)abilities on various frameworks.

Here at Novaleaf, we focus on XB360 and PC,  but we will most likely get into WP7 after our next game ships, so I found this link interesting…  hope you do too.

ArsTechnica’s the only news website I visit frequently, as though I’m busy, I need to “keep up with the joneses” as they say.

This article on multithreading, (or rather, the industries lack thereof) made me think of Novaleaf’s solution.  I’ll shortly describe what we have now, why we are not using it, and what we have an idea for in the future….

What we have now

Thankfully I consider multicore development one of my strong suits.  By strong, I mean 2 years ago I wrote a lock-free queue, logically verified that it was free of race conditions, and experimentally stress-tested on a 4 proc machine. 

So a few years ago, I took a few months and wrote a task parallel framework.  This was before the .NET’s TPF and other thread-safe collections, so I was quite a bit “ahead of my time”.  It all works great, and we still have it today.

Why we are not using it

The problem I discovered however, as the ars-technica article describes, is that the lack of multicore experience/understanding by my dev team, coupled with the disasterous side-effects we’d encounter if I forced them to learn on our project, led me to shelf the asynchronous framework I worked so hard to perfect.

Also, my implementation used classes (objects) for the tasks, and that may be a potential disaster on the GC weak CF.NET (xbox360).

So, I put it aside for later.

What we will do in the future

In “the future”, once we finish our next title (using multithreading only on specific systems), we’ll be re-introducing the asynchronous task framework I developed, however will need to make it “noob proof” to guarantee inexperienced devs won’t die a horrible death.  (I planned a Dependency tree framework as a solution)  

Architecturally, I’m happy with my asynchronous ideas, and man, I wish we could integrate it now…    but, first thing’s first, get our next game done :)

very important for “realtime simulations” is how to optimize for performance.

on the desktop.net CLR, the GC is robust enough to (usually) allow you to get away with classes for everything.

However on the XBox360, and especially smaller platforms like WP7, which use the CF.NET, object allocations run into the GC performance issues.

The first step to recovery is to know the difference between the Heap and the Stack.

I’ll follow this up with another post further describing CF.NET woes.