Event Handlers!? ARGLEARGLEARGLE

Started by
15 comments, last by ghetalion 18 years, 3 months ago
Quote:Original post by Argus2
Why are you defining events in real-time? Because you can't guarantee it, as you've discovered.

So would there be a problem if you only constrained a minimum time for the loop to run? ie. a tick would happen after each game loop, and if the loop takes under 2 seconds, then you pad it out to 2 seconds. EDIT: And if it takes more than 2 seconds, then the tick just turns over when the loop ends.

There should be no time-critical events in your game engine, especially in a MUD. If my computer isn't fast enough to run an RTS game, the game just slows down - its internal state doesn't go barmy. It should not be any different for your game.


hmmmmm lets see if i got this correct

- game loop goes and is 1.5 seconds long
- at end of loop, tick doesn't go, needs an extra .5 seconds? or just round up to let the tick happen?
- game loop goes and is 3 seconds long
- at end of loop, only one tick goes?

I dont uderstand what you mean by 'pad it out' or 'turns over'
Advertisement
I mean that it shouldn't really matter how long the tick takes. Why synchronise ticks with real time?

So you could just tick over only after a game loop, no matter how long it takes. But you might not want it ticking over too fast, so you might have a minimum time for a tick, and if the loop finishes in less than that, then you 'sleep' the thread until the minimum time is up.
Quote:Original post by Argus2
I mean that it shouldn't really matter how long the tick takes. Why synchronise ticks with real time?

So you could just tick over only after a game loop, no matter how long it takes. But you might not want it ticking over too fast, so you might have a minimum time for a tick, and if the loop finishes in less than that, then you 'sleep' the thread until the minimum time is up.


Running tick based on the game loop causes a problem when running this application of different boxes because on a very decked out box... the game will run FASTER. And be faster I don't mean better, I mean literally sped-up.

Sleep adds an unnessecary delay in which other computations could have taken place.
Quote:Sleep adds an unnessecary delay in which other computations could have taken place.

1. The delay is necessary, because by your own admission, you don't want the game to run too fast.
2. Sleep simply means that the current thread becomes unrunnable for a certain period of time - you are welcome to have computations running in other threads in the interim.

If you're determined not to believe in a solution, then don't ask for help.
Quote:Original post by Argus2
Quote:Sleep adds an unnessecary delay in which other computations could have taken place.

1. The delay is necessary, because by your own admission, you don't want the game to run too fast.
2. Sleep simply means that the current thread becomes unrunnable for a certain period of time - you are welcome to have computations running in other threads in the interim.

If you're determined not to believe in a solution, then don't ask for help.


I'm sorry... threads? My understanding of programming is that there is no such thing as paralell processing.

The delay may or may not be nessecary.. and sometimes the opposite will be needed... due to limitations of... say.. quantum mechanics, there is no such thing as a SpeedUp() function. The solution needs to be dynamic and adaptable to the situation.
Quote:Original post by ghetalion
I'm sorry... threads? My understanding of programming is that there is no such thing as paralell processing.

The delay may or may not be nessecary.. and sometimes the opposite will be needed... due to limitations of... say.. quantum mechanics, there is no such thing as a SpeedUp() function. The solution needs to be dynamic and adaptable to the situation.


Well, your understanding of programming is flawed by not having an idea of threading, but I won't go there since PHP doesn't really have a facility for threading... yet.

Meanwhile, the sleep is nessicary if you want to sync the Event Hander's loop to realtime. You don't have anything more to process, so let the loop idle for however much time adds up to the three seconds that the Event Handler's supposed to activate on anyways.

Your "Blueshifting/Redshifting" problem is caused by the event loop's intervals terminating too early or too late; if you want it to happen every 3 seconds, you must have a way of telling the computer to stop after 3 seconds, and you must have a way of telling the computer how to cope with extra time. This is where sleep and a good timing function come in. Sleep() when you have extra time, peek on the timer before doing anything you know takes a bit of time, if there's even a question that the event will put you over-time on your processing budget, simply delay processing the event until the next clock interval and sleep away the rest of the time. (keep in mind that peeking on the timer will also cost you time, so you shouldn't simply do it before every single function call, just the ones you know are slow such as a database query or an image blitting function).

--- top of event handler's inner loop ---
if (($preEventTime + 3) > getTime()) {
//go ahead and keep the loop running, we still have time.

if ((getTime() + .5) >= $preEventTime)
{
//skip processing this event, it's simply going to take too long
// EDIT: If you're using a priority queue, instead of continuing the loop,
// break here instead, and Sleep() the rest of the time until the 3 seconds
// are up. How do you know if this is ineffecient? Well, if you're spending
// more than half of your time asleep, you know something's wrong.
// Perhaps your event simply can't be processed in a timely manner (3 secs)?
continue; //move on to the next event in the loop
} else {
doSlowQuery();
}

} else {
//log the fact that you've spent too much time
$log .= "too little time\n";
//break out of the inner loop
break (2);
}
--- bottom of event handler's inner loop ---
Believe it or not, even big fancy games coded by game studios will use this to get around timing issues. If you want something to work in real time, you have to cope with the computer's abilities. Someone with a really fast computer's going to be able to process events much, much quicker than my 486 in the closet. Sleep() may be "wasting", but it allows for events to occur at the same time on both the ultra new machine, and the 486.

So really, just add the sleep and peek on the timer when you need to. It's the fix to the problem you're having, even if you don't understand why its neccesary now. Continuing to argue that you don't want to do it is only going to drive people on this site crazy (like the guy who couldn't figure out asin() is always going to be faster and more bugfree than his own implementation). Believe it or not, Sleep() is effecient programming if you want to do something in a timely manner, and its the reason modern processors have the nop ability. Think about it; if everything could run sychronous to realtime and not use sleep, who would? Why would the facility be left in the language?

[Edited by - ciroknight on January 2, 2006 6:34:20 AM]
Quote:Original post by ciroknight
Quote:Original post by ghetalion
I'm sorry... threads? My understanding of programming is that there is no such thing as paralell processing.

The delay may or may not be nessecary.. and sometimes the opposite will be needed... due to limitations of... say.. quantum mechanics, there is no such thing as a SpeedUp() function. The solution needs to be dynamic and adaptable to the situation.


Well, your understanding of programming is flawed by not having an idea of threading, but I won't go there since PHP doesn't really have a facility for threading... yet.

Meanwhile, the sleep is nessicary if you want to sync the Event Hander's loop to realtime. You don't have anything more to process, so let the loop idle for however much time adds up to the three seconds that the Event Handler's supposed to activate on anyways.

Your "Blueshifting/Redshifting" problem is caused by the event loop's intervals terminating too early or too late; if you want it to happen every 3 seconds, you must have a way of telling the computer to stop after 3 seconds, and you must have a way of telling the computer how to cope with extra time. This is where sleep and a good timing function come in. Sleep() when you have extra time, peek on the timer before doing anything you know takes a bit of time, if there's even a question that the event will put you over-time on your processing budget, simply delay processing the event until the next clock interval and sleep away the rest of the time. (keep in mind that peeking on the timer will also cost you time, so you shouldn't simply do it before every single function call, just the ones you know are slow such as a database query or an image blitting function).

--- top of event handler's inner loop ---
if (($preEventTime + 3) > getTime()) {
//go ahead and keep the loop running, we still have time.

if ((getTime() + .5) >= $preEventTime)
{
//skip processing this event, it's simply going to take too long
// EDIT: If you're using a priority queue, instead of continuing the loop,
// break here instead, and Sleep() the rest of the time until the 3 seconds
// are up. How do you know if this is ineffecient? Well, if you're spending
// more than half of your time asleep, you know something's wrong.
// Perhaps your event simply can't be processed in a timely manner (3 secs)?
continue; //move on to the next event in the loop
} else {
doSlowQuery();
}

} else {
//log the fact that you've spent too much time
$log .= "too little time\n";
//break out of the inner loop
break (2);
}
--- bottom of event handler's inner loop ---
Believe it or not, even big fancy games coded by game studios will use this to get around timing issues. If you want something to work in real time, you have to cope with the computer's abilities. Someone with a really fast computer's going to be able to process events much, much quicker than my 486 in the closet. Sleep() may be "wasting", but it allows for events to occur at the same time on both the ultra new machine, and the 486.

So really, just add the sleep and peek on the timer when you need to. It's the fix to the problem you're having, even if you don't understand why its neccesary now. Continuing to argue that you don't want to do it is only going to drive people on this site crazy (like the guy who couldn't figure out asin() is always going to be faster and more bugfree than his own implementation). Believe it or not, Sleep() is effecient programming if you want to do something in a timely manner, and its the reason modern processors have the nop ability. Think about it; if everything could run sychronous to realtime and not use sleep, who would? Why would the facility be left in the language?


I understand your analysis. I'm not saying it doesn't make sense.

I'm just kinda weirded out by the entire concept of forcefully cutting into cycles to regulate timing.

But by dividing the sleep into fractions and checking them... this is a good idea.

Thanks for the detailed insight. :D

This topic is closed to new replies.

Advertisement