Jeeeeeeju, Ty się zawsze potrafisz do czegoś przyczepić jeśli ktoś napisze więcej od Ciebie.
Ja bym zrobił odwrotnie.
Odwrotnie względem czego? Bo raczej nie mnie, robisz dokładnie to co napisałem.
...
i powiedzieć że o tym wszystkim wcześniej wspomniałem.
Sugeruję aby nie dostosowywać czasu do instrukcji tylko dostosować instrukcje do czasu. Wykonywać instrukcje całymi pakietami w ilości dostosowanej do upływającego czasu. Same uśpienia mogą być nieregularne. Chodzi przede wszystkim o to, że czas w komputerze nie jest ciągły, a podzielony na pojedyncze takty. Chodzi o pokazanie, że nie musimy za wszelką cenę starać się, by poszczególne wirtualne takty rozkładały się w czasie równomiernie. Jest ich tak dużo, że wystarczy by reguła była zachowana w uśrednieniu, lokalnie mogą się pojawiać wahania, ważne by sumarycznie się zgadzało.
Będziesz potrzebował dwie funkcje zależne od systemu operacyjnego
Bo nie ma bibliotek które zatrzymują wykonywanie albo mierzą czas i są OS independent.
Ewidentne czepialstwo o nie-wiadomo-co. Te biblioteki służą właśnie po to, by dostarczyć Ci owych "funkcji zależnych od systemu operacyjnego" w zunifikowany sposób. Nie ważne czy biblioteka, czy bezpośrednie wołanie API systemu. Chodziło mi o to, że nie obejdzie się nie wychodząc poza bibliotekę standardową. Ale oczywiście musisz się czepiać.
Timer.Interval = 1
Pointless whatsoever. Zamiast męczyć windę krótkimi odstępami, lepiej ustawić ~50ms, nie będziesz dławić procesu swoim obliczaniem delty żeby wykonać parę taktów wirtualnego procesora.
Application.ProcessMessages
Wiesz ile może trwać wykonanie processMessages dla większych projektów? Dlatego znowuż dławisz tym proces.
Czas liczenia delty będzie rzędu czasu wykonania JEDNEJ wirtualnej instrukcji procesora. Poza tym w ciągu 6ms ma zostać wykonanych ok. 6ms*3MHz=2000 instrukcji a nie kilka. Natomiast co do Application.ProcessMessages - jeśli wołamy często (czyli zazwyczaj żadne komunikaty nie będą czekać) to wykonanie będzie szybkie (sprowadza się do wywołania PeekMessage). W dużych projektach Application.ProcessMessages trwa długo dla tego, że przetwarzanie pojedynczego komunikatu trwa długo. Komunikatów tak czy siak musimy obsłużyć zawsze tyle samo więc tak naprawdę nie ma większego znaczenia jak często wołamy Application.ProcessMessages.
Tak poza tym w przykładzie który podałem wszystko samo-reguluje się gdy zaczyna brakować mocy obliczeniowej komputera. Gdy nasza maszyna wirtualna przestaje nadążać wtedy dzieją się dwie rzeczy - sleep'y zaczynają być pomijane oraz Application.ProcessMessages jest wykonywane co raz rzadziej (bo co raz więcej wykonujemy instrukcji w jednym pakiecie).
A tak na prawdę zamiast gdybać trzeba zrobić testy i dostroić algorytm. Podałem tylko zalążek, główną ideę.
I nie - nie napisałem tego samego co Ty. Twoja odpowiedź nie była wyczerpująca.