mehrteilige Antwort:
1. egal wie "genau" Windows die 10ms einhält, wenn dein Code länger wie 10ms braucht, wird das nix... da dann nur schnellerer PC, weniger machen, besser programmieren
2. als Timer/RunnerThread wäre minimal sinnvoll "while(not Terminated) do begin Sleep(10); SetEvent(xxx); end;"
3. als WorkerThread(s) wäre minimal sinnvoll "while(not Terminated) do begin WaitForEvent(xxx,TimeOut); if not "TimeOut" then CallWorkProc; end;"

Timer/RunnerThread der ja "nur" SetEvent macht kann "HighestPriority" laufen. WorkerThread kann "HigherPriority" laufen. Wenn ein ThreadPool an Workerthreads und eine MehrkernCPU, dann dürfte eine Ausführung sogar mal notfalls etwas länger wie 10ms dauern, weil ja ein anderer Kern den nächsten TimerEvent übernimmt und noch teils "halbparallel" ausführt.

Das sind aber alles keine Aufgaben, welche eine Usermode Delphi Anwendung so hart zeitkritisch bearbeiten sollte, dann lieber ein eigener Treiber per DDK im Kernelmode und es wird realistisch beherrschbar.
Ich definiere das Timing von Threads lieber so: es dauert alle "mindestens" solange wie da angegeben(also hier immer mindestens 10ms), es kann aber auch "länger" dauern.

Per HighPrecisionTimerMode kommt man so wie oben kurz beschrieben mit aktueller Hardware und Win7..10 durchaus auf +/-5ms Genauigkeit... also man könnte 10..15ms zu 98% erreichen. Aller neueste Systeme gehen auch 5msec +/-2 wenn man ohne IO Treiber Nutzung nur im Ram arbeitet... aber da ist Windows im UserMode dann wirklich am Ende dessen, was mit sinnvollem Aufwand an zu 98% "quasi garantierten" Zeiten möglich ist.

Zitat von mensch72:

dann lieber ein eigener Treiber per DDK im Kernelmode und es wird realistisch beherrschbar.

Echt jetzt - für ein Spiel? Ich würde eher sagen, daß die Architektur des Spiels nochmal überdacht werden sollte, damit sie nicht so zeitkritisch ist.