7 posts
Posted 19 October 2012 - 05:39 PM
I'm not entirely sure how your API works in the background, and if this function would be supportable. But the idea is this: Users of the API will no longer need to have multiple threads running if they want to empty the event queue every once in a while, because instead of calling os.getEvent(), and yielding in the event thread until an event is received, they can simply call os.hasEvent() to see, every once in a while, if the os has any events in queue. If not, then they can go about their business, else they process events. The hasEvent() function is an extremely important part of any game engine, because the game must process events and run game logic simultaneously. If users don't want to multithread, a hasEvent() function is essential. How fun would it be if a game ran only one frame every time you clicked your mouse or pressed a button, and froze at all other times, because it yields until you've sent it an event?
2447 posts
Posted 19 October 2012 - 05:52 PM
Nah. Not really possible - because if you're only looking for certain events (e.g. using sleep, read, or pullEvent yourself) you'll discard all the other events.
That doesn't mean all hope is lost though - we have a few built in program which keep running while still being able to be controlled. See worm, or alongtimeago. Hint - timers! It is what sleep uses to wait for a specified amount of time.
7 posts
Posted 19 October 2012 - 07:36 PM
So I force a timeout and return of the pullEvent() function by starting a timer just before (and then receiving the timer event).
2005 posts
Posted 19 October 2012 - 08:04 PM
You can also start a very short timer, use an os.pullEvent() loop to pull off all the events and store them in a table till it hits your timer event, and only access the events by looking for them in the table (which has handy timer events and is in chronological order). This introduces a tiny responsiveness delay, but you can minimize it below the noticeable threshold if your program is tight otherwise. You can either leave the table running or you can flush it and restart every time the pull event loop runs. The loop itself, for obvious reasons, is a repeat until loop, and will be nested in at the beginning of your larger program loop.
724 posts
Posted 20 October 2012 - 09:59 AM
You can queue fake event before pull events from queue. When you got your fake event, count queue as empty.
7 posts
Posted 20 October 2012 - 04:28 PM
Okay. Thanks much!