Brian Peek [MVP C#] - All Comments

XNA Timing Bug

Brian Peek — Mon, 24 Dec 2007 11:52:39 GMT

Update: This issue has been fixed in XNA Game Studio 2.0. Woo hoo! While working on my game for Maker

XNA Timing Bug

BrianPeek.com — Mon, 24 Dec 2007 11:52:36 GMT

Update: This issue has been fixed in XNA Game Studio 2.0. Woo hoo! While working on my game for Maker

Link Listing - July 16, 2007

Christopher Steen — Tue, 17 Jul 2007 11:16:07 GMT

Implementing duplex messaging with BizTalk Services [Via: gsusx ] Titan-IOC : A lightweight, flexible,...

re: C# MVP

Matthieu MEZIL — Tue, 03 Jul 2007 02:20:53 GMT

Congratulation

re: C# MVP

John Papa — Mon, 02 Jul 2007 13:08:48 GMT

Congrats! Well deserved!

re: C# MVP

Sam Gentile — Mon, 02 Jul 2007 13:02:56 GMT

Congrats!! Welcome!

re: XNA Timing Bug

Brian Peek — Wed, 27 Jun 2007 20:36:03 GMT

Dan,

Not sure I understand...when/why would you be getting multiple updates in a single frame?

re: XNA Timing Bug

Dan — Wed, 27 Jun 2007 13:01:01 GMT

Hi thanks for the quick reply. That has cleared a lot up for me. I had a poorly designed projectile class so have re done it to be more flexible and fit in better with my game. How do I get round a situation such as the update gets called again before the timer refreshes (do i just ignore this as it is unlikely that the human eye will be able to notice such a small hiccup?) Thanks for you help Dan

re: XNA Timing Bug

Brian Peek — Tue, 26 Jun 2007 20:44:23 GMT

Dan,

I assume you're using XNA since you're posting here. ;)

I'm not 100% sure I understand the question at hand, but I would be maintaining a list of projectiles and enumerating the list once per call to the XNA Update method. Here I'd take the elapsed ticks passed into the Update method to determine how far each projectile would have moved in that time frame.

So, you'd like have a Projectile class which contains its own update method, also taking in a TimeSpan of elapsed time since the last frame. So, something like this in your main game screen (pseudo-code):

void Update(GameTime time)

{

foreach(Projectile p in projectiles)

p.Update(time);

}

void Draw(GameTime time)

{

foreach(Projectile p in projectiles)

p.Draw(time);

}

Then in your Projectile class (pseudo-code again):

void Update(GameTime time)

{

this.X = VelocityX * time.ElapsedTime.TotalMilliseconds;

}

Hope that makes some amount of sense. If not, feel free to post back here, post to my forum at www.brianpeek.com or fire off an email to me at "my first name@my first and last name.com" . :)

re: XNA Timing Bug

Dan — Tue, 26 Jun 2007 15:10:38 GMT

Hi I have just read your article with great interest. I am writing an Xbox 360 game for my final year project at university. The game is going to be loosely themed on Worms. I have a projectile class that takes an accuracy (how many times it updates itself for the time spent in the air). At the moment the accuracy is set at 0.001 so it uses these intervals to work out (x,y) at a given time. The results are correct however i now need to make it perform at close to real time. Can you suggest a decent starting place to look for answers please. Any advice would be appreciated. Thanks Dan

re: XNA Timing Bug

Brian Peek — Wed, 30 May 2007 17:49:47 GMT

Thanks for the link. I've been bitten on the PC side by these inaccuracies in the past, but this time it wasn't the PC I found inaccurate in all of my testing, but the Xbox. Unfortunately since the CompactFramework is new to this platform and the fact that it is the CF, my options for timing are limited.

Also note that the issue I was having wasn't that I wouldn't get updates to the tick count fast enough, but the fact that the tick count was just plain wrong.

My sample app that proved the point showed that the Stopwatch (which uses QPC internally on the 360) actually redefined the length of a millisecond. :) The sample app would start a Stopwatch and grab the time value for DateTime.UtcNow.Ticks and compare the two over time. You can watch the difference between the two values increase at a constant rate such that after 1 minute, the value returned from DateTime.UtcNow.Ticks was indeed real time, and the value returned by the Stopwatch was 150ms in the past. After 2 minutes, it was 300ms off. After 3, 450ms.

Quite bizarre, but according to the Stopwatch on the 360's CF, a millisecond isn't quite a milisecond, but DateTime.UtcNow.Ticks was perfectly accurate for my needs.

re: XNA Timing Bug

cmyers — Wed, 30 May 2007 12:58:38 GMT

Brian, You should Google on StopWatch and QueryPerformanceCounter, because you're not alone on this. Many PC processors have this problem also, especially AMD ones and dual-core (AMD or Intel) ones. There are ways of compensating for this. As far as DateTime.Now and UtcNow, while the docs state that the RESOLUTION (accuracy) is 10 milliseconds, my observations have shown its PRECISION (repeatability/reliability) is around 200 milliseconds. For example, I've seen that repeated calls to dump DateTime.Now/UtcNow to the console in a tight loop will show that the value doesn't change but once every 150-200ms. I've tried this on Intel and AMD, single and dual core and the DateTime.Now/UtcNow are reliably imprecise and StopWatch/QueryPerformanceCounter can be all over the board (inaccurate, but precise, accurate but imprecise, etc). Here's a good article from a guy working on a video editing app (which has the same kinds of timing requirements you have): http://www.virtualdub.org/blog/pivot/entry.php?id=106

re: XNA and 3D Model Exporting

eric — Sun, 13 May 2007 07:29:59 GMT

Great to know, i was haveing a similar problem in 3 differnet modeling aps becuase of something like this! If onlyi could get blender 3d to export to .x properly...

re: Maker Faire 2007

Brendan Tompkins — Wed, 09 May 2007 23:57:23 GMT

Brian.. I'm a huge maker wannabe... very cool that you're going to be at the maker Faire!

re: Mix 07

Rod Paddock [MVP] — Wed, 25 Apr 2007 20:48:56 GMT

I'll be there. Cell # is 253 906 2342

I'm at bellagio.