News Helldivers 2: Installationsgröße „mal eben“ von 154 GB auf 23 GB reduziert

[Kuristina]

Denn die Kopien sind dann immer noch andere Dateien.

Aber die Kopien müssen doch nicht zwangsläufig alles eigene, andere Dateien sein. Ich kann die Landschaft von Level 3 und die Grafiken der Gegner von Level 3 in der level3 Datei haben. Und die Landschaft von Level 8 mit den gleichen Grafiken der Gegner aus Level 3 auch noch mal in der level8 Datei haben. Dann muss der Lesekopf nicht zu einer zweiten Datei springen, weil die Kopie der Gegner schon in der level8 Datei mit enthalten ist.

 

[Atkatla]

@Kuristina Wenn die Anwendung vom Filesystem die Datei level3 anfordert, geht der Lesekopf dorthin, wo die Blöcke von Datei level3 liegen. Und wenn du Datei level8 anforderst, geht er dorthin, wo die Daten von Datei level8 liegen.

Er geht nicht bei einer Anforderung von Level3 zu der Level8 Datei, weil die "näher liegt" und eventuell den gleichen Inhalt haben könnte. Denn der Lesekopf weiss davon nichts. Und die Anwendung weiss wiederum nicht, wo genau ein Block liegt. Vereinfacht gesagt: die Anwendung greift auf Dateien zu. Die Dateien liegen im Filesystem an logischen Adressen. Die logischen Adressen liegen auf einem Datenträger an denjenigen Orten, die der Datenträgercontroller kennt. Anwendung und Filesystem wissen daher nicht, an welcher physischer Stelle genau die Bytes liegen. Denn das mappt der Controller des Datenträgers.

Wenn zwei Dateien den gleichen Inhalt haben und man optimieren will, dann dedupliziert man die und greift in beiden Fällen auf die gleiche Datei zu oder (wenn man es auf Storageebene macht wie bei Fileservern, mappt an unterschiedliche Dateien auf die gleichen physischen Storageblöcke.)

Wenn du wie in deinem Fall beschrieben, in der Datei level8 auch noch mal die Gegner von level3 platzierst, dann hast du nichts gewonnen in Bezug auf Zugriffszeit, denn auf welche der beiden Dateien zugegriffen wird, entscheidet sich nicht dadurch, wo sie in Bezug zu Lesekopf liegen (denn das wissen Anwendung und Filesystem nicht), sondern letztlich durch die Anwendung, die bestimmt, aus welcher der beiden Dateien gelesen wird, egal wo deren physischen Blöcke liegen.

 

[Kuristina]

Er geht nicht bei einer Anforderung von Level3 zu der Level8 Datei, weil die "näher liegt" und eventuell den gleichen Inhalt haben könnte.

Er geht zur level8 Datei, weil der Spieler nun mal in Level 8 ist. Die Landschaftsdaten von Level 8 braucht er auf jeden Fall. Und die Gegnerdaten nimmt er dann gleich mit, obwohl es die gleichen sind, wie in der level3 Datei.

Wenn zwei Dateien den gleichen Inhalt haben

Sie haben ja nur zum Teil den gleichen Inhalt. Sie sind nicht identisch.

 

[Atkatla]

Er geht zur level8 Datei, weil der Spieler nun mal in Level 8 ist. Die Landschaftsdaten von Level 8 braucht er auf jeden Fall. Und die Gegnerdaten nimmt er dann gleich mit, obwohl es die gleichen sind, wie in der level3 Datei.

Der Zugriff ist aber nicht schneller (wenn der Nutzer in Level 8 ist und die Gegnerdaten von Level 8 identisch sind zu Gegnerdaten von Level 3). Daten von Level 8 liegen nicht "näher" als die Daten von Level 3, wenn man in Level 8 ist. Wo sie physischen Blöcke liegen, weiss nur der Storagecontroller und nicht die Anwendung. Es kann sogar sein, dass der Lesekopf zu Zeitpunkt X sich weiterbewegen und länger warten muss um auf die Gegenerdaten-Level 8-Blöcke zu warten, als auf die von Level 3. Denn da die Blöcke einer einzelnen Datei nicht immer sequentiell angeordnet sind, gibt es kein "nimmt er gleich mit", da die Anordnung der Daten auf den Datenträgern nicht identisch mit der logischen Sortierung im Filesystem ist. Und mit Defragmentierungen konnte man nur Blöcke einer Datei zusamenhalten.

User Katzenjoghurt hat in Post #218 beschrieben, welche andere Ursache die unnötige Redundanz der Daten hat.

Das was du beschrieben hast, ist der Denkfehler, den Wolfgang evtl gehabt hat (oder der Entwickler, falls die wirklich an Leseköpfe gedacht haben.) Das was Katzenjoghurt und ich beschreiben haben (und auch einige andere vorher im Thread), ist der Grund, warum dieser Effekt aber nicht so funktionieren kann, wie man sich das erhofft hat.

 

[Siebenschläfer]

Denn da die Blöcke einer einzelnen Datei nicht immer sequentiell angeordnet sind

Mal den ganzen Faden lesen hilft. Dann fängt auf Seite 12 die Diskussion nicht wieder von vorne an.

 

[mibbio]

Wenn du wie in deinem Fall beschrieben, in der Datei level8 auch noch mal die Gegner von level3 platzierst, dann hast du nichts gewonnen in Bezug auf Zugriffszeit, denn auf welche der beiden Dateien zugegriffen wird, entscheidet sich nicht dadurch, wo sie in Bezug zu Lesekopf liegen (denn das wissen Anwendung und Filesystem nicht), sondern letztlich durch die Anwendung, die bestimmt, aus welcher der beiden Dateien gelesen wird, egal wo deren physischen Blöcke liegen.

Deswegen bestand die Optimierung mit der Duplizierung ja auch darin, dass man die Gegner-Assets nicht separat mehrmals abspeichert, sondern sie in die jeweiligen Leveldateien mit integriert. Die Assets der Gegner sind dann also einmal in der Containerdatei für Level 3 und einmal in der für Level 8.

Dadurch werden die Assets für den jeweiligen Level direkt in einem Rutsch mit dessen Containerdatei gelesen und der Lesekopf muss nicht erst von level3.dat oder level8.dat zu gegner.asset springen.

Je mehr Überschneidungen es bei der Verwendung der zig Asstes in den verschiedenen Leveln gibt, desto mehr bläht die Duplizierung den benötigten Speicherplatz des Spiels auf, weil das Assets in jeder Leveldatei gespeichert wird, die dieses Asset verwendet - bei hunderten bis tausenden Modellen, Texturen, Sounds läppert sich da ordentlich was an x-facher Speicherung derselben Daten (als Teil der Leveldateien) zusammen.

Genau diese Duplizierung wurde jetzt entfernt und die Texturen werden nicht jeweils direkt in den Leveldateien gespeichert, sondern in einer (oder) mehreren separaten Dateien, auf die dann alle Level gemeinsam zugreifen.

Das ist aber nicht so trivial änderbar, weil man ja die ganzen spielinternen Referenzen auf die Assetdaten ändern muss.

 

[Kuristina]

Daten von Level 8 liegen nicht "näher" als die Daten von Level 3, wenn man in Level 8 ist.

Es geht nicht darum, was beim ersten Zugriff näher liegt, sondern beim Weiterlesen dann. Die Daten von Level 8 musste man vorher ja nicht laden, weil sie nicht gebraucht wurden. Erst mit erreichen von Level 8 müssen diese geladen werden. Bei einer HDD die nicht arg fragmentiert ist, liegt eine einzelne Datei von Anfang bis Ende doch eher beieinander und braucht somit weniger Lesekopfbewegungen, als wenn man zwischen zwei verschiedenen Dateien hin und her springen muss. Sonst könnte man sich das ganze Defragmentieren ja auch sparen.

 

[aid0nex]

klingt für mich nach irgendwo zwischen "völlig faule Shotgun-Methode" und "faule Ausrede"

Gefühlt wird so aber nur noch entwickelt... Einfach alles mit Leistung zuscheißen. Optimierung ist nur Zeit- und Geldverschwendung für die Entwickler.

Ganz ehrlich, ich spiele regelmäßig Games die schon 8-10 Jahre alt sind und die sehen meist genauso gut aus wie die von heute, brauchen aber vielleicht ein Viertel der Leistung. Von Jahr zu Jahr steigen die Hardwareanforderungen, aber die Spiele werden nicht schöner oder besser. Es gibt teilweise Games die nicht mal auf einer RTX 5090 ohne DLSS flüssig laufen... Früher mussten Entwickler kreative Lösungen finden um ihre Vision überhaupt auf der Hardware der damaligen Zeit lauffähig zu bekommen. Heute haben die alle ein Luxusproblem.

Ergänzung (Donnerstag um 14:53)

Hab es schon immer vermutet das sowas passiert.

Erklärt für mich nun auch warum viele Games auf der Nintendo Switch (2) kleiner sind als auf anderen Konsolen. Nicht weil irgendwelche Hochauflösenden Texturen weg gespart werden, nein... Sondern weil eh jede Switch mit einer SSD kommt und die Entwickler hier Maßnahmen durchführen müssen weil die Konsole nicht so viel Speicherplatz bietet. Aber dafür halt SSD Speicher.

 

[-Quasi-]

Man packt alles was man im aktuellen Level braucht in eine Datei. Und was man in einem anderen Level braucht in eine andere Datei, die man dann halt lädt. Alles was sich im nächsten Level wiederholt, packt man dort als Duplikat nochmal rein.

Auf der FreeBSD-basierten Konsole liegt diese Datei dann innerhalb derselben Cylinder Group und es muss nicht ans Ende der Welt geseekt werden. (Aus demselben Grund liegen auch alle Dateien eines Unterverzeichnisses in derselben cgroup, es muss also nicht zwingend level1.wad sein.)

Klar, Windows ist damit überfordert und braucht defrag.exe, aber das ist ja nicht der Maßstab für effizienten Umgang mit Festplatten.

danke für die Erklärung, die unterschiedlichen Physikalischen Gegebenheiten ändern sich aber selbst dadurch nicht. Bei Konsolen ist die Hardware ja immer identisch, da mag das funktionieren, aber die verschiedenen HDD und dessen Geschwindigkeitsunterschiede dürften da trotzdem eine ziemlich Hürde sein. Da könnte alleine die Firmware der HDD schon verschieden arbeiten, nur weil etwas extern gleich aussieht kann es intern doch ganz verschieden verarbeitet werden. Bin da aber kein Experte.

 

[Siebenschläfer]

aber die verschiedenen HDD und dessen Geschwindigkeitsunterschiede dürften da trotzdem eine ziemlich Hürde sein

Es gab bei der PS4 ab Werk nur zwei Laufwerke von HGST aus einer Serie verwandt mit der Travelstar 5K1000. Wenn ein OEM wie Sony die bestellt, kommen die auch immer mit der richtigen Firmware.

 

[Moritz Velten]

Sehr schön. Bin es gleich mal am laden und das neue Update sieht auch sehr gut aus.

Dann hoffe ich, dass auch andere Spiele deutlich kleiner werden.

 

[RealNorby]

@Moritz Velten Mach dir mal keine Hoffnungen. Der Fall ist nur so extrem weil die Autodesk Stingray Engine schon seit 7 Jahren discontinued ist. HD2 war ewig in der Entwicklung. Die Engine kennt current gen Konsolen und SSDs gar nicht. Das mussten die Entwickler alles selbst bauen. Wird bestimmt kein anderes Spiel rauskommen, dass noch auf die Engine setzt und andere Engines with Unreal oder Unity haben das Problem nicht.
Ich denke die Begruendung, dass man dich um HDD nutzer sorge ist doch etwas fadenscheinig. DIe wussten bestimmt, dass man assets so packagen kann dass es keine Ladezeit Nachteile gibt, bei der art Spiel die HD2 ist. Aber es war bestimmt ein risiger Aufwand diese uralte Engine so umzubauen.

 

[coxon]

108GB auf der 1TB SSD eingesparrt. Das sind einfach mal satte 10% mehr Speicherplatz.
Ich hatte mich schon vor geraumer Zeit mal bei Reddit über die enorme Installationsgröße mokiert, ging auch recht steil der Thread, was aber wirklich lustig war, war das Mobbing der Konsolen-User. Die haben sich reihenweise über "uns PC-User" lustig gemacht.😅

Sehr schön.

 

[-Quasi-]

Es gab bei der PS4 ab Werk nur zwei Laufwerke von HGST aus einer Serie verwandt mit der Travelstar 5K1000. Wenn ein OEM wie Sony die bestellt, kommen die auch immer mit der richtigen Firmware.

ja, aber das auf die PC Plattform zu übertragen ist wohl eher Blödsinn.... und ein völlig fehlerhafter Ansatz. Im Vergleich zu Konsolen sind PCs Wundertüten. Kann meines erachtens da niemals funktionieren. Das "optimieren" muss da andere Ansätze verfolgen, als Datenträger zuzumüllen in der Hoffnung das der HDD Zugriff minimal besser läuft, dadurch aber locker auch schlechter sein kann. Die in der Regel bessere Ram iAusstattung sollte da eigentlich locker für nutzbar sein, das sowas nicht nötig ist.

 

[WillardBL]

Ich dachte ich habe schon viele Spiele installiert.

Nein, eine HDD würde ich niemals mehr zum zocken nutzen. Die teilweise echt sehr langen Ladezeiten würden mich so stören.

Regt mich schon auf wenn ich online Starcraft 2 (Custom Maps) oder sowas spiele und dann sehe: Aha, 7 Spieler sind mit dem Laden nach 8 Sekunden durch, aber wegen diesem einen Typen müssen wir jetzt 30 - 40 Sekunden warten.

HHDs müssten zum spielen verboten werden 😜

Eigentlich komm ich eh kaum zum Zocken, aber falls mal doch, kann ich es dann wenigstens. Die 50 MBit Leitung behindert mich mehr, eben mal ein Spiel runterladen ist nicht drin.
Nutze 3 HDDs und 3 SSDs (SATA) in einem Speicherpool. Wie Windows es exakt macht, weiß ich nicht mehr, ist schon länger her, dass ich's konfiguriert hab.
Zusätzlich ist eh eine NVM SSD verbaut, was schneller starten soll, landet dort.

Und verglichen zu vor 20 Jahren, als ich ein Raid-0 mit 2 WD Raptoren hatte, ist der Speicherpool extrem schnell. Das Internet hingegen sogar langsamer.