Warum ist alles so träge?

Design Patterns, Erklärungen zu Algorithmen, Optimierung, Softwarearchitektur
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
Antworten
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Warum ist alles so träge?

Beitrag von Krishty »

Hi,

Ich überlege gerade, warum viele Spiele so träge werden und wie ich die Latenz von Benutzereingaben minimieren könnte:
  • Asynchrone CPU und GPU – dadurch bevorzugt man eindeutig Durchsatz gegenüber Latenz.
    Man lässt z.B. die GPU drei Frames vorausrendern, um sie besser auszulasten und dadurch eine höhere Frame-Rate zu erzielen. Allerdings beträgt dabei auch die Latenz zwischen Eingabe und Ausgabe mindestens drei Frames. Es sollte offensichtlich sein, dass man die Auslastung schon zumindest verdreifachen müsste, um die Latenz unberührt zu lassen, was völlig illusorisch ist.

    Das produziert dann den typischen Effekt, dass man die Maus schnell einmal im Kreis bewegt und das auf dem Bildschirm auch erkennen kann; allerdings fängt der Bildschirm erst an, wenn die Maus schon wieder stillsteht.

    Gegenmittel ist ab Vista SP2 mit Direct3D 10.1 IDXGIDevice1::SetMaximumFrameLatency().

    Es wäre toll, wenn jemand bei einem eigenen, GPU-limitierten, bei 20 fps kriechenden Spiel den Latenz- und Leistungsunterschied messen könnte.
     
  • Vertikale Synchronisation – dadurch opfert man Latenz für Stabilität.
    Rendert man mit theoretischen 55 Hz auf einen 60-Hz-Monitor, ist man echt angeschissen, weil man auf 30 Hz limitiert wird, und die Latenz damit fast verdoppelt.

    VSync abzuschalten ist inho keine Option, weil die Bildqualität zu sehr leidet und langsam über den Bildschirm kriechende Balken eine zu starke Ablenkung sind.

    Triple Buffering macht Kopfschmerzen, weil das Programm dann mit unregelmäßiger Latenz zu antworten scheint – dieses temporale Aliasing nehmen wir dann als Haken wahr. Dabei sind 30 Hz, 60 Hz, 30 Hz-Muster längst nicht das Schlimmste – katastrophal wird es im Bereich nahe der Bildschirmaktualisierungsrate, wenn das Programm mit 30 Hz, 30 Hz, 30 Hz, 30 Hz, 60 Hz zu antworten scheint. Dadurch kann alles unspielbar werden.

    Imho sollte man in so einem Fall das Warten nicht ans Ende des Frames legen, sondern an den Anfang. Das heißt: Wenn ich im letzten Frame 7 ms auf den Bildschirm warten musste, warte ich im nächsten direkt am Anfang 7 ms (rein exemplarisch!) und berechne erst danach den kompletten Frame inklusive Physik und Logik. So liegt der Zeitpunkt, zu dem ich meine Physik berechne, näher an dem Zeitpunkt, zu dem das Bild auf dem Monitor auftaucht. Damit bleibt die maximale Latenz gleich (wenn die Eingabe zu Anfang der Wartezeit entsteht), aber die minimale Latenz kann sich fast halbieren (wenn die Eingabe zu Ende der Wartezeit entsteht).
     
  • Polling – damit lässt man das Zeitfenster, in dem Eingaben entstehen, zu einem Zeitpunkt kollabieren.

    Drücke ich dreimal pro Frame die Feuertaste, wird ein naives Polling das nur als einen einzelnen Klick interpretieren. Oder als drei Klicks zwar, aber zum selben Zeitpunkt. Dadurch geht jede Menge Information verloren.

    Leider ist Polling die einfachste Möglichkeit, Eingaben in einem Echtzeitspiel zu verarbeiten. Wenn ich es bei mir anders machen wollte, würde mir nur vorschweben, die Eingabeverarbeitung in einen eigenen Thread zu verschieben, der die ganze Zeit wartet. Danach würde jede Eingabe mit einem präzisen Zeitstempel versehen und in den Haupt-Thread zum Verarbeiten geschoben. Hat man dann eine Physik, die mit höherer Frequenz arbeitet als die Bildausgabe (so wie die meisten Simulationen), kann man die Eingaben sogar einzelnen Logikschritten zuweisen.

    Das Ganze birgt großes Problempotential (das Fenster, das die Eingaben verarbeitet, müsste ein anderes sein als das Ausgabefenster, weil ein Thread nur die Message Queue des Fensters abarbeiten kann, das auch in diesem Thread erzeugt wurde) und wäre viel, viel einfacher wenn GetMessageTime() eine höhere Auflösung hätte – aber 60 Hz reichen nicht aus um Eingaben sauber auseinander zu halten (eben getestet) damit kann man aber zumindest die minimale Latenz von Spielen, die eh schon auf 20 fps laufen, wieder auf 60 Hz anheben.
Kritik daran? Vorschläge, was man noch machen könnte? Nützliche Links?

P.S.: Bei einigen Spielen könnte man die bewegten Objekte zuletzt zeichnen, und vorher einen zusätzlichen Logikdurchlauf tätigen. Das geht aber natürlich nicht bei Spielen, in denen der Spieler bestimmt, wo die Kamera hinsieht.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Warum ist alles so träge?

Beitrag von eXile »

Krishty hat geschrieben:Gegenmittel ist ab Vista SP2 mit Direct3D 10.1 IDXGIDevice1::SetMaximumFrameLatency().
Man kann das übrigens im Falle des Nvidia-Treibers mittels der Einstellung „Maximum pre-rendered frames“ forcieren (und ich glaube, für AMD-Graphikkarten gibt es eine ähnliche Option). So kannst du zumindest den Effekt bei kommerziellen Spielen überprüfen.

Unter Direct3D 11 gibt es auch noch SetMaximumFrameLatency.
Krishty hat geschrieben:Es wäre toll, wenn jemand bei einem eigenen, GPU-limitierten, bei 20 fps kriechenden Spiel den Latenz- und Leistungsunterschied messen könnte.
Ich habe das mal früher mit Crysis 2 und einem Multi-Monitor-Setup gemacht. Die Framerate ging von ca. 50 FPS auf ca. 45 FPS zurück; ob es einen tatsächlichen Latenzunterschied gab oder das nur Einbildung war, kann ich nicht mehr sagen. Es tut mir leid, aber ich habe halt einfach keine Hochgeschwindigkeitskamera für so etwas oder so etwas.
 
Krishty hat geschrieben:Vertikale Synchronisation – dadurch opfert man Latenz für Stabilität.
Rendert man mit theoretischen 55 Hz auf einen 60-Hz-Monitor, ist man echt angeschissen, weil man auf 30 Hz limitiert wird, und die Latenz damit fast verdoppelt.
Korrekt. Darum hat Nvidia mal Adaptive VSync gebastelt; das deaktiviert die vertikale Synchronisation wenn die Framerate unterhalb der Bildwiederholfrequenz des Monitors fällt. Natürlich kriegt man dann wieder Tearing (aber auch nur dann!). Leider ist mir kein plattformunabhängiger Weg bekannt.
Krishty hat geschrieben:Triple Buffering macht Kopfschmerzen
Wenn ich korrekt informiert bin, dann gibt es doch unter Direct3D gar kein Triple-Buffering mehr:
http://www.anandtech.com/show/2794/4 hat geschrieben:Microsoft doesn't implement triple buffering in DirectX, they implement render ahead (from 0 to 8 frames with 3 being the default).
Natürlich kannst du das auch wieder über Treiber-Einstellungen verändern (bei Nvidia heißt das einfach „Triple buffering“); aber wir suchen hier ja plattformunabhängige Wege. Ein solcher ist mir jedoch nicht bekannt.

Zur Allgemeinen Informationsaquise möchte ich noch dringend diesen Blogpost vom Timothy Lottes anbieten.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Krishty »

eXile hat geschrieben:
Krishty hat geschrieben:Gegenmittel ist ab Vista SP2 mit Direct3D 10.1 IDXGIDevice1::SetMaximumFrameLatency().
Man kann das übrigens im Falle des Nvidia-Treibers mittels der Einstellung „Maximum pre-rendered frames“ forcieren (und ich glaube, für AMD-Graphikkarten gibt es eine ähnliche Option). So kannst du zumindest den Effekt bei kommerziellen Spielen überprüfen.
Nein; finde ich hier nicht :(
eXile hat geschrieben:Unter Direct3D 11 gibt es auch noch SetMaximumFrameLatency.
Krishty hat geschrieben:Gegenmittel ist ab Vista SP2 mit Direct3D 10.1 IDXGIDevice1::SetMaximumFrameLatency().
Was meinst du damit? :)
eXile hat geschrieben:
Krishty hat geschrieben:Es wäre toll, wenn jemand bei einem eigenen, GPU-limitierten, bei 20 fps kriechenden Spiel den Latenz- und Leistungsunterschied messen könnte.
Ich habe das mal früher mit Crysis 2 und einem Multi-Monitor-Setup gemacht. Die Framerate ging von ca. 50 FPS auf ca. 45 FPS zurück; ob es einen tatsächlichen Latenzunterschied gab oder das nur Einbildung war, kann ich nicht mehr sagen. Es tut mir leid, aber ich habe halt einfach keine Hochgeschwindigkeitskamera für so etwas oder so etwas.
eXile hat geschrieben:Zur Allgemeinen Informationsaquise möchte ich noch dringend diesen Blogpost vom Timothy Lottes anbieten.
Super Links; danke! Insbesondere das mit der Maus- und Bildschirmlatenz war mir noch nicht bekannt.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Warum ist alles so träge?

Beitrag von eXile »

Krishty hat geschrieben:Nein; finde ich hier nicht :(
Tatsächlich; die Option gibt es beim Catalyst-Treiber gar nicht. Das erstaunt mich doch sehr, weil ich das schon sehr angenehm fand, im Zweifelsfall einen großen Hammer zu haben, mit dem ich diese Latenzprobleme plattmachen/zumindest reduzieren könnte. Da bliebt wohl nur noch einen eigene DLL-Umleitung, worauf ich persönlich keine Lust hätte. :?
Krishty hat geschrieben:Was meinst du damit? :)
Ach verdammt, das war mal wieder ein Brainfart von mir. Entschuldige!
eXile hat geschrieben:Natürlich kannst du das auch wieder über Treiber-Einstellungen verändern (bei Nvidia heißt das einfach „Triple buffering“); aber wir suchen hier ja plattformunabhängige Wege. Ein solcher ist mir jedoch nicht bekannt.
Auch da muss ich nun Eigenkritik üben: Das bezieht sich anscheinend nur auf OpenGL. Unter Direct3D gibt es einfach kein Triple-Buffering, egal ob mit nativen Mitteln oder mit Treiber-Hacks. Meiner Meinung nach ist Adaptive VSync auch eine weniger (wie du es schön beschrieben hast) erratische Stabilisierungsmaßnahme als Triple-Buffering.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Krishty »

John Carmack hat auch was zum Thema geschrieben. Als letzten Ausweg empfiehlt er, mit übergroßem FOV zu zeichnen und kurz vor Präsentation einen Nachbearbeitungsschritt drüberzujagen, der diesen internen Puffer wieder in Weltkoordinaten umrechenet und für die Ausgabe an die erst im letzten Augenblick ausgerechnete View Matrix anpasst.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Andre
Establishment
Beiträge: 186
Registriert: 21.12.2011, 20:33

Re: Warum ist alles so träge?

Beitrag von Andre »

eXile hat geschrieben:Tatsächlich; die Option gibt es beim Catalyst-Treiber gar nicht. Das erstaunt mich doch sehr, weil ich das schon sehr angenehm fand, im Zweifelsfall einen großen Hammer zu haben, mit dem ich diese Latenzprobleme plattmachen/zumindest reduzieren könnte. Da bliebt wohl nur noch einen eigene DLL-Umleitung, worauf ich persönlich keine Lust hätte. :?
Möglich ist die Einstellung aber trotzdem, nur eben nicht direkt im Treiber. Dieses Programm erlaubt einem wohl den Zugriff auf diesen Parameter: http://www.chip.de/downloads/ATI-Tray-T ... 14959.html

Selbst ausprobieren konnte ich das zwar nicht (NVidia besitzer), soll aber laut einem Freund super funktioniert haben.
Benutzeravatar
starcow
Establishment
Beiträge: 523
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von starcow »

Ich störe nur ungern eure Experten-Runde, doch mir brennt da ne Laien-Frage unter den Nägeln.
Ist es den so, dass wenn ich den VSync aktiviere das ganze Programm runter gedrosselt wird auf 60Hz / 30Hz (bzw. was der Monitor halt HZ zu leisten vermag)?

Ist es nicht möglich das ganze so zu programmieren, das das eigentliche Programm inkl. Input-Abfragen mit dem maximalen Speed läuft und nur der Bildspeicher im richtigen Intervall quasi getauscht wird?
Oder kommt das dann aufs selbe raus?

Gruss starcow
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Schrompf »

Nö, das ist ne Frage des Code-Designs. Man kann das so machen, wie Du das sagst: die Spiellogik mit einem Affenzahn rotieren lassen und nur das Rendering auf VSync zu limitieren. Manche tun das auch, aber ich persönlich sehe da keinen Sinn drin. Das Rendern ist im Endeffekt der große Zeitfresser. Ich kenne einfach keine Spiellogik, die im Vergleich zur Anzeige nennenswert Rechenzeit frisst. Und damit lohnt es sich einfach nicht, daran zu arbeiten - niemand würde einen Unterschied bemerken.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Krishty »

starcow hat geschrieben:Ich störe nur ungern eure Experten-Runde, doch mir brennt da ne Laien-Frage unter den Nägeln.
Du störst nicht.
starcow hat geschrieben:Ist es den so, dass wenn ich den VSync aktiviere das ganze Programm runter gedrosselt wird auf 60Hz / 30Hz (bzw. was der Monitor halt HZ zu leisten vermag)?
Schrompf hat geschrieben:Nö, das ist ne Frage des Code-Designs. Man kann das so machen, wie Du das sagst: die Spiellogik mit einem Affenzahn rotieren lassen und nur das Rendering auf VSync zu limitieren. Manche tun das auch, aber ich persönlich sehe da keinen Sinn drin.
Krishty hat geschrieben:Hat man dann eine Physik, die mit höherer Frequenz arbeitet als die Bildausgabe (so wie die meisten Simulationen)
Viele Simulatoren lassen die Spiellogik mit 300 bis 2000 Hz arbeiten, weil ein mit 300 km/h auf eine Mauer zurasendes Auto diese sonst einfach durchdringen könnte. Und das benötigt dann schon eine im Verhältnis zum Rendern auffallende Rechenzeit.

Was ich hier als Problem von aktiviertem VSync sehe, ist, dass vorausgezeichnet wird. Viele Anwendungen zeichnen den aktuellen Frame im Back Buffer und haben noch zwei oder drei weitere Back Buffer bis endlich der Front Buffer kommt. Das hat den Zweck, dass die GPU dadurch niemals leer läuft (es ist immer Arbeit für drei oder vier Frames im Voraus da), damit die Aktualisierungsrate (und damit das, was bei Benchmarks gemessen wird) noch einige Prozent höher ist. Die Aktualisierungsrate gibt allerdings nur den Durchsatz an Bildern zu Sekunde an, und nicht etwa die Latenz zwischen Benutzereingaben und dem Zeitpunkt, an dem sich die Eingabe tatsächlich auf dem Bildschirm auswirkt. Wandert der Frame erstmal durch 4 Puffer, hat man bei 60 fps zwar ein flüssiges Bild, aber es reagiert so träge wie bei 15 fps.

Wenn ich mich recht irre wurde zu D3D9-Zeiten noch gerendert so schnell es ging und wenn die GPU mehr als n Frames in ihrer Schlange hatte, wurden die ältesten Aufträge einfach verworfen. Ich finde aber gerade nichts dazu, wie D3D >9 es macht (für die Meckerei hier ist es auch unerheblich).
starcow hat geschrieben:Ist es nicht möglich das ganze so zu programmieren, das das eigentliche Programm inkl. Input-Abfragen mit dem maximalen Speed läuft und nur der Bildspeicher im richtigen Intervall quasi getauscht wird?
Oder kommt das dann aufs selbe raus?
Darum geht es in diesem Thread gerade – was kann man alles tun, dass die Eingaben möglichst nahe am Erscheinen des Bildes auf dem Bildschirm landen?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Warum ist alles so träge?

Beitrag von eXile »

Krishty hat geschrieben:Viele Simulatoren lassen die Spiellogik mit 300 bis 2000 Hz arbeiten, weil ein mit 300 km/h auf eine Mauer zurasendes Auto diese sonst einfach durchdringen könnte. Und das benötigt dann schon eine im Verhältnis zum Rendern auffallende Rechenzeit.
Ich dachte vor allen Dingen, dass Simulatoren immer in fixen Zeitschritten voranschreiten (was der hier noch will, habe ich aber noch nicht so ganz verstanden), weil ansonsten bei der numerischen Integration der Bewegungen bei unterschiedlich langen Zeitschritten unterschiedliche Ergebnisse rauskommen.

Das von dir beschriebene Problem sollte mit kontinuierlicher Kollisionserkennung (im Gegensatz zu diskreter Kollisionserkennung) keine Probleme machen. Wenn man beispielsweise ein A-Posteriori-Physiksystem hat, schaut man, welche Objekte auf ihrem Weg während des letzten Zeitschrittes eine Intersektion verursachten, und korrigiert diese.

Das sollte aber alles unabhängig von der Hauptschleifenrate, der Bildanzeigerate, der Inputabfragerate, etc. sein. Egal ob ich das auf einem 386er einem Core i7 ausführe, das Ergebnis muss numerisch das gleiche sein, ansonsten hat man versagt.

Nachtrag: Meinst du vielleicht die „Spiral of Death“ aus dem ersten Link? So wie ich das gerade sehe, ist das tatsächlich das einzige, was ein nicht-deterministisches Ergebnis liefern könnte. Aber die Lösung dafür ist auch im Text enthalten:
http://gafferongames.com/game-physics/fix-your-timestep/ hat geschrieben:lternatively you can clamp at a maximum # of steps per-frame and the simulation will appear to slow down under heavy load.
Niki
Establishment
Beiträge: 309
Registriert: 01.01.2013, 21:52

Re: Warum ist alles so träge?

Beitrag von Niki »

eXile hat geschrieben:Ich dachte vor allen Dingen, dass Simulatoren immer in fixen Zeitschritten voranschreiten
Das dachte ich eigentlich auch immer. Andererseits sagt er aber auch nicht, dass das nicht so ist.
eXile hat geschrieben:Das von dir beschriebene Problem sollte mit kontinuierlicher Kollisionserkennung (im Gegensatz zu diskreter Kollisionserkennung) keine
Jupp, das sollte definitiv das Problem mit dem Auto und der Mauer lösen, auch mit einer sehr viel niedrigeren Hz-Zahl. Mich würde ja mal interessieren ob Krishty da von Simulationsspielen oder "richtigen" Simulationen redet. Bei richtigen Simulationen könnte ich mir denken das die hohe Hz-Zahl u.A. dazu dient die Objektrotationen pro Zeitschritt möglichst klein zu halten (oder um möglichst gut an eine nicht-lineare "Flugbahn" anzunähern). Kontinuierliche Kollisionsabfrage unter exakter Berücksichtigung von Drehmomenten ist ja nun mal ein Problem (ebenso mit der nicht-linearen Flugbahn).
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Krishty »

Ich wollte damit vor allem Schrompfs Kommentar zurückweisen, die Spiellogik mit höherer Aktualisierungsrate als das Rendern zu betreiben sei sinnlos.

Hat denn eigentlich nie jemand auf den Link geklickt? :D Die Simulationen laufen alle mit festen Zeitschritten, die fast immer weit über der Aktualisierungsrate des Monitors liegen.
eXile hat geschrieben:Das von dir beschriebene Problem sollte mit kontinuierlicher Kollisionserkennung (im Gegensatz zu diskreter Kollisionserkennung) keine Probleme machen. Wenn man beispielsweise ein A-Posteriori-Physiksystem hat, schaut man, welche Objekte auf ihrem Weg während des letzten Zeitschrittes eine Intersektion verursachten, und korrigiert diese.
Okay; das war nur was Anschauliches. Problematisch ist ja nicht nur Kollisionserkennung, sondern die gesamte Physik. LFS (ich kaue drauf rum weil ich mich damit am besten auskenne) simuliert beim Überfahren der Curbs jede einzelne Stoßwelle plus Drehmomente und Querbeschleunigungen; jedes 32tel des Reifens hat dabei andere physikalische Eigenschaften (Temperatur, Dicke, …); und alles wirkt zurück auf Aufhängung und Antriebswelle. Das bedeutet: Rotierende Reifen mit zwei Dutzend Eigenschaften, die sich bei 2000 Hz (300 km/h durch 2 m Reifenumfang * 32 Abschnitte) ändern. Versuch das mal bei 60 Hz zu integrieren.

Die Leute hinter rFactor sind zum Beispiel auch keine trüben Tassen, trotzdem rotiert dort die Spiellogik bei 600 Hz.

Ich persönlich strebe auch so um die 360 Hz an, schlicht weil es einfacher ist. Anstatt bei 60 Hz zu überlegen, wie ich nun meine mit 100 Hz feuernde Gatling genau eine und zwei Drittel Kugeln feuern lasse und da hunderte Zeilen zu investieren, iteriere ich einfach sechs Mal. Dafür wird die Logik auch sechs Mal einfacher. Und sollte es mal nötig werden, das zu vereinfachen, tue ich das auch. No love lost, no love found.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von CodingCat »

eXile hat geschrieben:(was der hier noch will, habe ich aber noch nicht so ganz verstanden)
Wow, endlich mal jemand anderes, der ebenfalls dieses Problem beobachtet hat. Und seine Lösung klingt exakter als meine, die einfach das Zeitdelta träge an die durch Present() vorgegebene Framezeit anpasst. Was er will: Present() kann unter großer Last in nahezu beliebigen Zeitabständen zurückkehren, was in Mikrostottern und maximaler Unruhe bei jeder Bewegung ausarten kann. Durch meine träge Anpassung mit gekoppeltem Sleep() für überschüssige Restzeit habe ich Present() auch irgendwie dazu bewegt, regelmäßiger zurückzukehren; hängt also vermutlich mit der Blockade bei Volllaufen der Frame Queue zusammen.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Krishty »

CodingCat hat geschrieben:Durch meine träge Anpassung mit gekoppeltem Sleep() für überschüssige Restzeit habe ich Present() auch irgendwie dazu bewegt, regelmäßiger zurückzukehren; hängt also vermutlich mit der Blockade bei Volllaufen der Frame Queue zusammen.
Hm. Hast du wirklich Sleep() benutzt? Mit oder ohne zusätzliches timeBeginPeriod()? Ich frage weil Sleep() entweder den aktuellen Zeitabschnitt abbricht oder einen kompletten Zeitabschnitt für die Zeit der Systemuhr abwartet; und das wären 12–16 ms oder 90–60 Hz. Hoch kann deine CPU-Last damit nicht sein …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Schrompf »

Hm, vielleicht kennst Du ja nur andere Beispiele als ich. Ich weiß nur von NVidia PhysX, dass es mit einer definierten festen Framerate arbeitet (default: 60 Hz). Meine eigenen Spiele arbeiten bisher immer mit flexiblen Zeitschritten limitiert auf VSync.

Das Beispiel mit der Gatling Gun ist gut! Ich empfinde das zwar als Extrem-Beispiel, aber es macht das allgemeine Arbeiten mit der Spiellogik doch etwas einfacher. Ich habe zum Beispiel in der Partikelengine Logik drin, die alle neuen Partikel eines Frames anteilig simuliert, um eine kontinuierliche Verteilung der Bewegungsmuster zu erreichen. Klappt prima, könnte man sich aber komplett ersparen, wenn man weiß, dass die PartikelEngine eh mit >> Bildrate arbeitet.

Ich werde aber trotzdem bei meiner "flexiblen" Schrittweite bleiben, da ich eh schon einiges an Arbeit drin habe, um manche Spiellogik-Aufgaben über viele Frames zu verteilen. Diese Notwendigkeit wird mit flexibel vielen Simulationsschritten pro Zeitschritt nur umso anstrengender.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Warum ist alles so träge?

Beitrag von Krishty »

Schrompf hat geschrieben:Das Beispiel mit der Gatling Gun ist gut! Ich empfinde das zwar als Extrem-Beispiel, aber es macht das allgemeine Arbeiten mit der Spiellogik doch etwas einfacher.
Naja; es kommt immer darauf an, was für ein Spiel du entwickelst. Bei Splatter mag es ziemlich egal sein ob ein Geschoss nun 30 % weiter hier spawnt oder da hinten (falls du überhaupt damit arbeitest und nicht nur mit Strahlen); aber wenn wir hier in Kampfflugsimulationen zehn Minuten auf Schussposition hinarbeiten und dann wegen Problemen mit der Aktualisierungsrate oder Input-Lag danebenschießen (zumal nach 2 Sekunden Feuer die Gatling leer ist), ist das ziemlich frustrierend.
Bild
(angepeilte Treffer mit einer Gatling bei 1000 km/h Zielgeschwindigkeit; via)

Letztens hatte jemand in einem Simulator einen Fall entdeckt, wo die Waffenreichweite bei 20 fps fast doppelt so groß war wie mit 40 fps, weil die Ballistik irgendwo desaströs angenähert war und nicht mit fester Aktualisierungsrate lief. Das ist dann insbesondere mit High Scores die größtmögliche Katastrophe; sowas darf nicht passieren.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Antworten