XNA Game Lag Definition

I am currently creating a tower defense game using C # and XNA. Games run normally and smoothly for a while, but after playing for enough time (after enough enemies / towers / bullets appear) the game seems to slow down exponentially. Even when all instances are cleared, the lag still persists.

At first I thought that this could be related to garbage collection (and maybe it is), but to check it, I wrote destructors for printing when the object was assembled and everything looks fine (all objects are collected). So I'm curious if anyone has any XNA latency experience and possible reasons for this?

EDIT: This is for PC

+6
source share
4 answers

There are two things that I used to test performance.

1) The App Hub has a productivity utility that you can use to help determine what you have improved.

2) This is a bit dated, but for the Xbox 360 this document helped me a lot .

Update: I also forgot about this Gamefest 2010 presentation . It also affects a few things.

+1
source

If you are concerned that garbage collection affects performance, one of the best tools you can learn is the CLR Profiler . This utility allows you to profile the heap allocations performed by your program so that you can determine which methods generate the garbage. Remember that a lot of unobvious things can be singled out in a heap: combining strings, indexing dictionaries with enumerating keys, closing, delegation, etc. Even small garbage generated once per frame at 60 frames per second can stack up quickly under the right circumstances.

However, what you described does not seem like a garbage collection problem for me. GC is usually fast enough, even during a complete collection, to release only a few frames - in other words, you will notice a slight, annoying jerk every so often, but not a constant slowdown.

(Caution: this only applies to a PC that has a very complex GC compared to other XNA platforms.)

You should try connecting the profiler to your code to determine which methods take the longest; if your problem is not related to the GC, this may be informative. I used to use EQATEC , although I had problems with some of their later versions. You can try this, or you can look at Google for an alternative.

+1
source

Does the game cycle time increase? Add a stopwatch to the beginning and to the end of the update cycle and the drawing cycle. If it increases, try to exclude (move the stopwatch .Start () and / or the stopwatch .Stop ()) until you find what causes the slowdown. If it does not increase, it is caused by something else.

Try adding this line to your code:

SpriteBatch.DrawInt64(Font, GC.GetTotalMemory(false) / 1000 /* in kilobytes */, POSITION, Color.White, 0f); 

(DrawInt64 / 32 is a really useful extension for spritebatch that allows you to draw numbers without generating garbage, available here: http://pastebin.com/pVw66mGy . Just use DrawString and .ToString ()).

Each time the number of displayed numbers decreases, garbage collection is performed.

0
source

You didn’t forget to unhook the events, right? in the example below, I add 4 sprites to the list, each sprite captures an event from the game. Then I delete the sprite and raise the event.

In this situation, all 4 sprites are still active and receive their event, because the game still has a link to them.

just a thought, if you use events for your game objects, you can leave them all right.

 class Game { public event EventHandler SomeEvent; List<Sprite> sprites; public Game() { sprites = new List<Sprite>(); sprites.Add(new Sprite(this)); sprites.Add(new Sprite(this)); sprites.Add(new Sprite(this)); sprites.Add(new Sprite(this)); sprites.RemoveAt(0); EventHandler temp = SomeEvent; if (temp != null) { temp(this, EventArgs.Empty); } } static void Main(string[] args) { Game newProgram = new Game(); } class Sprite { public Sprite(Game gameReference) { gameReference.SomeEvent += new EventHandler(gameReference_SomeEvent); } void gameReference_SomeEvent(object sender, EventArgs e) { Debug.WriteLine("Event"); } } 
0
source

Source: https://habr.com/ru/post/896800/


All Articles