Adding in Timer

[jwoertink]

This adds in the SDL_Timer stuff. Used for checking elapsed time in milliseconds, and creating delayed callbacks. I added 2 samples for doing a simple timer, and a more advanced timer from the Lazy Foo tutorial 22 & 23.

[wooster0]

Why not just on this line extend self instead of writing self. at every single method?

[ysbaddaden]

I prefer explicit self. definitions over extend self, which only has value if the module is meant to be used as an includable module and a namespace for global methods at the same time —it may be valid here.

[jwoertink]

Ditto ^ 😂

[ysbaddaden]

Since we have monotonic clocks and evented loops, what do SDL timers provide specifically?

Furthermore, do callbacks run from a Crystal context? I didn't check the documentation.

[jwoertink]

I'm not sure since I don't know what a monotonic clock is, but if SDL provides it, then the API should as well. I don't think the callbacks are in a crystal context since they're defined in C. But I didn't need to use any callbacks in the samples.

[ysbaddaden]

Well, SDL provides a network library, which is nice for C (platform abstraction) but they'll mess up with the Crystal event loop. We shouldn't integrate every SDL library, especially when Crystal already has an alternative.

The following will probably behave better (crystal context, integrated into the event loop), for example:

def interval(seconds : Time::Span)
  spawn do
    sleep(seconds)
    yield
  end
end

interval(5.milliseconds) do
  # ...
end

Instead of SDL ticks, there is ticks = Time.monotonic.total_milliseconds and span = Time.measure { ... } which won't be affected by time fluctuations (e.g. changing the computer's date) for computing elapsed time.

[ysbaddaden]

SDL_Delay() duplicates sleep() and AFAIK block the current thread, thus block the crystal event loop.

[ysbaddaden]

I'm afraid callback will be run from an unknown context, possibly another thread (unknown to crystal, thus unknown to the garbage collector, and incapable to access the event loop).

It also relies on a captured block passed to a C function, which will make it impossible to rely on closure variables, and there may be GC issues (e.g. callback trying to access collected variables) making it complex to handle, over a simple crystal function, such as spawn { sleep(seconds), yield } for example.

[ysbaddaden]

This sample timer is very nice, but can be achieved using Time.monotonic and doesn't need SDL_GetTicks. For example:

ticks = Time.monotonic.total_milliseconds

[jwoertink]

Ah, I see! Ok. That makes a lot of sense. If that's the case, then maybe we can just have the sample timer run the same way, but with a crystal context, and then just ditch the whole SDL Timer addition? If you're cool with that, I will make that change. Keeping the samples with the same result, but using straight Crystal, and remove the timer.