Ja! Es ist genau wie Skype: eine langsame DSL-Leitung kann man durch eine
schnellere CPU ausgleichen und umgekehrt.

Ich denke, mit den heutigen Möglichkeiten ist ein Playstation-Tomb Raider in
vollem Umfang auf dem Nintendo 64 möglich.
Der Coder von "OpenLara" hat durchblicken lassen, dass er es versuchen will.
Ich bin gespannt!

Gerade gesehen: Die CPU vom N64 schafft H.264 Videodecodierung.

https://www.youtube.com/watch?v=i89f_CMn7bw

Dann vermute ich bzgl. der PS1 Version folgendes:

Die 56 Audio-Tracks erklären sich durch die vielen kleinen Melodien, kurze Ambient-Sounds, die an fixen
Punkten in Levels abgespielt werden. Da sie nicht permanent durch Aktionen hervorgerufen werden (wie zum
Beispiel die Schieß-Geräusche), also auch nicht "schnell abrufbar" sein müssen, hat man sie einfach als
Audio-Track auf die CD gebrannt, um sie direkt zu streamen (langsamer durch die Zugriffszeit des CD-ROMs) und
somit RAM-Speicher für Audio-Samples zu sparen. Die als 4 Bit ADPCM Samples mit in den Datentrack aufzunehmen,
hätte den Kohl bei der starken Kompressionsrate nicht fett gemacht - wohl aber viel sehr begrenzten Sound-RAM gekostet.
Da das N64 Daten sehr flott vom Modul streamen konnte, macht es (wie bei allen Modulkonsolen) keinen
großen Unterschied, ob Samples im RAM liegen, oder man sie einfach direkt vom ROM aus verwendet.

Die 279MB Daten können reduziert werden,

a) Dadurch, dass wie gesagt einige Daten mehrfach auf der CD vorhanden sind, um Zugriffszeiten zu verkürzen
b) Die FMV Decodierung. Die PS1 hat einen Hardware-MotionJPEG-Decoder. Der hat eine gute, aber jetzt vielleicht
auch nicht optimale Kompressionsrate. Wozu auch, die CD ist ja groß genug, und da kommt es auf ein paar MBs
mehr oder weniger nicht an. Wählt man jetzt einen Codec, der besser / effizienter komprimiert, und den die 93MHz MIPS
CPU stemmen kann (zumal sie beim Abspielen von FMVs ja auch nichts anderes zu tun hat), kann die Größe der
FMV-Daten reduziert werden. Heutzutage noch umso mehr als damals, da sich die Kompressions-Algorithmen verbessert haben.

Aber. Großes "Aber". 64MB sind die maximale Modulgröße. Das war damals sauteuer. Und selbst wenn es möglich
gewesen wäre, alles darin unterzubringen, hätte ein Spiel dann vermutlich 300DM gekostet. Somit also wieder
unpraktikabel. (Aber: Grund sind die Kosten, nicht das Modul ansich)
Aber auch die PS1 Spiele hätten von ihrer MB-Zahl deutlich reduziert werden können. Aber wozu - man musste es
ja schließlich nicht. Also konnte man verschwenderisch mit den MBs einer CD umgehen und sparte somit teure
Entwicklungszeit. Doch wenn ein PS1 Spiel 279MB Daten groß ist, bedeutet es (aus den genannten Gründen) nicht,
dass es 279MB groß sein muss.
Kommentar wurde am 23.07.2022, 13:39 von Bömpf editiert.

Aus heutiger Sicht bin ich mir nicht mehr ganz sicher, ob bei dieser ganzen "CD vs. Modul"-Debatte
damals wirklich mit komplett offenen Karten gespielt wurde. Sicher, die Module waren teurer, aber
immer dieses Argument, das FMV-Sequenzen und gesampelte Musik da nicht drauf gepasst hätten...?

Ich habe die Entwicklung von "OpenLara" mitverfolgt und dadurch ein paar interessante Dinge mitbekommen.
Alle Audio-Samples (auch die Musik) liegen im 4 Bit ADPCM-Format vor. D. h. sie belegen quasi kaum
Speicherplatz. Wie sollten die Samples auch viel Speicherplatz belegen, wenn die PS1 nur 2MB RAM hat?
Da muss ja alles für einen Level reinpassen.
Die FMV-Sequenzen von Tomb Raider sind insgesamt ca. 320 Sekunden lang.
Nun hat das N64 einen 93MHz schnellen Risc-Prozessor mit FPU, d. h. ein effizienter Software-Decodierungs-
Algorithmus für Videos sollte kein Problem sein.

Ich glaube nicht, dass es bei einer Modulgröße von 64 Megabyte (64 Megabyte waren mitte der 90er wirklich
viel!) ein Problem gewesen wäre, ein Spiel wir "Tomb Raider" unterzubringen, mit all diesen möglichen
Kompressionsverfahren und der Hardware-Leistung des N64.

Und die Datengröße einer Playstation-CD (wenn man sich anschaut, wie groß ein ausgelesenes Image als ISO ist),
ist auch relativ - denn auf die CDs wurden Daten oft mehrfach gespeichert, an verschiedenen Positionen,
um die Lade- / Zugriffszeiten zu verringern. Die effektive MB-Größe eines Spieles war also oftmals geringer
als das ISO, aufgrund von mehrfach gespeicherten Dateien.
Kommentar wurde am 23.07.2022, 11:55 von Bömpf editiert.