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: 8261
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: 204
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: 8261
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: 2380
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: 4261
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: 8261
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: 578
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: 8261
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: Gestern, 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: 8261
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
Antworten