Have you been wanting a timeout for SDL_WaitEvent?

SDL Development
1

Here’s a cut for adding an SDL_WaitEventTimeout to SDL 1.3 r4406,
without any of the other deeper changes I proposed:

http://bugzilla.libsdl.org/show_bug.cgi?id=684

Reviews are welcome.–
http://pphaneuf.livejournal.com/

2

I would say that most SDL_WaitEvent() event use cases fall into one of
two categories:

  1. Wait indefinitely (no timeout)
  2. Perform all application processing on a specific interval

I thought I wanted this API, but when I actually think about it, I
can’t actually think up a good use case for this timeout function. In
every situation I can think of, I’ll have to call SDL_GetTicks() and
compare it to the next time interval I want to regain control upon, at
which point SDL_WaitEventTimeout() will compare it again to
SDL_GetTicks() just to undo the calculation I had to do.

Is there a good reason not to include an SDL_WaitEventInterval() API
in addition to an SDL_WaitEventTimeout() API?

Also, just so it’s clear to any onlookers: these are rudimentary stub
implementations that don’t provide many of the real advantages Pierre
wants to see get into the SDL event dispatching system. We should have
implementations that don’t wait in SDL_Delay() in the near future, but
the APIs will already be in place.On Mon, Jan 19, 2009 at 12:17 AM, Pierre Phaneuf wrote:

Reviews are welcome.

–
http://codebad.com/

3

I thought I wanted this API, but when I actually think about it, I
can’t actually think up a good use case for this timeout function. In
every situation I can think of, I’ll have to call SDL_GetTicks() and
compare it to the next time interval I want to regain control upon, at
which point SDL_WaitEventTimeout() will compare it again to
SDL_GetTicks() just to undo the calculation I had to do.

Is there a good reason not to include an SDL_WaitEventInterval() API
in addition to an SDL_WaitEventTimeout() API?

I was hoping to add some lightweight timers (they would just check if
one of them is expired and return it in the SDL_Event, without using a
thread), but starting simple. This enables one to implement it outside
of SDL, where before it wasn’t possible (without negating the coming
advantage of what else I’ve got coming up).

I do like having SDL_PollEvent and SDL_WaitEvent being unified with a
single implementation function, though.

Also, just so it’s clear to any onlookers: these are rudimentary stub
implementations that don’t provide many of the real advantages Pierre
wants to see get into the SDL event dispatching system. We should have
implementations that don’t wait in SDL_Delay() in the near future, but
the APIs will already be in place.

That is correct. It still has the latency “chunkiness” of
SDL_WaitEvent, but this API should be compatible with the upcoming
changes. I did more or less that change in my other change, so I
figured it’s an improvement by itself, and makes the following patches
easier to read.On Mon, Jan 19, 2009 at 10:05 AM, Donny Viszneki <donny.viszneki at gmail.com> wrote:

–
http://pphaneuf.livejournal.com/