Ich schreibe ein Old School ASCII DOS-Prompt Spiel. Ehrlich gesagt versuche ich, ZZT zu emulieren, um mehr über diese Marke des Spielentwurfs zu lernen (selbst wenn es antiquated ist)
Mir geht es gut, mein Vollbild-Textmodus funktioniert und ich kann Welten schaffen und mich ohne Probleme bewegen, aber ich kann keine vernünftige Timing-Methode für meine Renderings finden.
Ich weiß, dass mein Rendering- und Pre-Rendering-Code schnell ist, denn wenn ich keine delay () s oder (clock () - renderBegin) / CLK_TCK von time.h hinzufüge, sind die Renderings unglaublich schnell.
>Ich möchte delay () nicht verwenden, weil es für meine Wissensplattform spezifisch ist und obendrein kann ich keinen Code ausführen, während es verzögert (Wie Benutzereingabe und -verarbeitung). Also habe ich beschlossen, so etwas zu tun:
%Vor%Was sollte in "Theorie" gut funktionieren. Das Problem ist, dass wenn ich diesen Code (Einstellung der RenderInterval auf 0.0333 oder 30fps) Ich bekomme nicht irgendwo nahe 30fps, ich bekomme mehr wie 18 bei max.
Ich dachte, ich würde vielleicht versuchen, den RenderInterval auf 0.0 zu stellen, um zu sehen, ob die Performance hochging ... aber nicht. Ich war (mit einem RenderInterval von 0.0) bei max ~ 18-20fps.
Obwohl ich vielleicht all diese clock () und "divide this by that" Methoden benutze, verlangsamte ich die CPU etwas beängstigend, aber als ich die render und ballLogic Calls aus den Klammern der if Anweisung nahm und Setze RenderInterval auf 0.0 Ich bekomme, wieder blitzschnell rendert.
Das macht keinen Sinn für mich, wenn ich das If-Check-in verlasse, sollte es nicht genauso langsam laufen? Ich meine, es muss immer noch alle Berechnungen machen
BTW Ich kompiliere mit Borland Turbo C ++ V1.01
Das beste Spielerlebnis wird normalerweise durch Synchronisierung mit dem vertikalen Rücklauf des Monitors erreicht. Zusätzlich zum Timing wird dadurch auch das Spiel auf dem Bildschirm flüssiger, zumindest wenn ein CRT-Monitor an den Computer angeschlossen ist.
Im 80x25-Textmodus erfolgt der vertikale Rücklauf (auf VGA) 70 Mal / Sekunde. Ich erinnere mich nicht, ob die Frequenz bei EGA / CGA die gleiche war, aber ich bin mir ziemlich sicher, dass es bei Hercules und MDA 50 Hz waren. Wenn Sie die Dauer von beispielsweise 20 Frames messen, sollten Sie eine ausreichend gute Schätzung für die Häufigkeit haben, mit der Sie zu tun haben.
Lassen Sie die Hauptschleife wie folgt aussehen:
%Vor%Ich habe herausgefunden, warum es nicht sofort gerendert wird, der Timer, den ich erstellt habe, ist in Ordnung, das Problem ist, dass der tatsächliche clock_t nur auf .054547XXX oder so genau ist und so konnte ich nur mit 18fps rendern. Die Art, wie ich das beheben würde, ist mit einer genaueren Uhr ... was eine ganz andere Geschichte ist
Was ist damit: Sie subtrahieren von x (= Uhr ()) y (= renderTimer). Sowohl x als auch y werden durch CLOCKS_PER_SEC geteilt:
%Vor%Wäre es nicht effizienter zu schreiben:
%Vor%Das allererste Problem, das ich bei der Division gesehen habe, war, dass du keine echte Nummer bekommen wirst, da es zwischen zwei Long-Ints passiert. Das zweite Problem ist, dass es effizienter ist, RenderInterval * CLOCKS_PER_SEC zu multiplizieren und auf diese Weise loszuwerden, was die Operation vereinfacht.
Durch Hinzufügen der Klammern wird die Lesbarkeit verbessert. Und vielleicht werden Sie durch die Vereinfachung dieser Phormula einfacher, was falsch läuft.
Wie Sie bei Ihrer letzten Frage festgestellt haben, sind Sie durch CLOCKS_PER_SEC begrenzt, was nur etwa 18 ist. Sie erhalten einen Frame pro diskreten Wert der Uhr, weshalb Sie auf 18 fps beschränkt sind.
Sie können das vertikale Ausblendungsintervall des Bildschirms für das Timing verwenden, das ist bei Spielen üblich, da es das "Zerreißen" vermeidet (wo die Hälfte des Bildschirms ein Bild zeigt und die andere Hälfte)