Click here to Skip to main content
15,914,066 members
Please Sign up or sign in to vote.
3.00/5 (1 vote)
See more:
how do i time a game in c# windows application,the elapsed time has to be displayed on the interface of the game when the game being played.
Posted

Personally, I would use a BackgroundWorker that sends out a progress event once every second. Some folks will undoubtedly suggest the use of a Timer, but I despise Timers, and consider them to be the fallback of ex-VB programmers that desperately want to cling to old (bad) habits, learned in their programming infancy.

YMMV.
 
Share this answer
 
Comments
[no name] 31-Aug-11 13:53pm    
I dont understand why Timers have any connection to Very Bad (VB ;)) programming... If you use a BW for this then you are just busy spinning or something. Where as a Timer you can set the interval to what ever you need the UI to update at... Once the interval is up Blamo update the UI.
A BW would have to do other logic in it to maintain the timing. Why re-invent the wheel?
Sergey Alexandrovich Kryukov 31-Aug-11 15:40pm    
No, a thread never has to spin-wait! You probably have no idea how OS works. When a thread sleeps or waits for a sync. primitive object like a EventWaitHandle or a lock, OS switches it out and keep in a special state wasting 0% CPU until it is waken up by a primitive state change, timeout, Abort or Terminate.

I don't even know how to explain why times are so bad. It seems to be apparent. Ever tried to deal with the situation when a timer callback is not yet returned when a new tick event is fired?
--SA
[no name] 1-Sep-11 9:10am    
Actually I do know a lot more than most about OSes... Just because I said "busy spinning or SOMETHING" (about a thread) should not imply I have no idea how an OS works.

Again the timer I have referred to is not on the UI thread and is considered thread safe and runs on a thread from the thread pool. Please read this article on CP on differences of timers. Maybe you only have expreience using the older WinForms timers....


http://www.codeproject.com/Articles/167365/All-about-NET-Timers-A-Comparison/?display=Mobile
Bert Mitton 31-Aug-11 13:58pm    
The biggest issues IMO are the fact that the timing isn't always accurate, and that it's on the UI thread, both of these affect performance. You're right, in that it's alot easier though.

If you need help with the background worker, let me know. I'd be more then happy to help out.
[no name] 31-Aug-11 14:09pm    
I think the Forms.Timer is on the UI thread and not very accurate but I was under the understanding that the System.Timers.Timer is meant for Servers checking com status etc. and is not on the UI thread.
http://msdn.microsoft.com/en-us/library/system.timers.timer.aspx
Although JSOP says not to use Timers, at the risk of being down voted I suggest them... It is quite simple.

Create your timer and set up the update interval (how often the UI needs to be updated) and then start the timer. Also store the start time so you can keep calculating the elapsed time;

 Timer _timer;
const int UPDATE_TIME_MS = 1000;//Updates every second
DateTime _startTime;
TimeSpan _elapsedTime;
 ...

 private StartMonitoringTime()
{
    _timer = new System.Timers.Timer(UPDATE_TIME_MS);
    _timer.Elapsed += Timer_Elapsed;
    _startTime = DateTime.Now;
    _timer.Start();
}

...
private void Timer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
    _elapsedTime = DateTime.Now - _startTime;
    //Finally you expse the _elapsedTime to your UI (via binding or whatever)
}
 
Share this answer
 
Comments
#realJSOP 31-Aug-11 15:53pm    
Someon 1-voted you for no apparent reason, but I 5'd to compensate. I don't use timers because no matter what namespace you use, a timer message is the lowest priority message in Windows, and is NOT guaranteed to be fired (or handled soon enough that it doesn't fall out of the message queue) on a busy system. If there's no guarantee of consistent behavior, what's the point? A thread is guaranteed. I suggested a BackgroundWorker to avoid the added burden of setting up a custom tick event, instead, using the built-in Progress event.
[no name] 1-Sep-11 9:02am    
Thanks for the information (and the vote compensation).

I guess I never thought about how their priority is so low AND that it will remain on the queue (that could create some bad behavior).

But are you referring to the System.Windows.Forms timer or the System.Timers.Timer?

I am quite certain that the later is on a thread from the thread pool....
Good afternoon!

The easiest way would be to use a timespan (see link). Basically, you'll set a datetime object when you start playing, and at intervals calculate the timespan between the current time and the start time.

http://msdn.microsoft.com/en-us/library/system.timespan.aspx[^]

Regarding solution 1 above, I agree 100% on the background worker over the timer. Just remember that it's not on the UI thread, so there's a good bit more overhead.

You can use a timer, but remember they're not that terribly accurate, and the calculations would be on the UI thread. What you're trying to do here isn't that much, but if you're running alot off the UI thread, it's going to add up and affect performance.

To summarize, if you can, use a background worker (or even just a new system.threading.thread) unless you really need to.

Good luck, and let us know if there's anything else we can do to help.
 
Share this answer
 
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900