Re: Smarter NSTimer?
Re: Smarter NSTimer?
- Subject: Re: Smarter NSTimer?
- From: Quincey Morris <email@hidden>
- Date: Tue, 01 Jul 2014 12:12:30 -0700
On Jul 1, 2014, at 11:21 , William Squires <email@hidden> wrote:
> Use-case:
> I have a (fictitious) FPS game in which the players or bots can "damage" the scenery by leaving blast marks. A timer should remove these "decorations" after a given delay, but I want the timers to pause if any players/bots are within line-of-sight of the decorations.
It seems to me it’s a mistake to use “per event” timers at all in this scenario — it might not scale well.
The way I’d approach it (after thinking about it for about 30 seconds, so this may not be intelligent at all) is to create a set of “future event” objects, each of which has its own “remainingTimeDuration” property, along with information about what it is you want to do at the end of the duration.
Then, use a single timer, which is set to fire at the end of the remaining time of the soonest event. If a new event is created, or if the game is paused, or if the timer expires, invalidate the timer, subtract the actual elapsed time since the timer was started from each pending event, and start a new timer for the soonest of the newly updated events (if not paused, or start this timer at the end of the pause).
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden