Category Archives: XNA

Adding Physics to Sentinel using Jitter

This post will hopefully be one of many.

First things first. Go download Jitter (I’m using 0.1.7). The official web site is here http://jitter-physics.com/

Jitter is a little short on documentation but has an excellent set of demostration scenes. It is worthwhile having a look and a quick play.

The tutorial PDF (included in the package) sums up the basics.

  1. Create a Collision system (I use the CollisionSystemSAP).
  2. Create a physics World and pass the collision system.
  3. Create a shape
  4. Create a RigidBody – using the Shape just created
  5. Add the body to the world
  6. Every update loop ask the physics engine to step forward a small amount of time.

That’s pretty painless and pretty easy to get going. The Jitter libraries are very well designed, the code is well encapsulated and loosely bound.

I’m still playing with the physical properties and other parameters to get a world that “plays right”. Not too hard, not too easy but essentially realistic enough that the gamer can become immersed in shooting the baddies and protecting the oil refinary!

 

Sentinel game development – terrain and shadows

The terrain is based on Riemer’s excellent “multitextured terrain” tutorial. This is strongly recommended for any developer looking at clever multitexture techniques. http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series4/Multitexturing.php

The code is a little old, it predates the XNA 4.0 framework so some bits need tweaks to enable it to compile.

Simple control added with the ability to control the pitch and yaw of the guns.

Fixing Garbage Collection issues when developing for XNA and XBOX 360

The easiest way for a small indie company or hobbyist developer to develop for the XBox 360 is using the XNA tools from Microsoft. Microsoft have spent a substantial amount and time on the XNA product set.

The XNA framework is a low barrier way to games development. XNA development makes use of a XBox specific version of the .NET compact framework. However, this framework does of course have its issues. The libraries aren’t as complete as the non-compact version, etc.

The way memory works in the .NET framework and the Garbage Collector, the generations of collection, heap allocations and similar are well discussed in a number of locations (not least of which is the MSDN library) and so I shall not discuss those specifics here.

This post is about one specific issue – stalls due to garbage collection events firing off at an inconvenient time. At this point I would strongly recommend reading two excellent articles: Steve from StevePro Studios suggested that I investigate garbage collection when I was developing a game called “flap”. A simple sprite game that would stall every few seconds. Go check out Steve’s original articles . There are other articles out there that explain a fair bit of the inner workings of managed code. Boxing and unboxing is especially interesting.

Once you have read Steve’s original article you will understand that there are generally three values in the remote performance monitor to look out for.

  • Managed String Objects Allocated
  • Managed Objects Allocated
  • Boxed Value Types

So you understand how to use the remote performance monitor, you can see that a static scene is allocating 2000 strings each time it updates – what do you do now?

At this point go back to first principles. When you don’t know where the problem lies profile it. Sometimes, and I will admit this, you can guess where the problem is “oh yeah its because I have spriteBatch.DrawString(font,string.Format(“You have killed {0} baddies”,score, … ) in my main draw code”. But I’m becoming an old hand at this – I get surprised way more than I predict. My recommendation is nothing more than dust down the old CLRProfiler.

The current CLRProfiler is available here: http://www.microsoft.com/en-us/download/details.aspx?id=16273

The technique is very simple.

  1. [To find a scene to target for our investigation we do some precursor steps]
  2. Create a Xbox version of the game.
  3. Deploy to the XBox and use the remote performance manager to run the game.
  4. Find a scene that is static enough (e.g. a simple spinning of the camera around the Y axis) that you shouldn’t expect any allocations.
  5. Find, using the performance manager that there are in fact allocations and GC cycles occuring.
  6. You have now a specific and very targeted problem to solve. This is the key, bite off small chunks and solve them one at a time.
  7. Create a debug windows version of your game.
  8. Start the CLRProfiler.
  9. Set the working directory correctly.
  10. Set the “Profile Allocations” to be true.
  11. Set the “Profiling Active” to false.
  13. At this point you are ready to go.
  14. Launch the application.
  15. Now, navigate to the same point as “4” above.
  16. Click on the “Profiling active” checkbox.
  17. Collect some data for a few tens of seconds.
  18. Uncheck the “Profiling Active” checkbox.
  19. At this point use the call graph to see what objects are being allocated and where.

Profiling XNA Level loading times using Slimtune

Work has started on a small internal project that may turn into a game once some of the edges are smoothed off. The game features some maps that are produced on the CPU. This process on the PC takes a few seconds but on an XBOX it takes a few minutes!

Why is this? Time to start profiling.

One lesson I have definitely learnt over the years is profile first and then optimise your algorithms. Do it that way around. Profiling can definitely throw up some counter intuitive results.

My actual frame rate is fine (60 Hz locked to refresh) on both PC and XBOX.

I’m using slimtune which has some pretty good features – lets see how it does. http://code.google.com/p/slimtune/

I’m starting the profiling straight away and exiting out immediately upon loading.

Once I have profiled lets look at what slimtune shows us.

I have 7 threads going. That’s OK, I use background loading of all the levels and the XNA framework generates a few of its own. I can see the GamerServices object is eating quite a lot of CPU. That’s not to surprising and not too much I can do about it.

If I drill into my own threads what we see is a substantial amount of time spent in creating vertex buffers. Ah!

The game world is split into a number of regions. Each region has an associated volume and bounding box. If the bounding box intersects the view frustrum then it is rendered in its entirety. Each region is a voxel space and each block within that space can be turned into a renderable cube. However the engine we’re creating also allows for blocks that are actually models. Each of these has a “cube renderer” that can also build vertex buffers.

Does each of these need its own vertex buffer or could we do better?

These cube renderers need to start sharing one big vertex buffer (independent mobiles / NPCs use different techniques)

Lets put that optimisation in place and see what happens. Load time is down to seconds!

Profilers are powerful tools – the high end commercial profiles can give you more details about what is going on but Slimtune is a pretty good starting point.