Um den Rechner nicht auszulasten, bedarf es immer noch keines Timer-Systems, man kann auch z.B. Sleepen, wenn das Fenster nicht mehr aktiv ist. Du hast natürlich recht, wenn man davon ausgehen kann, dass das Spiel bei weitem nicht den Rechner auslastet, kann man dafür Maßnahmen treffen, aber selbst dann ist ein Wait/Skip-System in meinen Augen immer noch eleganter als ein Timer. Das hat auch nichts mit der Genauigkeit des Timers zu tun, was ich meinte, ist, dass man z.B. nicht unbedingt garantieren kann, dass man in einem Handler den Frame fertig bekommt usw., und dann muss man nämlich doch wieder eine Wait/Skip-Logik implementieren, die sich ohne Timer in meinen Augen leichter implementiert.
Andererseits gelten meine Ausführungen oben, wie du schon sagtest, generell eher für "große" Spiele, also Spiele, die keine Minispiele sind, sondern wenigstens im Vollbildmodus laufen. Aber irgendwo muss man ja anfangen
Noch eine kleine Ergänzung mit einem halbwegs aktuellen Beispiel, nämlich xna, dass uns beiden recht gibt:
Dort hat man keine direkte Kontrolle über die Gameloop, sondern es werden lediglich die Update- und DrawFrame-Methoden vom System aufgerufen. Dabei kann man aber einerseits FixedTimeStep benutzen, d.h. einen festen Abstand zwischen den Frames, der Rückstände dadurch aufholt, dass er DrawFrame auslässt (Skipping). Wenn Update auch zu langsam ist, funktioniert die Logik nicht mehr, weil der Sinn derselben gerade der ist, dass man sich auf den festen Abstand als Zeiteinheit verlassen kann. Andererseits kann man VariableTimeStep benutzen, was nichts anderes bedeutet, als dass die Gameloop so schnell läuft, wie sie eben kann, und dann muss man sowieso time based movement (übrigens eventuell ein Suchstichwort für dich, Matze, um die von DMW erwähnte Rechnerabhängigkeit zu umgehen) benutzen.