PureBoard

>> Ich wollte dich lediglich darauf hinweisen, dass das Ziel-OS eh nur Windows sein wird.
> Das mag ja sein, ging aber nicht aus dem Post hervor.
Es war kein Bestandteil der Frage, nach einer Lösung zu suchen, die die Portierung auf andere Systeme erlaubt.
Mit anderen Worten: Ob die Portierung möglich ist, ist egal.

Nun, meine Lösung bietet keine Portierung, aber danach war ja auch nicht gefragt.

Ob meine Lösung nun die beste ist, darüber lässt sich sicherlich streiten. Ich will jetzt auch nicht angeberisch erscheinen, aber ich halte meine Lösung für die bisheer beste, die hier abgegeben wurde (außer remi meier's Tutorial, auf das ich verweisen habe und #NULL den Link gegeben hat).

Um auch noch mal auf edel zurück zu kommen, sicher hast du auch Recht. Allerdings ist die Ungenauigkeit von ElapsedMilliSeconds() nicht immer unerheblich: So dauert ein simples Delay(1), wenn man es mit ElapesedMilliSeconds() misst, nicht 1 ms, sondern ca. 2-4 ms.

Gut, ich wil jetzt auch nicht kleinlich sein. Welche Lösung letzendlich genommen wird, ist mir auch egal. Ich muss mich auch nicht rechtfertigen (vTuT), schließlich habe ich mir ja auch nichts zu schulden kommen lassen.
Dass ich es doch tue und auf eure Antworten eingehe, beweist aber, dass mir die Stimmung zwischen mir und dir (vTuT) nicht egal ist.

Ein simples Delay(1) wird nahezu niemals 1ms lang sein.
Delay(1) bedeutet eigentlich, dass es mindestens eine Millisekunde anhält.
Werte von 2-4ms wären völlig legitim.

Aber egal...

[...]Ich will jetzt auch nicht angeberisch erscheinen, aber ich halte meine Lösung für die bisheer beste, [...]

Da hier von Spielen die rede ist ... ist eigentlich der vorhandene PB
Befehl nicht nur ausreichend, sondern auch der empfelenswerteste ...

Warum? ... Weil bei keinem Spiel die berechnung der Zeit pro Frame
nicht auf die Millisekunde genau sein brauch und dagegen jede
vorhandene Ressorce nicht achtlos verschwendet werden sollte ...

Ich hoffe nur du verwendest in deinen nicht solch aufwendige
Zeitberechnungen ... um so weniger Ressorce ein Spiel
braucht, um so niedriger sind die Anforderungen
Unglaublich aber wahr

MFG PMV

Und wieder was dazu gelernt @ Hexor und @ PMV.

Was soll's. Wenigstens muss ich mir keine Vorwürfe (mehr) machen, weil ich "angeblich" Leute akribisch darauf hinweise, sie sollen (Zitat, vTuT) "gefälligst" (habe ich nie gesagt) die Postings genau durchlesen.

Ich muss zugeben, dass ich mir über den Performanceeinbruch von QueryPerformanceCounter_() nicht im Klaren bin, da ich das bisheer nur ein Mal in der Schule im Unterricht in Delphi verwendet habe und das auch nur ein einer kleinen GUI-Applikation.

Ich finde, wir alle haben hier einige gute Lösungen zusammengetragen

Kann man irgentnen code machen damit der das an jedem Rechner gleich interpretiert?

SetRefreshRate() nimmt zwar einfuß auf die geschwindigkeit, aber man hat dabei leider nur sehr wenig spielraum, und gerade um es auf anderen rechnern zu benutzten müßte man erst die unterstützten modi ermitteln und einen in etwa passenden auswählen, aber man wird dann oft nicht genau den gewünschten finden (außer standartwerte wie 60).

@vTuT:
Für dich mag Plattformunabhängigkeit ein wichtiges Merkmal sein, ich behaupte aber mal: Für die Masse nicht. Ich denke, es macht auch mehr Sinn, dass der Betroffene selbst anmerkt, dass er plattformunabhängig Programmieren will und nicht, dass du bei jedem API-Befehl ein Sauerstoffzelt brauchst, weil dir das Blut in den Kopf geschossen ist.


@edel:
Ich bin da anderer Meinung mit dem QueryPerformanceCounter.

1.) Der Befehl wird 1x(!!) pro Frame aufgerufen.
2.) Der Befehl braucht kaum spürbare Leistung.
3.) Der Befehl liefert mir Ergebnisse, mit denen ich rechnen kann.
4.) Eine Auflösung von 1ms (+-1ms) ist zu gering, wodurch unsaubere Bewegungen und Berechnungen entstehen können.
5.) Ich geb wenig auf Plattformunabhängigkeit unter PB.

Danke für die Antworten! Sie waren sehr hilfreich!