Hi,

Mostly when I want to know values of some variables, I can't put breakpoints since it would break on alot of not important occasions before hitting it for the right time (and I vaguely remember putting IF's for it, but I donno how anymore). So I used Trace.WriteLine (or something like that) but that required me to ALT+TAB my way alot and wasn't that useful. So I was after a cheap (performance wise) way to show some values on the screen to ease the debugging. I'm sure there is something there in XNA for such matter.

Thanks you guys in advance.

You can just use the build in .NET namespace System.Diagnostics


When you are running in Visual Studio, all that debug information will show up in the output window.
Just make sure that your game window is smaller than your screen resolution, so you don't have to switch between VS and your game.

Otherwise you can also write something to the screen with the spritebatch:

spriteBatch.DrawString( Font1, output, FontPos, Color.LightGreen, 0, FontOrigin, 1.0f, SpriteEffects.None, 0.5f ); 
 

Hi,

Can you please help with Font? I'm facing difficulties using a font, I use SpriteFont and Content.Load<SpriteFont> to load a font but it doesn't find my font to load.

Try this tutorial.

Jim Perry:

Try this tutorial.

Thanks alot man, darn I was missing to address the folder to the naming, I just thought as of C++, those folders are for management and doesn't need to be addressed via code.

Back to teh topic, I'm currently writing stuff that I want from the Draw section of my class code but that method is called once per frame and is called after everything else. What I want is being able to call to draw my stuff from everywhere I want, like how you can use Trace command. I want to see my values on the screen from various places, not just Draw method.

What do you suggest on that?

How about using a Queue, recording where and when the item in the Queue occurred, and drawing the items in the Draw method.

Jim Perry:

How about using a Queue, recording where and when the item in the Queue occurred, and drawing the items in the Draw method.

I think I would lose data. If I understood your point correctly, when I enque my i.e. UpLeft position to draw on the screen, there is no guarantee that until the Draw calls, the data remains the same.

99% of the time it'll still be the same unless you're doing something really weird. Maybe I just don't understand what problem you're trying to solve. If you log the data, you'll see it change values.

If you use Jim's method, it doesn't matter how many times your collision detection is called because each time it is called it queues it's current values, so the previous values are still there in the queue, and don't get cleared until your Draw routine dequeues everything when drawing, which is once a frame.

A Queue, a Stack, a List (which is cleared each frame) all would work perfectly well. I personally use a List and clear it at the beginning of my Update.


#tip: Wrap all your code that adds debug info to the queue in a #DISPLAYDEBUG definition because they can generate a lot of garbage.

test84:

Jim Perry:

How about using a Queue, recording where and when the item in the Queue occurred, and drawing the items in the Draw method.

I think I would lose data. If I understood your point correctly, when I enque my i.e. UpLeft position to draw on the screen, there is no guarantee that until the Draw calls, the data remains the same.

Actually, in such a style of logging via a queue, you should not put a reference to the data on the queue (which is what I think you think you should do.) You should convert the data you want logged to a string (this obviously captures the value exactly when you want it) and put the string on the queue. You can also add other information (e.g current time, a full call-stack, whatever) to the queued string.

This kind of "deferred" logging has many advantages (performance, simplicity) but it may have a few shortcomings (depending on whether you need the particular features or not.) For example, if you break the execution of your program in the middle of a frame (before the draw call) you obviously won't see the logged data. One solution is to use other methods of logging too, for example, call the Trace.WriteLine as soon as you push something on the queue.