Hallo Besucher, der Thread wurde 7,3k mal aufgerufen und enthält 47 Antworten

letzter Beitrag von fredrikr am

Interactive Fiction Interpreter

    Ich bin heute über Ozmoo gestolpert, tolles Projekt !
    Was mich aber an allen Projekten dieser Art bisher gestört hat ist die Platzverschwendung der Storyfiles.
    Wäre es möglich die Storyfiles in gecrunchter Form zu verwenden mit angepasstem Loader, ähnlich IFFL Loader ?
    Z.B. ein 120 KB großer Z5 File würde so auf 40 - 50 KB reduziert und würde locker auf eine Diskseite passen, oder je nach Größe sogar ins RAM.
    Exomizer wird bei Ozmoo ja schon angewendet....

    Zitat von Larry

    Wäre es möglich die Storyfiles in gecrunchter Form zu verwenden

    Nein, eher nicht.
    1.) Die Texte in den Storyfiles sind nach dem damaligen Standard bereits gepackt.
    2.) Auf die Storyfiles wird zugegriffen wie auf ein Ram, d. h. nicht seriell nacheinander, sondern kunterbunt durcheinander. Ein Entpacker arbeitet jedoch seriell, d. h. um an ein Byte der Position X zu kommen, müssen vorher alle X - 1 Bytes entpackt werden.
    3.) Das könnte man dadurch lösen, indem man nur blockweise packt und bei Bedarf einen Block in einen Cache entpackt. Fragt sich nur, ob sich dadurch wirklich viel Platz einsparen läßt, da der Aufwand für solch eine Vorgehensweise recht hoch ist. Es ist leider zu vermuten, daß es nicht lohnt.

    Zitat von Larry

    Z.B. ein 120 KB großer Z5 File würde so auf 40 - 50 KB reduziert und würde locker auf eine Diskseite passen, oder je nach Größe sogar ins RAM.

    Du scheinst die Komprimierbarkeit von Infocom-Storyfiles deutlich zu überschätzen:



    exomizer 2.0beta7 lag gerade rum, komprimiert mit der raw-Option ohne besondere Einstellungen. Real müsste man die Dateien blockweise komprimieren um nur die gerade benötigten Teile daraus nachladen zu können, was die Kompressionsrate nochmal verschlechtern würde.

    Naja ich habe z.B. das Storyfile von "2604" von 120KB mit Exomizer 3 auf rund 47 kb bekommen und ein anderes von von 173,7 auf 35,1.
    Das ist schon erheblich in meinen Augen.
    Natürlich müsste das File "in seine Bestandteile" gesplittet werden und dann wie beim Levelpacken wieder zusammengefügt werden. Dann braucht man eine Tabelle, wo im File was liegt. Bzw. die Umsetzung von VMEM Adresse zu Track/Sector gibt es ja und muss entsprechend ersetzt werden.
    Wie gesagt das ist nur so ein Gedanke von mir. Wie schnell das dann alles laufen würde ist noch eine andere Frage.


    EDIT: Sorry Exomizer 2.09

    Die Story-Datei besteht im Wesentlichen aus zwei Teilen - dem dynamischen Speicher und dem schreibgeschützten Speicher. Wenn große Teile der Story-Datei sehr effizient komprimiert werden können, befinden sie sich fast immer im dynamischen Speicher. Der gesamte dynamische Speicher ist in der Datei mit dem Interpreter enthalten und mit Exomizer 3.0.2 komprimiert. Der Inhalt des dynamischen Speichers verbleibt immer im RAM, sodass er nicht Teil der VMEM-Verarbeitung ist.


    Ozmoo teilt den schreibgeschützten Teil der Story-Datei in 512-Byte VMEM-Blöcke auf (Wir haben unterschiedliche Blockgrößen ausprobiert und fanden diese größe am besten). Immer wenn der Code auf einen Block verweist, der sich derzeit nicht im RAM befindet, wirft er den zuletzt verwendeten Block aus und lädt den angeforderten Block von der Diskette. Da ein Diskettesektor aus 256 Bytes besteht, ist es ziemlich einfach zu berechnen, welche Sektoren gelesen werden sollen, und die Anzahl der zu lesenden Sektoren beträgt immer genau zwei. Wenn Sie jeden 512-Byte-Block komprimieren, könnte dies möglicherweise 70% von zwei Sektoren = 1,4 Sektoren beanspruchen, so dass immer noch zwei Sektoren gelesen werden müssen. Da Sie keine Zeit sparen und Dekompressionszeiten hinzufügen, wird das Spiel langsamer.