Showroom - Aktuelle Arbeiten und Projekte

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

TomasRiker hat geschrieben: 13.05.2024, 10:42Ich 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.
Respekt, dass es auf einer ganzen Plattform lief! Ich höre ständig Gerüchte darüber, dass es „höchstens auf dem selben System“ reproduzierbar wäre, wie etwa in diesem grottenschlechten Artikel. Spieleentwickler müssen sich natürlich an die Trennung von Update() und FixedUpdate() halten, aber welche Probleme Unity intern hat, weiß ich nicht. Falls es dazu Entwicklerkommentare gibt, würde ich die gern lesen 👀

————
Alexander Kornrumpf hat geschrieben: 13.05.2024, 07:40Vor 20 Jahren (oh shit!) war das hier der Goldstandard: https://gafferongames.com/post/fix_your_timestep/
Upps – ich vergaß, dass mir aus (zu recht!) dieses Video ans Herz gelegt worden war:


————
Jonathan hat geschrieben: 13.05.2024, 14:01Hm, 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.
Ich lese „Ich habe keine Ahnung, was meine Software tut. Deshalb ist es nicht einfach, Software zu entwickeln, die tut, was man möchte.“

Man kann mit nicht-deterministischer Physik weit kommen; hängt halt vom Anwendungsfall ab. Deterministische Physik ist aber keinesfalls unmöglich. Half-Life, Quake – die waren alle deterministisch (siehe Demos/Replays im DEM-Format). Die Engine spielt einfach einen Strom Ereignisse ab; egal, ob die aus der lokalen GUI oder von einem Server kommen. Muss aber in Vergessenheit geraten sein, denn so etwas wird heute ja mitunter als Errungenschaft von Entity-Component-Systemen verkauft.
Jonathan hat geschrieben: 13.05.2024, 14:01Vielleicht bin ich aber auch einfach ein schlechter Entwickler, weil ich dafür keine Unit-Tests habe
Replays von deterministischer Physik eignen sich übrigens perfekt als Tests. Du kannst ziemlich hohe Testabdeckung erreichen, indem du literally für ein paar Sekunden die Record-Taste hälst, nach jedem Build ein Replay laufen lässt, und schließlich prüfst, ob die Objektpositionen die selben sind 🤷
VSYNC ist eine guter Punkt
Ich gehe nicht auf die Details ein, weil die sich bisher immer als irrelevant herausgestellt haben. Du lässt deine Simulation natürlich nicht mit VSync-Frequenz laufen, sondern mit einer festen Frequenz, die höher ist – optimalerweise der GGT beliebter Frame-Intervalle. Ich nutze gerade 144 Hz; früher mal 240. Autorennspiele laufen intern gern mit 200–1000 Hz (Wikipedia hatte dazu mal eine tolle Tabelle). Interpolieren/Extrapolieren kann man, aber ich habe noch nicht gehört, dass sich jemand wirklich dazu gezwungen sah – außer Soapy in ReDRIVER2, dessen Physik mit 50 Hz lief (weil PlayStation 1!) und das auf 60-Hz-Bildschirmen leicht unrund aussah. Wenn du mit 120 Hz rechnest, wird das auch ohne Interpolation auf jedem gängigen Monitor (60 Hz, 80 Hz, 120 Hz) flüssig aussehen.
Ein Objekt kann dann nicht mehr mit seiner aktuellen Position aus der Spiellogik gerendert werden, sondern es muss eine extra Renderposition berechnet werden. […] 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.
Ja; zwei/drei Implementierungen, die mir bekannt sind, speichern bei VSync einen Snapshot der aktuellen Szene. Ist durchaus nervig, beschwert mitunter aber auch Synergieeffekte mit Dingen wie Multi-Threaded Rendering.

Ich selber tue das übrigens nicht. Ich unterbreche die Physik-Berechnung, sobald ein Frame angezeigt werden muss, und hole nach dem Rendern wieder auf. Fühlt sich ein wenig schmutzig an; ändere ich wahrscheinlich, sobald ich Multiplayer realisieren muss.

Ich möchte niemandem was vorschreiben und labere hier nur, weil ich das Thema gern diskutiere. Gute Spiele kann man mit Determinismus bauen oder ohne. Aber Aussagen wie, Floats wären grundsätzlich ungenau oder man könnte sie nicht über Plattformen hinweg konsistent nutzen, kann ich nicht stehen lassen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
smurfer
Establishment
Beiträge: 207
Registriert: 25.02.2002, 14:55

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von smurfer »

Autorennspiele laufen intern gern mit 200–1000 Hz (Wikipedia hatte dazu mal eine tolle Tabelle)
Die fand ich auch klasse, war aber meine ich nur ein Subset der Tabelle aus dem LFS-Forum, deren Eintrag von 2008 auch noch 2023 aktualisiert wurde. Daher der Vollständigkeit halber: https://www.lfs.net/forum/thread/48927- ... acing-sims
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

smurfer hat geschrieben: 13.05.2024, 19:27Die fand ich auch klasse, war aber meine ich nur ein Subset der Tabelle aus dem LFS-Forum, deren Eintrag von 2008 auch noch 2023 aktualisiert wurde. Daher der Vollständigkeit halber: https://www.lfs.net/forum/thread/48927- ... acing-sims
Sehr geil; vielen Dank 🙏
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Jonathan
Establishment
Beiträge: 2388
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Jonathan »

Krishty hat geschrieben: 13.05.2024, 17:38Ich lese „Ich habe keine Ahnung, was meine Software tut. Deshalb ist es nicht einfach, Software zu entwickeln, die tut, was man möchte.“
Naja, kann man so oder so sehen. Du kannst das so lesen, wenn du das möchtest, und hast dann damit auch nicht unbedingt unrecht. Aber ich würde es eher so formulieren: Man kann fast beliebig weit in die Komplexität absteigen, aber in der Regel entscheide ich mich dafür, Dinge nicht wesentlich besser zu verstehen, als ich muss, um mehr Zeit für anderes zu haben. Ich guck mir z.B. nie den kompilierten Maschinencode an, weil das für meine Zwecke Zeitverschwendung ist. Die Überwiegende Mehrheit der Compilerflags stehen auf Standardeinstellungen, weil die halt tun und das pragmatisch ist. Und konkret zu deterministischer Physik ist das Problem weniger, dass es intellektuell schwierig ist, sondern eher, das es zeitlich aufwändig ist (wobei man philosophisch fragen kann, ob das überhaupt jemals ein Unterschied ist ;) ). Ich muss mir eine Liste an Dingen die schief gehen können zusammenstellen, gucken wie sich mein Code diesbezüglich verhält, und gucken wie sich der Code aller Abhängigkeiten diesbezüglich verhält. Und sicherstellen, dass sich das nicht ändert. Und dieser Zeitaufwand muss mir der erwartete Mehrwert wert sein.

Ich hatte übrigens mal das nette Problem, dass GLM all seine Standardkonstruktoren von "mit 0 initialisieren" auf "gar nicht initialisieren" geändert hat, wegen Performance. Das hat mich mehrere Tage gekostet, alle Stellen in meinem Spiel zu finden, wo meine Variablen jetzt uninitialisiert sind. Ich hätte die neue GLM Version zu dem Zeitpunkt nicht gebraucht, wollte aber mit der Zeit gehen und auf die aktuelle Version umsteigen. Spaß hatte ich damit nicht. Seit dem bin ich etwas vorgeschädigt, weil breaking changes in Abhängigkeiten angeht^^.
Replays von deterministischer Physik eignen sich übrigens perfekt als Tests. Du kannst ziemlich hohe Testabdeckung erreichen, indem du literally für ein paar Sekunden die Record-Taste hälst, nach jedem Build ein Replay laufen lässt, und schließlich prüfst, ob die Objektpositionen die selben sind 🤷
Hmmm, ich bin mir wirklich nicht sicher, wie viele Fehler ich in meinem Spiel realistisch durch Unit-Tests jemals hätte finden können. Das Problem ist, dass die allermeisten Änderungen am Code auch das erwartete Ergebnis ändern und damit alle Tests ungültig werden. Und dass ich an einer Stelle A etwas ändere, und dadurch an einer Stelle B, die für etwas komplett unterschiedliches da ist, und deren Unit-Test demnach weiterhin durchlaufen sollte, etwas durch unbewusste Abhängigkeiten kaputt geht, passiert mir extrem selten. Daher habe ich jedesmal wenn ich darüber nachgedacht habe, mich gegen Unit-Tests entschieden.
aber ich habe noch nicht gehört, dass sich jemand wirklich dazu gezwungen sah – außer Soapy in ReDRIVER2, dessen Physik mit 50 Hz lief (weil PlayStation 1!) und das auf 60-Hz-Bildschirmen leicht unrund aussah.
Ja, bin mir auch wirklich nicht sicher, ob ich wirklich darauf beharren würde (daher die "Und dann ist halt die große Entscheidung, ob es einem reicht, den letzten Spielzustand anzuzeigen, oder ob man zwischen Frames interpolieren will." - Formulierung), aber es war halt ein großer Punkt der mir eingefallen ist, der einem kaputt geht, wenn man auf eine feste Framerate umsteigt. Man könnte das natürlich einfach mit 10 Zeilen in der Hauptschleife schnell mal ausprobieren und vergleichen, vielleicht mache ich das ja mal. Insbesondere wenn man die Schrittweite verringert, also sich nicht 1 und 2 Logik Updates zwischen dem Rendern abwechseln, sondern z.B. 9 und 10 merkt man das bei 60 FPS vielleicht wirklich einfach gar nicht mehr. Wobei eine größere Anzahl Update-Schritte natürlich auch entsprechend mehr kostet. Hmmmm.

Mir fällt noch auf, dass mein Beispiel mit den Plattformen nichts mit der Framerate zu tun hat - Fehler können sich ja auch bei festen Zeitschritten genau so aufaddieren. Der einzige Unterschied scheint mir zu sein, ob sie sich deterministisch aufaddieren, oder nicht.

Für Harald wären Replays schon eine nette Sache gewesen. Wenn man das Frame-Interpolieren weglässt, würden sich die Änderungen ja sogar in Grenzen halten. Man könnte sogar auf Unterschiede zwischen CPU-Flags pfeifen, es reicht ja theoretisch, wenn das einmal kompilierte Programm auf jedem Rechner gleich läuft, in neuen Versionen könnte sich ja auch die Spiellogik ändern, dann sind die Replays eh pfutsch.
So gesehen, könnte man das wirklich mit einer handvoll Zeilen umstellen. Aber letztendlich hätte man die Replays ja auch mit der Online-Highscore über den Server schicken müssen, einen Abspielmodus einbauen müssen, und und und. Ich hab lange genug für das Spiel gebraucht, es war Zeit für neue Projekte. Nunja, vielleicht in der Zukunft.
Ich möchte niemandem was vorschreiben und labere hier nur, weil ich das Thema gern diskutiere. Gute Spiele kann man mit Determinismus bauen oder ohne. Aber Aussagen wie, Floats wären grundsätzlich ungenau oder man könnte sie nicht über Plattformen hinweg konsistent nutzen, kann ich nicht stehen lassen.
Joah, ich hab das Thema ja auch nochmal ausführlicher angesprochen, weil ich darüber diskutieren wollte. Ich hab beim Lesen und darüber Nachdenken jetzt jedenfalls ein besseres Bild davon bekommen, was die Vor- und Nachteile sind. Hat sich daher für mich schon gelohnt.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4262
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Chromanoid »

TomasRiker hat geschrieben: 13.05.2024, 10:42
Krishty hat geschrieben: 13.05.2024, 08:42 [*]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.
Für unity3d habe ich irgendwann mal kurz das hier versucht:
https://github.com/Kimbatt/unity-deterministic-physics

Die Lösung ist da floating point Operationen selbst zu implementieren und das "neue" DOTS Zeug zu modifizieren... Kommentar des Entwicklers: https://www.reddit.com/r/Unity3D/commen ... t/gnmb24y/

Quake nutzt wie ich das verstehe fixed point Q16.16.

Alles irgendwie schrecklich, Probleme die man glaubt hinter sich zu haben. https://gafferongames.com/post/floating ... terminism/ Kann man bei allen relevanten c/cpp compilern die zusätzlichen Optimierungen, die zu Abweichungen führen ausstellen? Ab Java 17 ist das ja standard und vorher gab's strictfp (auch lustig https://stackoverflow.com/questions/366 ... nt-systems). komisch, dass die CLR das nicht hat?!

Naja, aber so wie ich das verstehe, ist cross device play meist auch rechtlich ein Problem (edit: mmh, dann müsste diese Liste aber kleiner sein https://en.m.wikipedia.org/wiki/List_of ... tform_play). Wenigstens für Aufnahmen wäre es natürlich schön...
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Chromanoid hat geschrieben: 13.05.2024, 22:51Alles irgendwie schrecklich, Probleme die man glaubt hinter sich zu haben. https://gafferongames.com/post/floating ... terminism/
Danke für die Link-Liste; auf diesen fantastischen Artikel hatte auch schon Unity verwiesen. Er zählt drei Probleme auf:
  1. Compiler-Bugs in IEEE754-Optimierungen;
  2. Hardware-optimierte Gleitkommabefehle;
  3. ganz speziell die x86-FPU.
Punkt 3. ist tot und durch SSE2 ersetzt worden. Heute bekommt man es ohne große Umwege gar nicht mehr hin, dass GCC/MSVC x86-FPU-Code emittieren.

Punkt 1 hat sich enorm verbessert, und das ist wohl hauptsächlich dem Aufkommen von Clang in den 00ern zu verdanken; außerdem großen portablen Projekten wie Google Chrome (ursprünglich GCC, dann für Windows auf MSVC portiert, dann weiter zu Clang).

Punkt 2 erfordert Feingefühl. Die 2008er Revision von IEEE754 hat Reproduzierbarkeit eingefordert. 1.+3. haben dafür gesorgt, dass sich die C-Laufzeitbibliotheken angleichen und Implementierungen bspw. von sin() auf allen großen Plattformen den gleichen Genauigkeits- und Verhaltensstandards entsprechen.

Dummerweise sind aber auch spezielle CPU-Befehle populär geworden (FJCVTZS auf ARM, zahllose SSE-Befehle auf x86), die teils IEEE754 nicht voll implementieren. Und GPUs sowieso nicht. Und da muss man wirklich aufpassen, ob der schnellere CPU-Befehl für 32-Bit Quadratwurzeln einem nicht die Portabilität kaputtmacht … deshalb hat es ja auch ewig gedauert, bis wir auf x86 ein Multiply-Add bekommen haben.

Dazu aus dem Artikel:
Interestingly, SSE with its support for SIMD FP commands actually can make things worse in the standard-violating-algebraic-optimizations department. Specifically, Intel's compiler reportedly has (had?) an optimization which unrolls FP accumulation loops and reorders additions in order to utilize SIMD FP commands (gcc 4 does that, too, but only if you explicitly ask for trouble with -funsafe-math-optimizations or similar). But I wouldn't conclude anything from it, except that automatic vectorization, which is known to work only on the simplest of code snippets, actually doesn't work even on them.
Der Burn war so sick, dass ich nach Stunden immernoch drüber lache 🤣

Also ja: Portable Gleitkommazahlberechnungen auf x86 waren bis ca. 2010 ein Martyrium. Das ist nun 14 Jahre her. Es ist wirklich viel, viel besser geworden.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 583
Registriert: 05.07.2003, 11:17

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Lord Delvin »

Krishty hat geschrieben: 13.05.2024, 17:38 Ich selber tue das übrigens nicht. Ich unterbreche die Physik-Berechnung, sobald ein Frame angezeigt werden muss, und hole nach dem Rendern wieder auf. Fühlt sich ein wenig schmutzig an; ändere ich wahrscheinlich, sobald ich Multiplayer realisieren muss.

Ich möchte niemandem was vorschreiben und labere hier nur, weil ich das Thema gern diskutiere. Gute Spiele kann man mit Determinismus bauen oder ohne. Aber Aussagen wie, Floats wären grundsätzlich ungenau oder man könnte sie nicht über Plattformen hinweg konsistent nutzen, kann ich nicht stehen lassen.
Habe letztens in anderem Kontext einen Vortrag zum Thema deterministische Berechnungen, Modularisierung, Tests gehalten und bin glaube nicht durchgedrungen. Nur fragende Gesichter und kaum Gegenfragen.
Jonathan hat geschrieben: 13.05.2024, 21:54
Replays von deterministischer Physik eignen sich übrigens perfekt als Tests. Du kannst ziemlich hohe Testabdeckung erreichen, indem du literally für ein paar Sekunden die Record-Taste hälst, nach jedem Build ein Replay laufen lässt, und schließlich prüfst, ob die Objektpositionen die selben sind 🤷
Hmmm, ich bin mir wirklich nicht sicher, wie viele Fehler ich in meinem Spiel realistisch durch Unit-Tests jemals hätte finden können. Das Problem ist, dass die allermeisten Änderungen am Code auch das erwartete Ergebnis ändern und damit alle Tests ungültig werden. Und dass ich an einer Stelle A etwas ändere, und dadurch an einer Stelle B, die für etwas komplett unterschiedliches da ist, und deren Unit-Test demnach weiterhin durchlaufen sollte, etwas durch unbewusste Abhängigkeiten kaputt geht, passiert mir extrem selten. Daher habe ich jedesmal wenn ich darüber nachgedacht habe, mich gegen Unit-Tests entschieden.
Das ist jetzt wirklich nicht böse gemeint, aber: Weil du halt nie irgendwas wirklich kompliziertes gemacht hast und Spaß hast rumzubasteln.
Wenn man ein größeres Projekt bauen möchte, dann muss man an den Punkt kommen, an dem man Themen abschließen und vergessen kann.
Das schaffst du anders nicht. Und wenn man dann irgendwann gezwungen ist, irgendwelche fundamentalen Änderungen zu machen, dann will man wissen wo es Probleme gibt.

Der zweite Punkt ist, dass du bei deterministischen Tests auch beliebig oft eine Debugsession auf demselben Test starten kannst und immer wieder in dieselbe Situation kommst.
Das brauchst du insbesondere dann, wenn dir nicht klar ist, wo du was wissen musst und immer wieder feststellst, dass du zu weit gesteppt bist oder eigentlich an ganz anderer Stelle schauen musst, was eigentlich passiert.

In Tyr sind selbst die Objektallokationen bei gleichem Input deterministisch. Wenn ich das nicht hätte wäre ich auch mit einem Zehnmannteam und in Vollzeit nicht so weit gekommen wie ich jetzt bin. Es bringt ja nichts, wenn irgendwas nicht so ist wie man will, das irgendwie gerade zu biegen und dann ist was anderes nicht so wie man will und man hat keine Ahnung warum. Wenn man lange genug spannende Projekte baut, dann kann man die auch nicht mehr überblicken.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Lord Delvin hat geschrieben: 18.05.2024, 12:29In Tyr sind selbst die Objektallokationen bei gleichem Input deterministisch. Wenn ich das nicht hätte wäre ich auch mit einem Zehnmannteam und in Vollzeit nicht so weit gekommen wie ich jetzt bin. Es bringt ja nichts, wenn irgendwas nicht so ist wie man will, das irgendwie gerade zu biegen und dann ist was anderes nicht so wie man will und man hat keine Ahnung warum. Wenn man lange genug spannende Projekte baut, dann kann man die auch nicht mehr überblicken.
Fun fact: Irgendeine Bibliothek musste mal gepatcht werden, weil deterministische Hash Tables eine Sicherheitslücke darstellen. Wenn der Angreifer dein Hashing kennt, kann er Anfragen geziehlt so auswählen, dass dein O(1)-Zugriff in die Hash Table zu O(n) wird, was je nach Verwendung direkt zu DoS führen kann. Sie mussten einen Zufallszahlengenerator verwenden.

Will nicht bewerten, ob das gut oder schlecht war, aber kam mir bei totalem Determinismus in den Sinn.

Deterministische Heaps möchte man ja auch tunlichst vermeiden, damit Angreifer nicht die Adressen wichtiger Datenstrukturen raten können.

Aber meine Debug-Builds mag ich tatsächlich auch so deterministisch wie möglich.

Edit: Betroffen war 2011 die .NET-Runtime, Tomcat, JRuby, und mehr; Google spuckt aus, dass das ständig in allen möglichen Sprachen und Bibliotheken wiederentdeckt wird.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
EyDu
Establishment
Beiträge: 101
Registriert: 24.08.2002, 18:52
Wohnort: Berlin
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von EyDu »

Krishty hat geschrieben: 20.05.2024, 23:51 Fun fact: Irgendeine Bibliothek musste mal gepatcht werden, weil deterministische Hash Tables eine Sicherheitslücke darstellen. Wenn der Angreifer dein Hashing kennt, kann er Anfragen geziehlt so auswählen, dass dein O(1)-Zugriff in die Hash Table zu O(n) wird, was je nach Verwendung direkt zu DoS führen kann. Sie mussten einen Zufallszahlengenerator verwenden.
Ja, das zog sich quer durch sehr viele Systeme. Eine schöne Übersicht gibt es hier: https://ocert.org/advisories/ocert-2011-003.html.

Besonders stark betroffen war fast alles, was auf Python basiert, da dort jeder Attribut-Zugriff über Hashmaps erfolgt.
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Hier übrigens ein Aufsatz über die Frage nach deterministischem Lerp, die im Video oben offen gelassen wurde: https://blog.pkh.me/p/41-fixing-the-ite ... games.html
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Lord Delvin
Establishment
Beiträge: 583
Registriert: 05.07.2003, 11:17

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Lord Delvin »

Krishty hat geschrieben: 20.05.2024, 23:51
Lord Delvin hat geschrieben: 18.05.2024, 12:29...
Fun fact: Irgendeine Bibliothek musste mal gepatcht werden, weil deterministische Hash Tables eine Sicherheitslücke darstellen. Wenn der Angreifer dein Hashing kennt, kann er Anfragen geziehlt so auswählen, dass dein O(1)-Zugriff in die Hash Table zu O(n) wird, was je nach Verwendung direkt zu DoS führen kann. Sie mussten einen Zufallszahlengenerator verwenden.

Will nicht bewerten, ob das gut oder schlecht war, aber kam mir bei totalem Determinismus in den Sinn.

Deterministische Heaps möchte man ja auch tunlichst vermeiden, damit Angreifer nicht die Adressen wichtiger Datenstrukturen raten können.
Das ist sicher eine erwähnenswerte Reaktion ;)

Mein Ansatz ist weder HashMaps noch Zeiger*werten* zu erlauben die Ausführung zu beeinflussen. In dem Fall geht das relativ einfach mit etwas Disziplin. Wenn Algorithmen von Maps und Sets beeinflusst werden würden wäre das vielleicht nicht durchzuhalten. Timing gibt's bei mir natürlich einfach nicht.
XML/JSON/EMF in schnell: OGSS
Keine Lust mehr auf C++? Versuche Tyr: Get & Get started
Benutzeravatar
Schrompf
Moderator
Beiträge: 4876
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Splatter. Auf Koreanisch.
screenshot0007.png
Ich hab tatsächlich noch paar Bugs gefunden und gefixt. Plus Framerate-Begrenzung und ner verbesserten Goldenen Pistole. Einige Spieler*innen hatten sich ja (zu Recht) beschwert, dass die Pistole, wenn man sie mal komplett hat, nix besser macht als die Voll Ausgebaute Pistole. Zu Recht, war halt damals die Zeit alle. Und jetzt hab ich einfach nen zusätzlichen Codepfad eingebaut, so dass sie jetzt in Gold noch bissl heftiger rattert. 10 Jahre nach Release.

Einer der Bugs war so alt wie die C++-Menschheit:

Code: Alles auswählen

assert( ptr != null );
if( ptr != null ) return dummy;
Hat ne Weile funktioniert, im Debug assert und im Release zumindest kein Crash. Dann aber habe ich vor x Jahren mein assert() umgebaut, dass es im Release-Build zu einem assume( !condition ); wird. Bringt was an Performance zum Beispiel in großen Schleifen:

Code: Alles auswählen

assert( (loopcount % 8) == 0 );
for( size_t a = 0; a < loopcount; ++a )
Dann unrollt der Compiler die Schleife partiell und macht immer 8 Aktionen auf einmal, was selbst ohne Autovektorisierung bissl was bringen kann. Aber damit hab ich halt auch aus Versehen meine Not-Aus-Schalter rausoptimiert und mir ein paar Zugriffe auf ungültige Iteratoren eingetreten.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Krishty »

Niiiice! Die Pistole muss ich mal ausprobieren.

Interessant mit __assume() und for.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
smurfer
Establishment
Beiträge: 207
Registriert: 25.02.2002, 14:55

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von smurfer »

Hallo zusammen,

ich hatte ja schon ein paar Posts weiter vorne von meinem kleinen Raumschiff-Emitter-Experiment berichtet. Die Daten für das Raumschiff (Form, Emitter-Parameter, etc.) wollte ich komfortabler "malen", wobei mir diverse Blender-Exporte oder svg einfach zu umfassend dafür sind. Da ich auch gerne so grundlegende Dinge aus Spaß an der Freude selbst mache und es meinem Lernprozess in Zig nur hilft, habe ich mich für -- nicht hauen ;-) -- XFig entschieden. Das kenne ich, es wird immer noch unterstützt, das Textformat ist simpel (bis auf die Farbpalette und die Logik dahinter), unterstützt Ebenen und es ist sehr gut für meine Zwecke geeignet.

Hier mal ein Vergleich XFig zu Spiel (alles nur ein Testobjekt):
xfig_ship_01.png
Ein Aspekt, der die Entscheidung zu XFig unterstützt hat, ist, dass sehr einfach Kommentare an Objekte (Shapes) geheftet werden können. Geht bestimmt auch bei Inkscape und Blender, aber wie gesagt, XFig war einfach direkt und simpel.
Als Test habe ich Kreise für die Emitter verwendet, die Position ist durch das Kreiszentrum beschrieben, der Emittertyp als ID und die Ausrichtung (in Grad) im Kommentar. Die restlichen Parameter sind in json hinterlegt, mit der Emittertyp-ID als Referenz.
xfig_ship_02.png
Sicher nicht die beste Lösung, aber für ein paar wenige Abende Rumprobieren war es aus meiner Sicht keine verschwendete Energie, auch wenn ich irgendwann in Zukunft evtl. das Format/Tool wechseln muss oder möchte.

Beste Grüße
kristof
Beiträge: 92
Registriert: 19.01.2009, 13:05

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von kristof »

Ich bastele gerade an einem kleinen Node Editor Feature. Bisher ist es nur eine Spielerei. Aber ich stelle mir vor es zum darstellen vom Datenfluss zwischen Systemen in meiner Game Loop zu verwenden. Vielleicht auch zum Zusammenstöpseln von Materials oder Soundeffekten...
nodes.gif
(anklicken für ein bewegtes GIF)

Technisch ist es auch ganz interessant, da ich hier C++ nach WebAssembly kompiliere und daraus das HTML DOM manipuliere. Natürlich durch einen dünnen JavaScript Layer. Seitdem WebAssembly External Reference Types unterstützt, ist das plötzlich sehr viel schmerzfreier geworden.
Benutzeravatar
woodsmoke
Beiträge: 46
Registriert: 30.06.2023, 14:05
Wohnort: Ludwigshafen
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von woodsmoke »

Bild

Navpoint Beta (Titelbild und Highscore Bild)

Bild
smurfer
Establishment
Beiträge: 207
Registriert: 25.02.2002, 14:55

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von smurfer »

Nachdem nun XFig recht gut als Modelling-Tool hergehalten hat und ich dort auch in einem extra Layer die Kollisionsgeometrie zeichnen kann, ging es bei meinem Nicht-mehr-nur-Emitter-Experiment an die Kollisionsabfrage. Erstmal bin ich einfach rangegangen: Bounding-Boxen und im überlappenden Fall Linienschnitt.
Für die Kollisionstests (bzw. um zu Testen, ob die generelle Architektur mit visuellen zum einen und Kollsionsgeometrien zum anderen funktioniert) habe ich ganz rudimentär ein paar 100 Asteroiden generiert -- nicht schön, aber zweckdienlich.
Hier zwei Bilder zur Kollision:
01.png
02.png
Als nächstes folgt die "Response". Newton'sche Physik und das Reagieren auf Kräfte/Momente (Translation Schwerpunkt, Rotation um den Schwerpunkt auf Basis der angreifenden Kräfte) ist bereits implementiert, ein einfaches Penalty-based-Verfahren sollte also für's Erste schon reichen und Ergebnisse zeigen.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4876
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Ja cool! Ne simple Physik reicht im 2D-Weltraum sicher aus, wenn die Kollisionsprüfung nur zuverlässig und genau ist. Und das hast Du anscheinend erreicht. Gute Arbeit!
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Antworten