Question

I have a list of entities which implement an ICollidable interface. This interface is used to resolve collisions between entities. My entities are thus:

• Players
• Enemies
• Projectiles
• Items
• Tiles

On each game update (about 60 t/s), I am clearing the list and adding the current entities based on the game state. I am accomplishing this via:

collidableEntities.Clear();
collidableEntities.AddRange(players);
collidableEntities.AddRange(enemies);
collidableEntities.AddRange(projectiles);
collidableEntities.AddRange(items);
collidableEntities.AddRange(camera.VisibleTiles);

Everything works fine until I add the visible tiles to the list. The first ~1-2 seconds of running the game loop causes a visible hiccup that delays drawing (so I can see a jitter in the rendering). I can literally remove/add the line that adds the tiles and see the jitter occur and not occur, so I have narrowed it down to that line.

My question is, why? The list of VisibleTiles is about 450-500 tiles, so it’s really not that much data. Each tile contains a Texture2D (image) and a Vector2 (position) to determine what is rendered and where. I’m going to keep looking, but from the top of my head, I can’t understand why only the first 1-2 seconds hiccups but is then smooth from there on out.

Any advice is appreciated.

Update

I have tried increasing the initial capacity to an approximate amount of elements, but no difference was observed.

Update

As requested, here is the code for camera.VisibleTiles

public List<Tile>
{
    get { return this.visibleTiles; }
}

Answer 1

Whenever you have a performance issue like this, the correct response is not to guess at what possible causes might be; the correct response is to profile the application. There are a number of options available; I’m sure you can find suggestions here on StackOverflow.

However, I’m feeling lucky today, so I’m going to ignore the advice I just gave you and take a wild guess. I will explain my reasoning, which I hope will be helpful in diagnosing such problems in the future.

The fact that the problem you describe only happens once and only at the beginning of gameplay leads me to believe that it’s not anything inherent to the functionality of the list itself, or of the collision logic. This is assuming, of course, that the number of objects in the list is basically constant across this period of time. If it was caused by either of these, I would expect it to happen every frame.

Therefore I suspect the garbage collector. You’re likely to see GC happening right at the beginning of the game-in other words, right after you’ve loaded all of your massive assets into memory. You’re also likely to see it happen at seemingly random points in the code, because any object you allocate can theoretically push it over the edge into a collection.

My guess is this: when you load your game, the assets you create are generating a large amount of collection pressure which is nonetheless not sufficient to trigger a collection. As you allocate objects during the course of gameplay (in this case, as a result of resizing the list), it is increasing the collection pressure to the point where the GC finally decides to activate, causing the jitter you observe. Once the GC has run, and all of the appropriate objects have been relegated to their correct generations, the jitter stops.

As I said, this is just a guess, albeit an educated one. It is, however, simple to test. Add a call to GC.Collect(2) prior to entering your render loop. If I’m right, the jitter should go away.

If you want to be more thorough than that-and I highly recommend it-Microsoft provides a tool which is useful for debugging memory issues, the CLR Profiler. This tool will show you exactly when collections are occurring and why. It’s very useful for XNA development.