Problem: Verzögerte Auswirkung der Steuerung

Diskussion zum Thema Programmierung unter DOS (Intel x86)
Antworten
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Problem: Verzögerte Auswirkung der Steuerung

Beitrag von zatzen »

Ich würde ja so gern ein Action-Spiel programmieren.
Aber mit meiner Herangehensweise habe ich ein Problem mit dem Bildschirmupdate vs. der Steuerung:

1. Frame:
Spieler erkennt eine Gefahr, will seine Figur bewegen (drückt entsprechende Tasten)

2. Frame: Dargestellt wird, was während der Darstellung von Frame 1 berechnet wurde,
d.h. die Gefahr kommt näher an den Spieler heran, während dieser sich dagegen noch nicht bewegt hat.
Währenddessen wird erst das weitere Spielgeschehen unter Berücksichtigung der Entscheidung
des Spielers berechnet.

3. Frame:
Nun erst wird die eigentlich gewünschte Änderung des Spielers angezeigt (bzw. ist sie nun erst gültig),
während der automatisierte Rest des Spiels schon zwei Frames vorangeschritten ist.


Als Spielgefühl wird sich das so auswirken, dass man die Steuerung als träge empfindet.


Vielleicht habe ich aber auch einen Denkfehler drin.
DOSferatu möge mir verzeihen, dass ich immer noch nicht losgekommen bin von der festen
Taktung und Bindung von Framerate und Steuerung. Zu lange habe ich das wohl so in vergangenen
Projekten gemacht, ohne mir wirklich Gedanken darüber gemacht zu haben. Deshalb stelle ich das
jetzt nocheinmal extra heraus zur Diskussion an alle. Ich frage mich nur, wie monolithische
Systeme wie eine NES Konsole soetwas handhaben, bei denen ich davon ausgehe dass sie
fest mit 50 Hz getaktet sind.
Zuletzt geändert von zatzen am Mi 16. Jan 2019, 16:47, insgesamt 1-mal geändert.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Problem: Verzögerte Auswirkung der Steuerung

Beitrag von zatzen »

Ein Lösungsansatz wäre vielleicht, die "Auflösung" intern zu erhöhen.
Die Grafik-Framerate bleibt gleich, sagen wir einmal 20 Hz.
Aber ich vervierfache intern die Abfrage der Steuerung und die Berechnung
der automatisierten Elemente.
Damit würde sich der "Versatzfehler" auf ein Viertel reduzieren.

Eine Verfeinerung der internen Objektberechnungen ist ohnehin gut, da
man dann für schnell bewegte Objekte nicht interpolieren muss für Kollisionsabfragen.

Ich bin mir nicht sicher ob das funktionieren würde, es fiel mir nur gerade ein.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Problem: Verzögerte Auswirkung der Steuerung

Beitrag von Dosenware »

Hmm, bei der Frameberechnung den Spieler + seine Aktion als letztes rendern?
Das funktioniert natürlich nicht wenn der Bildschirm an der Spielfigur klebt, daher sollte die Spielfigur in solchen Spielen einen kleinen Bewegungsbereich haben bevor der Bildschirm mitscrollt.

Alternativ ließe sich auch ein größerer Bereich rendern eben: Bildschirmauflösung + maximale Strecke die der Spieler in einem Frame zurücklegen kann - dann könntest du einfach den Bildausschnitt verschieben.

PS. da Wobo gleich DOOM erwähnt hat - obiges ist nur für 2D...
Zuletzt geändert von Dosenware am Mi 16. Jan 2019, 19:03, insgesamt 2-mal geändert.
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Problem: Verzögerte Auswirkung der Steuerung

Beitrag von wobo »

Grüß Dich Zatzen!

Nein, ich glaube nicht, dass ein Spieler die Steuerung dann als träge empfinden wird. Der Spieler wird die Steuerung m.E. nur dann als träge empfinden, wenn die Framerate insgesamt zu gering ist. Anfang der 90er galten 15 fps als gut, heute wird das als sehr träge empfunden.

Ich finde grundsätzlich ein Game ab 30 fps, besser 35 fps als spielbar und alles darunter als träge. (Ist aber Geschmackssache)

Doom verwendet z.B. triple buffering bei 35 fps, d.h. die Steuerbefehle des Spielers werden erst nach 3/35 sec, also mit einer Verzögerung von 0,086 sec angezeigt. Merkst Du diese Verzögerung? (Ich nicht :-))

AUßerdem muss es zu gar keiner Verzögerung kommen, wenn Du die richtige Reihenfolge einhältst und nicht auf double oder triple buffering angewiesen bist. (Double und triple buffering brauchst Du eh nur in den 16 Farbmodi und den ModeX-Varianten).

Im Standard $13 Mode legst Du einfach einen Virtuellen Buffer ins Ram, den Du - wenn alles fertig berechnet ist - dann ins Videoram kopierst.

Also:
-Gegnerbewegung berechnen
-Spielerbewegung abfragen/berechnen
-Grafik in VBuffer aufbauen,
- alles ins Videoram kopieren.


Das ist auch ausgeglichen. Der Spieler reagiert auf den aktuell am Bildschirm angezeigten Gegner, der aber schon einen Schritt weiter ist. Der Gegner aber berechnet seine Bewegung auch anhand der noch am Bildschirm angezeigten Spielerposition, da er dessen alte Daten verwenden muss. Beide verwenden also die aktuell am Bildschirm angezeigten Daten zur Berechnung der weiteren Vorgehensweise. Der Computergegner macht dies, weil er die Spielerbewegungsbefehle zu diesem Zeitpunkt ja noch gar nicht abgefragt sind. Der Spieler macht dies, weil er nur auf die am Bildschirm angezeigten Gegnerpositionen reagiert.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Problem: Verzögerte Auswirkung der Steuerung

Beitrag von zatzen »

Vielen Dank schonmal Ihr beiden, für die schnellen Antworten!

Ich habe übrigens weder 3D noch Scrolling geplant, und ja, es soll Mode 13h sein.

Ich spiele das mal durch, Wobo, wobei ich nicht nur den Fall von AI oder von Menschenhand
gesteuerten Gegnern in Erwägung ziehe, sondern auch soetwas banales wie ein Geschoss
oder irgendein sich konstant bewegender Gegenstand dem man aus dem Weg gehen muss.


1. Frame:

Angezeigt wird, wie der gefährliche Gegenstand gerade eine Kollisionsmaßeinheit vom Spieler
entfernt ist.

Währenddessen wird:
- berechnet, wie sich der Gegenstand weiter bewegt
- die Spielerbewegung abgefragt (vom Gegenstand weg) ***
- Grafik aufbauen

2. Frame
- in den VRAM kopieren und somit anzeigen:
Spielerfigur und Gegenstand sind nicht kollidiert (Applaus!)

Alles soweit schön und gut, aber es gibt ein Problem an der Stelle ***:
Wenn nicht schon andere Prozesse, benötigt spätestens der Grafikaufbau
einen nicht zu vernachlässigenden Rechenaufwand (auch wenn's eigentlich
nur Datenkopiererei ist, je nachdem).
Daher muss, um die Rechenleistung voll auszunutzen, die Spielerbewegung
zum Startzeitpunkt der gesamten Frameberechnung eigentlich schon bekannt sein, denn
man kann ja nicht auf sie warten, was dazu führt, dass man den Spieler-Input aus dem
vorherigen Frame beziehen muss.

Daher wird das ganze zu:

1. Frame:

Angezeigt wird, wie der gefährliche Gegenstand gerade eine Kollisionsmaßeinheit vom Spieler
entfernt ist.

Währenddessen wird:
- berechnet, wie sich der Gegenstand weiter bewegt
- die Spielerbewegung vom vorherigen Frame (Frame "0") ausgewertet
- Grafik aufbauen

2. Frame
- in den VRAM kopieren und somit anzeigen:
Spielerfigur und Gegenstand kollidieren, wenn Spieler sich erst in Frame 1 in Bewegung gesetzt hat



Es besteht eine Chance, dass es so wie in der ersten Darstellung funktioniert, das dann aber nur
für den Fall, dass der Spieler in einem winzigen Bruchteil der Zeit nachdem das neue Bild generiert wurde
eine Entscheidung trifft, was sehr unwahrscheinlich ist.

Vielleicht mach ich hier auch Erbsenzählerei und es ist nunmal so dass die Spielerfigur immer nur halb
so schnell wie die Framerate reagieren kann. Aber das möchte ich geklärt haben bevor ich ein Spiel
angehe. Ich würde so in etwa eine Framerate von 25 fps anstreben, dann hätte ich eine Steuerungs-
verzögerung von 40 ms, etwa halb so viel wie bei Doom.
mov ax, 13h
int 10h

while vorne_frei do vor;
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Problem: Verzögerte Auswirkung der Steuerung

Beitrag von wobo »

Wie gesagt, ich sehe das als sehr theoretisches Problem, weil ich glaube, dass die zeitliche Verzögerung nicht spürbar ist. Der Mensch hat laut Wikipedia im besten Fall eine Reaktionszeit von 0,2 - 0,3 sec. Hast du eine Framerate von nur 25 fps, dann kommt eine Verzögerung von 0,04 sec hinzu. Der Mensch mit einer Reaktionszeit von 0,2 sec reagiert dann rechnerisch in 0,24 sec, aus seiner subjektiven Sicht aber immer noch in 0,2 sec (weil er ja auf die alte, am Bildschirm dargestellte Situation reagiert.).

Außerdem reagiert der Mensch nicht auf die exakte Situation, sondern antizipiert z.B. die Ausholbewegung des Gegners beim Schlag oder das von weitem zukommende Geschoss. Ich würde also meinen, dass der Mensch nicht auf das reagiert, was unmittelbar bevorsteht, sondern das was innerhalb der Reaktionszeit abwendbar ist. Ich denke also, dass eine rechnerische Verzögerung von 0,04 sec nicht wahrnehmbar ist.

Geklärt haben, kannst Du das wahrscheinlich nur, wenn einen Prototyp schreibst und nicht vorher. Ich glaube aber nicht, dass die rechnerische Verzögerung ein Problem darstellt, da sonst Games wie DOOM etc. nicht funktioniert hätten.
Antworten