Well, you can always pass a different number to the constructor of the Gosu::Window class. It uses 16.66666.... ms by default (60Hz, fps).
If you pass to it 0, or 1 (never done that, gonna try it), I think it will go as fast as it can, and then you can implement the timing handling yourself in the update loop for time skipping, etc., as pointed out in the article.
By jlnr (dev)
Date 2010-03-31 03:52
Unless enabling it fails, it will never go faster than the screen's vsync even with a lower update_interval (= max 60 FPS almost everywhere). Which begs the question what you actually want: A game that updates even more often between rendering, so gameplay is somehow more precise? No problem, put a loop into Window#update and limit the loop with custom timing. Or a game that degrades more gracefully in the (already sub-optimal case) that the computer can't handle running it at 60 FPS? You can use Window#needs_redraw? to let Gosu skip rendering frames. And you can remember the time of the last Window#update too and do larger steps inside Window#update to degrade in the worst case, that even with skipping frames, the computer cannot compute 60 FPS.
I really think the two game loop types are pretty similar in practice.
