spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich hab grad angefangen das Buch zu lesen, bin aber schon nach ein paar Seiten hängen geblieben - nicht weil ich den Inhalt des Kapitels nicht verstanden hätte, sondern eher weil ich nicht verstehen konnte was so etwas in einem professionellem Buch zu suchen hat.

Ich weiß nicht ob darauf noch später eingegangen wird, aber auf die Gefahr hin das ich hier eine bereits bekannte Problematik anspreche:
Die Lösung die hier für die Zeitkontrolle genannt wird ist unheimlich naiv und enthält einige Logikfehler und andere Probleme die eigentlich nur einem Anfänger entgehen können:

1) Die Lösung erfordert das ständige zeitabhängige Umrechnen von Koordinaten - nicht sehr schön, und intuitiv schon gar nicht.
2) Auf langsamen Rechnern (und unter ungünstigen Bedingungen auch bei schnellen) können sehr schnell große Sprünge entstehen, was eine Kollisionserkennung mit dem a posteriori Ansatz komplett unbrauchbar macht.
3) Ressourcen werden unnötig verschwendet: Arbeitet ein Rechner zu schnell, werden völlig sinnloserweise zigtausende Berechnungen der Spiellogik durchgeführt, wenn es hundert oder weniger auch getan hätten.
4) Es wird von einem völlig unrealistischen Aufwandsverhältnis von Graphik- und Logikberechnungen ausgegangen - beiden wird hier die gleiche Gewichtung zugeordnet. Praktisch verbraucht das Berechnen von Graphiken jedoch viel mehr Ressourcen als die Logikberechnungen wie Bewegung oder Kollisionserkennung. Wenn man nicht gerade auf einem Commodore 64 arbeitet dürften die paar Berechnungen die die Logik benötigt locker unabhängig vom Rechner mehrere hundert mal pro Sekunde durchführbar sein, während das Berechnen von Graphiken ungleich aufwändiger ist und sich wahrscheinlich selbst auf einem schnellen Rechner nur ein paar dutzend mal pro Sekunde durchführen lässt (bei einer Szene die mehr als einen Würfel enthält versteht sich).

Nun hätte man das vielleicht noch durchgehen lassen können, wenn die wesentlich bessere Alternative tatsächlich schwieriger zu implementieren oder weniger einleuchtend wäre. Nur ist sie genau das nicht:

Man benutzt einfach einen Timer (unter Windows per SetTimer verfügbar), und führt die Logik vom WM_TIMER handler aus aus, ruft falls nötig InvalidateRect nach dem Logikdurchlauf auf, das Rendern wird dann im WM_PAINT handler erledigt. Im Prinzip wars das schon. Natürlich hinken hier Rechner die mehr Zeit für die Berechnung eines logischen Frames brauchen als die angestrebte logische Framerate es erfordert hinterher - aber dafür gibt es auch eine recht pragmatische Lösung: Man holt sich einen neueren Rechner. Niemand erwartet das Crysis auf einem Apple II läuft, und auf derartig langsamen Rechnern würde die im Buch vorgestellte Methode ebenfalls nicht zu einem befriedigendem Spielerlebnis führen. Angestrebt werden hierbei 60-100 logische Frames pro Sekunde, die muss der Rechner halt schaffen, Bildberechnungen werden maximal mit dieser Framerate ausgeführt und ansonsten eben so oft wie der Rechner es hinkriegt. Man hat hier weder das Problem das Charaktere auf langsamen Rechnern einfach durch Wände laufen, noch unnütze Berechnungszyklen auf schnellen Rechnern. Nebenbei spart man sich die Zeitumrechnungen im Quellcode und das Zeitproblem an sich ist auch gelöst.


Sollte irgendjemandem Gründe einfallen die gegen diese Methode bzw. für die im Buch sprechen, kann er sie hier gerne vor bringen.

PS: Bevor mir jemand damit ankommt: Sollte man extrem komplexe Logikberechnungen durchführen müssen die sich beim besten Willen nicht so oft innerhalb einer Sekunde unterbringen lassen wie der Rest der Logik, so kann er den Teil einfach abkapseln und weniger oft (zB. nur jeden dritten Frame oder so) ausführen.

Wie gesagt, ich hab das Buch grad erst angefangen. Ist mir bloß gleich zu Anfang ins Auge gestochen. Und Gruß zurück