Das perfekte Timing

dust

Im ctor der Timerklasse hat das auf jeden Fall nix verloren.

Sondern? Und warum nicht?

hustbaer

dust schrieb:

Im ctor der Timerklasse hat das auf jeden Fall nix verloren.

Sondern?

Ich hab nie behauptet dass es einfach wäre und ich die Silver-Bullet für Timing hätte

Und warum nicht?

Weil es ein ganz grober Seiteneffekt ist. Löscht du Files im ctor einer String-Klasse? Nein? Eben.

dust

Erklär mal genauer, was da schlimm dran ist, ich blick's nicht.

rapso

dust schrieb:

Richtig so?

jap, das ist gut zusammengefasst!

Vielleicht kannst du noch etwas näher auf das eigehen, was du Animatoren nennst, vielleicht auch mit bisserl Code? Wär' dir sehr dankbar.

oh, sorry, ja, so nannte man an einer engine an der ich gearbeitet habe die objekte an nodes von einem scenegraph, die die nodes dann animiert/bewegt hatten.

Und nochmal zu deinem Source
… zum Abfangen des Wrap-Arounds ist welcher nach 49,7 Tagen eintritt, und dass TICKTIME die erwähnten 40 ms sind, oder?

Danke!

nein, das ist resettet den counter falls 10s lang keine logik lief.
die idee ist ja, falls du mal z.b. nur 5fps hast, dass die logik dann trotzdem noch x-mal pro sekunde durchlaeuft, dann hast du fast kein nuetzliches spiel mehr, also nen shooter waere damit echt unbrauchbar ;).
andererseits koenntest du trotzdem fuer eine simulation die logik mit z.b. 250logikschritten pro sekunde in einem "fast forward" modus rechnen lassen, es gibt einige spiele die dann nur noch wenige fps anzeigten.

ab einem gewissen punkt sollte man das sein lassen. z.b. gibt es notebooks deren festplatte ausgeht nach ein paar sekunden, stell dir vor jemand spielt einen shooter und nun will windows ploetzlich wieder ein ausgelagertes speicherstueck nachladen, startet die hdd, das spiel steht fuer nen moment (kann manchmal 20s dauern).
wenn dann wieder dein spiel weiterlaeuft/rechenzeit bekommt, willst du nicht dass fuer die letzten 20s alles durchgerechnet wird, weil die logik meint dass real 20s vergangen sind und der spieler dann erst wieder ein frame sieht wenn in-game 20s vorbei sind.
wenn er dann vor nem gegner stand, wird er vermutlich tod sein und sich eventuell aufregen

in so nem fall geht man einfach davon aus dass keine reale zeit vergangen ist und nur ein logiktick noetig ist.
manche spiele gehen bei sowas auch mal in den pausemodus und erlauben dem spieler dann ruhig weiter zu spielen.

ebenfalls ist es oft ueblich, dass ein spiel nicht sofort losgeht nach dem pausemodus, sondern erstmal der spieler das spiel sieht, die situation erkennt und nach 3s bis 5s erst die logik einsetzt (wichtig vor allem bei z.b. rennspielen). da kannst du auch einfach den "LastTick" mit +5s initialisieren.

zum interpolieren:
man muss nicht immer und alles interpolieren, man muss die dinge nicht 100% akkurat interpolieren.
stell dir vor du hast 100 baelle die in einem raum quer durch die gegend springen und sich auch gegenseitig beruehren koennen (also physikalisch korrekt). eventuell ist das extrem aufwendig zu simulieren und die hardware auf der es laufen soll schafft das garnicht mit 60fps mit der das spiel laufen sollte.
dann kannst du trotz komplexester, nicht linearer simulation der bewegungen (die vielleicht nur 10mal die sekunde durchlaeuft) berechnen, diese mit 60fps linear interpolieren.
particle kannst du eventuell sogar nur mit nem shader interpolieren.
die camerabewegung des spielerst solltest du aufwendiger interpolieren, also z.b. die winkel ausrichtung jedesmal interpolieren und dann die view matrix neu errechnen.
die bewegung der gegner kannst du interpolieren indem du simpel jedes element einer matrix fuer sich interpolierst zwischen den zustaenden. natuerlich ist das nicht akkurat und bei rotationen hast du leichte verzerrungen, aber das merkt man nicht.
animationen an sich von koerpern musst du vielleicht garnicht interpolieren, du kannst aber die beiden zustaende nutzen um einen motionblur vector zu errechnen (siehe KillZone2 oder Crysis).

das haengt auch immer vom spiel ab. bei einem RTS mag es nicht viel ausmachen wenn die einzelnen einheiten nur 20mal pro sekunde geupdated werden. bei nem shooter faellt eventuell doch auf wenn es keine 100mal sind.

Ich habe mal eine Frage bezüglich der Abkopplung zwischen Logik und Darstellung. Wie genau realisiert ihr das am Beispiel eines Szenengraphs, der für die Darstellung sorgt? Sind logikabhängige Knoten bei euch dort "double-buffered" ausgelegt? Oder ist der Szenengraph komplett doppelt vorgehalten? Wenn Logik und Rendering nicht synchron laufen und bespielsweise auf 2 Threads verteilt werden, wie verhindert ihr, dass der Render-Thread denselben Status zweimal anzeigen muss, weil der Logikthread gerade den nächsten Status des Szenengraphs aktualisiert? Oder darf der Renderer auch einen Szenengraph zeichnen, bei dem der "Zeitstempel" der einzelnen Knoten nicht synchron ist, weil der Logikthread gerade darauf werkelt?

Fragen über Fragen^^

Viele Grüße,
Michael

PS: Oder "interleaved" ihr das Rendern und die Logik nur? Will meinen, beispielsweise 2x Logik -> 1x Rendern -> 5x Logik 1x Rendern ... etc.