XNA Loading Performance??

Topics: Developer Forum, Project Management Forum, User Forum
Feb 5, 2010 at 9:54 PM

I'm having huge performance problems when it comes to loading my levels in my 2D platformer.

I tried to write all vertices data to XML, and then read it upon startup. While this works very well, and gives a huge cut in loading time, it is still not enough for the game to be playable. Loading takes about 1 minute for a geometry. I've also tried cutting the level geometry into segments, which has helped, but again, not enough. I've also tried playing with different AABBFactor values, GridCellSize values, etc. I've found the perfect value of both to make my levels and objects collide appropriately, but it results in a horrendously long loading time.

Is there any solution, or something i've missed? Is it possible to write the entire geometry object to XML and then read it upon startup instead?

Any help would be greatly appreciated.

Feb 5, 2010 at 11:44 PM

You are probably using a too low grid cell size if it takes 1 minute to create a geometry. Try keeping the AABBFactor the default value and only change the grid cell size for geometries that have trouble colliding.

Not really a solution, but you could cache the collision grids. We don't have anything that can help you with that, so you will have to make it yourself.

Feb 6, 2010 at 2:06 AM

Caching sounds like a plausible method of approach.

If I set the collisionGridCellSize any higher, my objects do not collide with the level properly. On corners, they move as if the corner is rounded off, and so they appear to roll up a surface that is perpendicular to the ground.

Feb 6, 2010 at 11:45 AM

Du you have vertices along the edges of the level polygon?

Feb 6, 2010 at 1:14 PM

my game takes about 5mins to load a level.. I was going to do what you said with the vertices however if that doesn't do much I'll just stick to the loading

Feb 6, 2010 at 5:43 PM

Yes, I do have vertices along the edge of the level. I draw a large texture for a level in photoshop, and then I create a geometry from that in C# using Farseer's methods. It's a horribly concave and convex structure with parabolical curves etc. I know that in itself is hurtful to loading time, so I have attempted to break it down for Farseer, by slicing the texture up using code, then passing each slice individually to farseer to have vertices generated. These are then exported to XML, and upon runtime of the game, the XML document is loaded, every vertex is plucked from the document, and is then added to the corresponding slice's vertices list. I then tell Farseer that the pre-loaded vertices list belongs to said geometry, and so cut out the entire need to generate vertices upon startup.

But from that, I load the level in slices, create geometries for each slice, and then translate the slices accordingly. But this is still taking an excessive amount of time.

If caching the collision grids would make it faster, what property of them would I need to cache? Would it be the nodes? 

Are there any other ways around this problem?

Feb 6, 2010 at 7:54 PM
Edited Feb 6, 2010 at 7:55 PM

If it indeed is the generation of the collision grid that is the problem, then it should be easy to solve with caching. The DistanceGrid class have a private distancegrid list that contains a list of ids and collision grids.

You could create a GetDistanceGrid(int) and InsertDistanceGrid(Geom) in the DistanceGrid class.

The CreateDistanceGrid(Geom) method is called from the Construct() method inside the Geom class. You could introduce an overloaded method that takes in a distance grid that you have cached earlier. The CreateDistanceGrid(Geom) method is the one taking a long time, by skipping that call and inserting a premade distance grid into the DistanceGrid class should solve your problem of long loading times due to grid calculation.

Update: Beware that this only works for non-changing geometries. If you change the size or shape of the geometry, you will have to regenerate the distance grid.

Mar 2, 2010 at 7:04 PM
To genbox: I have spent quite a while trying to make a solution to the problem I previously had. I've managed to cache a lot of data about the distanceGrid of my level, and while this has massively reduced loading time, I'm having some problems with the geometry itself. During runtime, I can view the vertices and edges of my level, and they are in line with the drawing of the level. However, collisions do not work properly. I can collide with vertices, but not edges. There seems to be no detection of solids. Also, above the centroid of the geometry's vertices, there is some form of collision occuring, but it has no visible vertices, and it is of a very odd shape. It causes the player's ball (character) to move erratically in places. I've tried to trace the collision of the invisible object, as it clearly has a shape of some kind, but it does not at all represent any part of my level's geometry. Do you know what could be causing this?