Showroom - Aktuelle Arbeiten und Projekte

[woodsmoke]

Arbeite an einen 2. Teil von einer mech simulation. Das erste war Mechwarrior 2 Feeling, das jetzt eher Mech2 Mecenaries.
Dazu nutze ich die alte erste Version aus meinen programmier n00b Zeit. Ist lustig, viel brute force taktik.
Ziel ist eine aufwändigere Gegner AI, ein paar mehr Waffen, Mechs, aufgebohte Optik ...
Vielleicht auch zufallsgenerierte Welten, und da Söldner Permadeath + Punkte-Highscore-System.

[joeydee]

Habe gestern mal einen Tesselation-Algo ausprobiert, dessen Name ich leider nicht kenne.
Ich schätze zwar, dass der generell deutlich mehr Line-Intersection-Tests benötigt als z.B. Pig Ear, also dürfte nicht besonders optimal sein. Und schmale lange Dreiecke sind ja auch nicht besonders hübsch, alles mehr so Brute-Force, also dürfte nicht wirklich von Interesse sein. Aber: er funktioniert ;)

Dafür ist die Formulierung ziemlich simpel: Nimm einen beliebigen Punkt im Loop als Startpunkt an, gehe im Umlaufsinn durch welche Punkte von dort aus "sichtbar" sind, und füge diese zum aktuellen Fan hinzu. Für Punkte die nicht sichtbar sind, mache einen neuen Loop auf welcher separat gelöst wird.

Ist entfernt mit Schweinsöhrchen verwandt, aber schneidet keine einzelnen Dreiecke ab, sondern ganze Polyloops (welche am Ende dann alle jeweils durch einen einzelnen Fan repräsentiert werden können, dabei aber nicht konvex sein müssen), und arbeitet von innen nach außen statt von außen nach innen.

Die Idee ist an einen Bot angelehnt, welcher seine Umgebung von einem Punkt aus scannt, offene Portale im Scanpanorama markiert, später dann zu diesen hinrollt und von dort aus die noch unbekannten Bereiche dahinter scannt, bis keine Portale mehr übrig sind.

Im Bild startet der Algo bei 0; 1 ist sichtbar, 2 und 3 nicht, 4 ist wieder sichtbar, also wird ein separater Loop 1,2,3,4 in die ToDo-Liste gelegt. Ebenso 4,5,6, sowie 7-19 usw. Zum aktuellen Fan gehören dagegen die von 0 aus "sichtbaren" Punkte 0,1,4,6,7,19,...
Die blauen Kreise markieren jeweils den letzten sichtbaren Punkt und damit Startpunkt für abgetrennte Polyloops, die blaue Linie die Schnittkante zum nächsten wieder sichtbaren Punkt; abgetrennte Dreiecke (wie z.B. 4,5,6) sind trivial und haben hier im Debug-Render keinen neuen Startpunkt, sondern werden ungeprüft in die Renderliste gelegt.

[joeydee]

Relativ uninteressant, ich zeigs trotzdem. Weitere kleine Beschäftigungen mit Triangulierung. Diesmal der Original-Schweinsöhrchen-Algo, und dabei lief mir auch die konvexe Hülle über den Weg. Alter Kumpel, lange nicht gesehen ;)

Nimm das nächstbeste Ohr:

Nimm das Ohr mit dem kleinsten Innenwinkel am verbliebenen Polygon:

Nimm das Ohr mit der kürzesten Cut-Strecke:

Definiere "Ohr" als "Konkave Stelle, Verbindungsline der Schenkel ausschließlich außerhalb des Polygons"
(Oder einfacher: Kehre den Umlaufsinn des Polygons um)
Das verbleibende Polygon (hier weiß) ohne weitere solche Konkav-Stelle ist die konvexe Hülle. Behaupte ich mal, Beweisführung geht anders.

[Schrompf]

Wie unterscheidest Du zwischen z.B. den kürzesten Cut-Strecken? Erstellst Du da jedes mögliche Ohr und wählst dann das aus, was den kürzesten Cut hat? Oder gibt's irgendnen Trick, wie Du z.B. den Punkt erkennst, von dem aus der TriFan den kleinsten Innenwinkel hat?

[joeydee]

Im Moment noch Brute Force, also ja, komplette Prüfung in jedem Durchgang.
Man kann aber vorher eine sortierte Liste mit allen konvexen Ecken erstellen, nach dem Grad der Konvexität (Innenwinkel) oder dem Abstand der Schenkel-Endpunkte. Für den nächsten Clip nimmt man dann das erste Element dieser Liste, welches den eigentlichen Ohr-Test besteht. Diese Liste kann man dann nach jedem Clip ja relativ aufwandsarm updaten (Konvexität der beiden Nachbarpunkte kann sich geändert haben) und sortiert halten.

[**Achilles**]

Ich bin gerade dabei , etwas zu erstellen wo sich wahrscheinlich nie jemand getraut hat es zu versuchen. Ich werde natürlich sehr viele Orte in die Spielidee einbauen. Natürlich wird bald mein erster Trailer fertig werden. Aber zuerst möchte ich Nürnberg nachkonstruieren und dass kostet viel Zeit. Wer sich mit Unity Gut auskennt kann mir gerne helfen. Das Video hier ist nur eine Show , was UPBGE kann. Für mein vorhaben wird es von Level zu Level ausreichend sein und komplett mit Python Programmiert. Ich werde euch hier auf dem Laufenden halten.

[smurfer]

Hallo zusammen,

es gibt ein paar Spiele, Techniken und Mechaniken, zu denen ich immer wieder zurückkomme. Und im Zuge meines Lernprozesses mit Zig habe ich vieles neu aufgesetzt. Ich habe hier im Forum und auch beim Stammtisch schon das Projekt "Rayworld-NG" vorgestellt. Nachdem ich dort eine Mini-Simulation eines Asteroidengürtels per RTT auf die spiegelnden Wände gemappt habe und irgendwann das Raycasting-Interieur auch eine Geschichte bekommen muss -- wie eine Raumstation oder ein großes Schiff -- bin ich wieder bei einem meiner Lieblingsthemen gelandet: Asteroids in etwas moderner. Wenn das 2D-Minigame soweit (momentan als eigentständiges Programm) läuft, soll es auf den "Bildschirmen" in Rayworld genutzt werden können.
Meine grundsätzlichen Zig-Codeteile, die ich z.B. für die Grafik nutze, sowie die generelle Architektur, sind (hoffentlich) so modular, dass es dann gut eingebettet werden können sollte.
Außerdem war ich sehr positiv überrascht von der Performance in Zig, die einem durch den Code-Stil irgendwie aufgezwungen wird. Man macht sich eben gezwungenermaßen viele Gedanken über die Speicherauslegung, die Cache-bezogen ordentlich Performance liefern. Daher wollte ich mal wieder meine alte Particle-Emitter-Engine neu aufleben lassen und das passt ganz gut zu dem kleinen Asteroids-Raumschiff mit Newton'scher Physik.

Hier der erste Prototyp:

Dazu zwei Anmerkungen:
1. Die Sterne im Hintergrund gehören teilweise zur Galaxy-Textur, teilweise sind sie gerendert und bewegen sich parallax. Ich habe versucht, den Übergang von Bild zu gerendert möglichst nahtlos zu gestalten. Das sieht man allerdings erst in Bewegung.
2. In dem Zusammenhang und mit den Partikeln (im Bild ein paar 10 000), habe ich das erste Mal tatsächlich Pointsprites im Shader genutzt. Hatte ich nie Berührungspunkte mit, aber für den Zweck scheint es ein gutes Mittel, hat viel gebracht.

Ist natürlich alles noch im sehr frühen Teststadium.

Beste Grüße

[smurfer]

Noch ein paar zusätzlich Hintergrundinfos:

Üblicherweise verwende ich für einfache Kinetik einen semi-implicit Euler zur Integration (wie erwähnt einfache Integration, RK4 u.Ä. außen vor). Für diejenigen, denen das nichts sagt:
Die Beschleunigung der Objekte wird integriert, es ergibt sich die Geschwindigkeit, diese wiederum integriert zur Position, also

Code: Alles auswählen

acc -> vel -> pos

in jedem (physikalischen) Frame.
Explizite Integratoren, also solche, die aus dem (wenn wir mal in der Physik bleiben) Zeitschritt t den Zeitschrit t+1 berechnen, fügen dem System durch numerische Ungenauigkeiten Energie zu. D.h. bei sehr dynamischen Systemen, wie Feder-Dämpfer-Masse-Systeme (oder noch schlimmer solche mit starren Verbindungen), ist es recht ungeeignet, da diese mitunter "explodieren". Implizite Integration, die zur Berechnung der neuen Werte zu t+1 auch Werte aus der Zukunft (z.B. auch Zeitpunkt t+1) nutzen, entziehen eher Energie, sie dämpfen. Allerdings sind oftmals die Zukunftswerte nicht bekannt.
Bei der o. g. Zweifach-Integration wird wie erwähnt häufig ein ein semi-impliziter Integrator verwendet, für das Beispiel heißt das:

Code: Alles auswählen

acc(t) -> vel(t+1) -> pos(t+1) 

.
Hier wird der neu berechnete Wert für die Geschwindigkeit direkt für die Integration zur Position genutzt. Diese Art von Integratoren ist recht neutral, was die Energie angeht und bietet sich im Bereich der Kinetik für einfache Dinge an.

Da nun Zig explizit SIMD-Instruktionen mit Schüsselwörtern unterstützt, kann sowohl die x-, wie auch die y-Koordinate in einem Vektor gleichzeitig integriert werden und man erhält direkt doppelte Geschwindigkeit, was sich in meinen Messungen auch so bestätigt.

Nun kam mir folgende Überlegung: Für einen Partikel-Emitter muss der Integrator nicht sonderlich genau sein, er darf ruhig rein explizit sein. Warum also nicht einen Vektor bestehend aus

Code: Alles auswählen

(acc_x, acc_y, vel_x, vel_y)

und diesen direkt auf

Code: Alles auswählen

(vel_x, vel_y, pos_x, pos_y)

integrieren. Einzig die Geschwindigkeit zu t+1 im zweiten Vektor muss im nächsten Frame wieder in den ersten Vektor kopiert werden. Auch dafür gibt es SIMD-Instruktionen. Mit etwas Overhead ist für diesen Schritt dann am Ende die Berechnung der Dynamik etwa Faktor 3.0 - 3.5 schneller.

Natürlich habe ich nur meine eigenen Berechnungen als Stichprobe und ich hoffe, hier nicht zu viel geschwafelt zu haben, was vielleicht eh 90% schon wissen und kennen. Aber mir hat es viel Freude bereitet, dahingehend zu optimieren.

Disclaimer: Für die weitere Entwicklung bin ich erstmal wieder zu 2-Komponenten-Vektoren zurück, da der Code mit Umsortieren, lokalen Koordintensystemen, Parent-(Winkel-)Geschwindigkeiten, etc. im gezeigten 4-Komponenten-Vektor etwas unübersichtlich wurde und erstmal die Emitter "fertig" werden sollen, bevor ich final optimiere -- dann kann es wieder aus dem Branch geholt werden.

[woodsmoke]

Ich arbeite gerade an der GAME OVER Graphik anstatt erstmal Gegner KI, wobei ich für die KI schon auf Papier einen Plan erstellt habe.

[Schrompf]

Spannend. Also vom Projekt seh ich noch nicht so viel, aber die Infos zur Physik und zur Euler-Integration fand ich spannend. Hab ich richtig verstanden, dass die Mathematik in dieser Reihenfolge:

Code: Alles auswählen

a = collectAllForces();
v = v + a*dt;
p = p + v*dt;

numerisch stabil ist und dieser Code hingegen:

Code: Alles auswählen

a = collectAllForces();
v = v + a*dt;
p = p + v*dt + 0.5f*a*dt*dt;

Energie ins Gesamtsystem einträgt? Das klingt falsch für mich, aber ich habe aufschwingende Systeme selbst schon gesehen und nie verstanden, warum das manchmal knallt und manchmal stabil bleibt, und vielleicht ist das ja der Grund?

[smurfer]

Hi Schrompf,

ganz so einfach ist es meine ich leider nicht, dass die semi-impliziten Integratoren stabil sind. Es hängt ganz stark von der Frequenz in den Signalen und der Abtastrate (also dem dt ab).
Ich bin kein Mathematiker (mögen mir diese verzeien, falls nicht alle Termini und Zusammenhänge richtig passen), aber versuche das noch einmal nach meinem Verständnis zusammenzufassen. Alles bespielhaft in einfacher Ausprägung:

Expliziter Integrator

• Aktuelle Werte werden aus vergangenen berechnet. Im Beispiel:

  Code: Alles auswählen

  v(n+1) = v(n) + a(n) * dt

• Bringt tendenziell Energie ins System.
• Beispiel Auswirkung bei zu großem dt: Aus einer Kreisbahn wird numerisch integriert eine größer werdende Spirale, ein Feder-Masse-System schwingt auf

Impliziter Integrator

• Aktuelle Werte werden aus aktuellen (und evtl. vergangenen) berechnet. Im Beispiel:

  Code: Alles auswählen

  v(n+1) = v(n) + a(n+1) * dt

• Entnimmt tendenziell Energie aus dem System.
• Beispiel Auswirkung bei zu großem dt: Aus einer Kreisbahn wird numerisch integriert eine kleiner werdende Spirale, ein Feder-Masse-System wird gedämpft

Implizit ist einem meist lieber, generell ist das oben genannte Verhalten zwar in beiden Fällen ungenau, allerdings geht zweiteres gegen Null, ersteres gegen Unendlich.

Genauigkeit / Stabilität:

• Hängt wie oben erwähnt sehr stark vom Signal und dem dt ab
• Hängt stark vom Integrator ab, implizit/explizit, Ordnung, Verfahren etc.

Semi-Implizit
Der Euler ist erster Ordnung und daher auch nicht sonderlich gut im Sinne von genau/stabil. Bei deinem Beispiel (mit kleiner Ergänzung)

Code: Alles auswählen

a = collectAllForces();
v(n+1) = v(n) + a(n)*dt;
p(n+1) = p(n) + v(n+1)*dt;

ist der erste Teil explizit, der zweite implizit und die oben genannten Eigenschaften heben sich einigermaßen auf. Drehst du deine beiden Zeilen um, entsteht

Code: Alles auswählen

a = collectAllForces();
p(n+1) = p(n) + v(n)*dt;
v(n+1) = v(n) + a(n)*dt;

Hier sind beide explizit wie in meinem 4-Komponentenvektor-Beispiel oben im Post, das ist somit ungenauer/instabiler.

Ordnung etc.
Wie erwähnt ist der Euler aber in der Form nur erster Ordnung und somit eher für Probleme geringer Genauigkeit geeignet.

Dein zweites Beispiel kann ich in dem Zusammenhang schwer vergleichen. Es ist ja (wieder etwas angepasst)

Code: Alles auswählen

a = collectAllForces();
v(n+1) = v(n) + a(n)*dt;
p(n+1) = p(n) + v(n+1)*dt + 0.5f*a(n)*dt*dt;

Das ist irgendwie auch etwas semi-implizit (wenn Du die Zeilen tauscht, wieder nicht), aber der zweite Teil geht ja eher in Richtung Verlet-Integration, also zweiter Ordnung. Dort könntest Du theoretisch auch in der ersten Zeile diesen Term der zweiten Ordnung einbringen, das wäre physikalisch der Jerk, die zeitliche Änderung der Beschleunignung.
Wie gesagt, fällt mir schwer zu vergleichen.

Das ist aber nur eine grobes Verständnis meinerseits, man kann damit ja ganze Dissertationen füllen und hier fehlen ja noch viele weitere auch einfache Aspekte wie Mehrschritt-Verfahren (Adams-Bashforth, Adams-Moulton -- die beiden in Kombination lassen sich wieder semi-implizit einsetzen, wenn ich das recht in Erinnerung habe), Prädiktor-Korrektor-Verfahren, höhere Ordnungen (Runge-Kutta ist sehr beliebt, benannt mit der Ordnung, RK1 müsste Euler sein, RK2 Leapfrog oder Ähnliches, viel benutzt in Physiksimulationen mit viel Dynamik RK4, usw.). Und beliebige Kombinationen aus allem sowie Fehlerordnungen (an der Stelle wird man meine ich auch aussagekräftiger über die Stabilität, habe ich mich aber nie mit beschäftigt.).

[joeydee]

Jüngstes Experiment: Eine Art Achterbahn (ohne Physik, kein geschlossener Track) prozedural erstellen, mit weicher Fahrt (Stichwort stimmige Ableitungen), und so angelegt dass möglichst immer ein Stück voraus einigermaßen im Blickfeld bleibt, um später mal auf Hindernisse und Sammelzeugs reagieren zu können. Also so, dass z.B. nichts unerwartet hinter einer Kuppe auftaucht und man keine Chance mehr hat auszuweichen.
Mit etlichen Parametern für Berg/Tal, Kurven, Twists etc. - man kann auch flache und ruhigere Strecken generieren.
Vielleicht wird ja mal ein einfaches Game draus, eher casual in Richtung C64-Trailblazer-Gameplay, keine Rennsim.
In Bewegung: https://youtu.be/jvqmPCor6gs

[Schrompf]

Danke, @smurfer

Und schick, @joeydee Du könntest beim Wireframe-Look bleiben, wenn Du die Außenkanten fetter und/oder farbintensiver renderst.

[smurfer]

@joeydee: Schwer, vernünftige Bilder zu finden, hat mich aber sofort an das HUD von I-War erinnert :-)

[joeydee]

Es geht tatsächlich erstmal nur um Tech/Evaluation. Ich möchte mal ausprobieren, wie sich ein Trailblazer-ähnliches Game (Basis-Gameplay nicht unähnlich dem Barrel-Renen von Grinseengel) steuern lässt, wenn sich der Track quer durch den Raum schlängelt statt endlos linear. Wahrscheinlich wirds aber viel zu verwirrend, ist höchst experimentell.

Der Track mehr in Original-Optik, aber geschlängelt, würde übrigens so aussehen:

Beim Original gings stur geradeaus: https://plus4world.powweb.com/dl/screen ... r_main.gif

Aber wie gesagt, noch verfolge ich keinen spezifischen Stil, sondern untersuche nur wie sich eine passende Steuerung anfühlt.

[gombolo]

Seit einigen Monaten arbeite ich an einer kleinen 3D-Engine. Nachdem ich jetzt einfach Triangle erstellen kann, Texturen, direktes Licht erzeugen und rendern kann, habe ich mich dazu entschlossen, mich dem Thema Kollision zu widmen. Sicher, ich könnte den einfachen Weg gehen und auf DirectXCollision zurückgreifen, aber wo bleibt da der Spaß? :D

Ich habe gehört, dass eine achsenorientierte Box (AABB) relativ einfach zu implementieren ist. Eigentlich ist es auch nicht allzu schwer zu verstehen. Im Grunde handelt es sich dabei um drei Achsen in den Dimensionen x, y und z, die die größte Ausdehnung des Objekts beschreiben.

Allerdings reicht es nicht aus, nur die Box zu berechnen. Schließlich möchten wir auch sehen, was passiert. Also habe ich zusätzlich die Möglichkeit implementiert, die Begrenzungsbox als Linien zu rendern. Das hat für einen Abend schon ganz schön Arbeit gemacht.

Ach was ich noch vergessen habe. Wenn sich das Objekt dreht muss man die Box ja auch noch anpassen...Ich weiß nicht, vielleicht sollte ich mir ein neues Hobby suchen :D

Den Code auf GitHub habe ich noch nicht aktualisiert, weil der Quellcode momentan eher einem Schlachtfeld gleicht... Nun ja, immerhin kann man jetzt die Begrenzungsbox um das 3D-Objekt sehen. Das zählt ja auch schon etwas.

Das Bild ist ein gif...einfach mal draufklicken...

[joeydee]

Hier mal das Basis-Gameplay von "Trailblazer" implementiert.
Die Kurven werden automatisch geflogen, man muss sich nur auf links/rechts und Jumps konzentrieren.

[Mirror]

Sieht echt gut aus. Du machst echt tolle Sachen joeydee.

[gombolo]

Hier mal das Basis-Gameplay von "Trailblazer" implementiert...

hmmm sieht interessant aus....

[Jonathan]

Hier mal das Basis-Gameplay von "Trailblazer" implementiert.
Die Kurven werden automatisch geflogen, man muss sich nur auf links/rechts und Jumps konzentrieren.

Cool. Ist ein schönes Beispiel dafür, wie durch Präsentation ein eher simples Spielprinzip spektakulärer gemacht werden kann. Zumindest im Video macht das Biegen der Bahn ordentlich was her.
Steuerung scheint auch gut zu sein, du scheinst du schmalen Bahnabschnitte ziemlich mühelos zu treffen. Aber ist das Hängenbleiben an den roten Feldern Absicht, oder Versehen?

[joeydee]

Danke für euer Interesse :)
Das Hängenbleiben am ersten Block ist Absicht, zur Demo was das ist. Der Rest war eher Zufall/Ungeschick glaube ich. Die schmalen Abschnitte sind deshalb gut zu treffen, da ich weiß dass sie immer in der Mitte sind. Das kann man bei einzelnen Blöcken und Löchern auf Distanz schlechter abschätzen und schnell genug darauf reagieren.
Es bleibt aber nicht bei reinen Zufallsbahnen, sondern es soll mal wiedererkennbare Abschnitte und Muster geben, um Bahnen besser trainieren zu können. So war auch das Leveldesign im Original.

[joeydee]

Noch eins. Eigentlich sollte ich einen Projektthread machen, aber das bleibt wahrscheinlich sowieso bald wieder liegen, ich kenne mich.
Local Multiplayer im Splitscreen. Diesmal eine weniger wilde Strecke. Ich steuere hier Orange (oben), Grün lässt sich gleichzeitig mit anderen Tasten steuern, läuft hier aber einfach ungesteuert auf Maxspeed mittig durch, und Maxspeed ist ein klein wenig schneller als bei Orange.
Player-Kollision gibts nicht. Gibts auch bei Trackmania Multiplayer nicht. Passt also. Könnte ich aber trotzdem mal ausprobieren.
Außerdem muss ich mir mal Gamepads als Input anschauen.
Auf dem Plan stehen auch noch das Rennen gegen Ghost-Records, um auf Medaillenjagd zu gehen oder eigene Rekorde zu brechen.
Sollte ich mich da wirklich durch die restliche Technik durchhangeln, werde ich über Polish, Sound, Theme usw. nachdenken und erst dann ein "Projekt" nennen.

[gombolo]

Auf dem Plan stehen auch noch das Rennen gegen Ghost-Records...

Du weißt schon, wie das technisch funktionieren soll? Ich wollte das für mein Spiel implementieren (mit Unity erstellt), aber ich bin an der frameunabhängigen Bewegung der Objekte gescheitert. Denn als ich den Spieler mit den aufgezeichneten Werten durch das Spiel geschickt habe, hat es sich nie genau so bewegt, wie ich es gespielt habe. Dafür hätte ich das ganze Spiel umschreiben müssen, denn auf dieselbe Eingabe musste dieselbe Ausgabe erfolgen. Leider tat sie das nicht... nur so als Hinweis :)

[Jonathan]

Du weißt schon, wie das technisch funktionieren soll? Ich wollte das für mein Spiel implementieren (mit Unity erstellt), aber ich bin an der frameunabhängigen Bewegung der Objekte gescheitert. Denn als ich den Spieler mit den aufgezeichneten Werten durch das Spiel geschickt habe, hat es sich nie genau so bewegt, wie ich es gespielt habe. Dafür hätte ich das ganze Spiel umschreiben müssen, denn auf dieselbe Eingabe musste dieselbe Ausgabe erfolgen. Leider tat sie das nicht... nur so als Hinweis :)

Wo wir gerade beim Thema sind: Ich hatte darüber auch neulich nochmal nachgedacht, weil ich das in Harald Hoppelhase einbauen wollte, damit man anschauen und überprüfen kann, wie Highscores erreicht wurden.

Aktuell steppe ich alles mit dem time-delta des letzten Frames (was vermutlich theoretisch ja auch leicht falsch ist, man sollte ja wohl eher mit dem delta des aktuellen Frames rechnen, nur ist das natürlich noch unbekannt), sie läuft alles mit schwankender Framerate immer gleich schnell, gut soweit. Jetzt kann ich natürlich auch einfach feste Zeitschritte machen und zwar bei Bedarf mehrere, bis ich halt entweder eins über oder unter dem aktuellen Frame-Delta bin. Nur, sieht das dann noch flüssig aus? Oder muss ich, nur fürs Rendern, dann einen Bruchteil des deltas nochmal weiter rechnen, dass dann nur zum Rendern verwenden, danach verwerfen und wieder mit ganzen Schritten weiter rechnen? Ist das in der Praxis so kompliziert, wie es auf den ersten Blick klingt?

Zweitens, wäre es ja nett, nur die Eingabe zu speichern (welche Taste in welchem Frame gedrückt ist), weil man die super leicht zentral abgreifen kann. Das bedingt natürlich, dass die ganze Spiellogik tatsächlich deterministisch ist, inklusive Ungenauigkeiten bei float-Berechnungen. Könnte ja vlt. bei unterschiedlichen CPUs, oder auch wenn sich mal ein Kompilerflag ändert, dann leicht unterschiedliche Ergebnisse bedeuten, die sich schnell aufschaukeln. Also muss alles auf Int basieren, die dann garantiert immer gleich gerechnet werden?

Das klingt jetzt beides nach recht fundamentalen Umstellungen, die selbst, wenn man sie von Anfang an berücksichtigt, noch einiges an Arbeit erfordern. Da würde ich dann doch schon zweimal nachdenken, ob es mir das wert ist.

[Alexander Kornrumpf]

Vor 20 Jahren (oh shit!) war das hier der Goldstandard: https://gafferongames.com/post/fix_your_timestep/

[Schrompf]

Aber selbst mit fixem Timestep gibt's Probleme. Ich halte es eigentlich für unmöglich, aber in Crossfire 1/2 vor >20 Jahren hatten wir festen Zeitschritt und Zufall nur aus ner Tabelle und alles... und trotzdem sind manchmal nach ein paar Minuten die Replays aus der Sync gelaufen, und wir haben nie herausgefunden, warum.

[Krishty]

Vor 20 Jahren (oh shit!) war das hier der Goldstandard: https://gafferongames.com/post/fix_your_timestep/

+1

Das bedingt natürlich, dass die ganze Spiellogik tatsächlich deterministisch ist, inklusive Ungenauigkeiten bei float-Berechnungen. Könnte ja vlt. bei unterschiedlichen CPUs, oder auch wenn sich mal ein Kompilerflag ändert, dann leicht unterschiedliche Ergebnisse bedeuten, die sich schnell aufschaukeln. Also muss alles auf Int basieren, die dann garantiert immer gleich gerechnet werden?

1. float alias IEEE 754 ist deterministisch.
2. Alle CPUs, die du aktuell kaufen kannst, unterstützen IEEE 754. Alle Mainstream-Compiler ebenfalls.
3. Wer seine Programme mit Fast Math kompiliert, gibt alle Determinismus-Garantien explizit auf und ist selber schuld, wenn er keine deterministischen Berechnungen mehr hat. Das sind nicht „die ungenauen floats“ oder „Compiler“.

Die einzigen Gleitkommaberechnungen, die mir bisher jemand zeigen konnte und die nicht perfekt zwischen CPUs und Compilern portabel sind:

• Overflow-/Underflow-/Rounding-Flags der CPU ändern. Ist inhärent CPU-Abhängig. Berühmterweise tat das Direct3D vor 25 Jahren, wenn Software Transform & Lighting aktiviert war. Ebenso berühmt ist, dass C# das nach jedem Aufruf von nicht-.NET-Code zurücksetzt um Entwicklern die Fehlersuche zu sparen.
• Signalling und Non-Signalling NaNs mischen.

Ansonsten verhält sich jeder float-basierte Code mit Clang/GCC/MSVC auf allen Major Platforms inklusive ARM identisch.

[joeydee]

Du weißt schon, wie das technisch funktionieren soll?

Speziell für diesen Fall: Ja.
Ghost-Replay bei Rennspielen würde ich jetzt über Zustands-Keyframes mit Timecode aufzeichnen und interpoliert abspielen. Hier will ich ja nur den Vergleich zu meiner aktuellen Fahrt, kein komplett simuliertes Replay wo der Ghost die Umgebung beeinflusst.

[TomasRiker]

[*]Wer seine Programme mit Fast Math kompiliert, gibt alle Determinismus-Garantien explizit auf und ist selber schuld, wenn er keine deterministischen Berechnungen mehr hat. Das sind nicht „die ungenauen floats“ oder „Compiler“.

Mag sein, aber wenn du z. B. Unity und dessen Physik-Engine benutzt, dann hast du keinen Einfluss darauf, da Fremdsoftware.
Ich habe selbst mal versucht Unity-Physik deterministisch hinzukriegen. Mit viel Mühe habe ich es innerhalb von einer Plattform geschafft, aber plattformübergreifend war es ein aussichtsloses Unterfangen.

[Jonathan]

Hm, ja, ich folgere daraus mal, dass es tatsächlich nicht einfach ist.

Ich habe ehrlich gesagt keine Ahnung, ob ich z.B. Fast-Math aktiviert habe. Oder wie das in all meinen Abhängigkeiten aussieht. Oder welche Flags wo und wann aktiviert sind und von welcher Abhängigkeit. Oder wann für irgendwas ein Bugfix kommt, weil versehentlich ein Flag umgeschaltet wurde und jetzt in der neuen Version wieder zurückgesetzt wird. D.h. das erstmal alles herausfinden und bei jedem Update von irgendwas alle Patch-Notes lesen um herauszufinden ob sich diesbezüglich irgendetwas geändert hat. Klingt entweder aufwändig, oder fehleranfällig. Vielleicht bin ich aber auch einfach ein schlechter Entwickler, weil ich dafür keine Unit-Tests habe, die mich sofort warnen würden. Wer weiß. Jedenfalls scheint man sich auf Determinismus ohne zusätzliche Arbeit doch nicht so verlassen zu können.

Vor 20 Jahren (oh shit!) war das hier der Goldstandard: https://gafferongames.com/post/fix_your_timestep/

Hm, ja, größenteils das, was ich mir dachte. Die Frage ist letztendlich, ob es mir reicht, wenn die Spiellogik mit konstanter Geschwindigkeit läuft, oder ob es eben auch flüssig aussehen soll.

VSYNC ist eine guter Punkt, den hatte ich oben aus den Augen verloren. Eigentlich ist damit alles ganz einfach, weil man halt eine konstante Framerate hat. Außer, man dreht die Details hoch und gerät damit alle paar Frames knapp über die Frametime (und man kann ja fast immer Rechenzeit für bessere Grafik eintauschen, weshalb sollte man sie also einfach verschenken?), wodurch die Framerate augenblicklich z.B. von 60 auf 30 reduziert wird, weil man halt nur zu genau definierten Zeitpunkten updaten kann (und dann wird vielleicht jeder dritte Frame doppelt so lange angezeigt, was auch wieder nicht gut aussieht). Aber dafür gibt es heute ja GSync und FreeSync, was theoretisch sehr weiche Animationen ermöglicht, aber dann ist halt die Framerate wieder komplett variabel. Eine wirkliche Lösung für irgendetwas ist VSync damit eigentlich nicht mehr.

Und dann ist halt die große Entscheidung, ob es einem reicht, den letzten Spielzustand anzuzeigen, oder ob man zwischen Frames interpolieren will. Dann muss man aber durch die gesamte Spiellogik hindurch zwischen Spielzustand und Renderzustand unterscheiden. Ein Objekt kann dann nicht mehr mit seiner aktuellen Position aus der Spiellogik gerendert werden, sondern es muss eine extra Renderposition berechnet werden. Das einfachste ist vermutlich wirklich lineare Interpolation, aber dann braucht man auch mindestens mal alle Variablen doppelt und muss auch immer einen extra Update-Schritt machen, und irgendwo zwischenspeichern. Für alles, was irgendwo irgendwie angezeigt wird. Klingt super nervig.

Ich denke, ich bleibe erstmal bei meinem System. Aktuell habe ich variable Framerate mit einer maximalen Frametime von 1/10, damit nichts explodiert. Trivial und robust, vermutlich will ich auch irgendwann nochmal eine minimale Frametime einbauen, aber das sind auch nur 5 Zeilen mehr. Nicht alle Berechnungen werden damit super genau sein, wenn man 5 mal für 30 Sekunden geradeaus läuft, kommt man vermutlich immer auf einer anderen Position raus. Andererseits zählt der Spieler ja nicht mit, wie viele Sekunden er schon nach vorne läuft, sondern entscheidet anhand des letzten Frames, ob er jetzt die Taste loslassen soll oder nicht. Es gibt ein paar Ausnahmen, wie sich Fehler schon aufaddieren könnten, beispielsweise eine Plattform die 5 Sekunden nach links und dann wieder 5 Sekunden nach rechts fährt, das ganze Level lang. Die könnte irgendwann an der falschen Position landen. Allerdings kann man das auch leicht anders implementieren, indem man z.B. Start- und Endposition definiert und dazwischen interpoliert. Dann bleibt die Plattform immer im richtigen Gebiet und kann höchstens noch etwas zu spät oder zu früh irgendwo sein, was wichtig sein könnte, wenn verschiedene Spielelemente immer synchron bleiben müssen, aber auch das kann man als Spezialfall behandeln und dann recht leicht robust lösen. Fast immer wird man das aber nicht brauchen...