Level-/Karteneditor für Historyline 1914-18


  • jetzt kann man auch schön sehen das der 2. Parameter der SOMETHING_WITH_FILENAME_OPEN_ETC_sub_1C56E von mir liebevoll "some_buffer" getauft

    der Puffer ist für den ungepackten Dateiinhalt, der file_read_buffer ist dann wohl nur der Zwischenspeicher zum entpacken

    Code
    SOMETHING_WITH_FILENAME_OPEN_ETC_sub_1C56E("MNUCHR18.LIB",some_buffer(0x7147:0x000A) => 0x0007147A),...
    ...
    DOS_ReadFile: name: BLUEBYTE\HL\MNUCHR18.LIB, handle: 5, toread: 65526, at-pos: 0 => ds:dx(0x7147:0x000A) => 0x0007147A


    Auffällig finde ich hier, dass auch hier zunächst 8 Byte gelsen werden und anschließend dann der Rest in großen Blöcken.

    In der out.txt, die du kürzlich hier eingestellt hast, sah man das ja auch sehr gut z.B. bei der NEWCHAR6.DAT. Da liest er ebenfalls zunächst 8 Byte ein und den Rest dann in 4 KB Blöcken. Die 8 Bytes passen dort perfekt für eine Abfrage, ob die Datei komprimiert ist und dürften also in eine entsprechende Prüffunktion gehen. Passt ja genau mit dem ID String "TPWM" + 4 Bytes für die unkomprimierte Größe.

    Zum Aufbau der LIB-Dateien hatte ich ja schon herausgefunden, dass die ersten vier Byte das Offset zu einem Block mit IDs/Bezeichnungen der enthaltenen Grafiken und den jeweiligen Offsets bilden. Er liest also diesen Offset und den String "INFO".

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • Zitat

    Da llm ja vermutet hatte, dass etwas mit meinem Entpacker nicht stimmt, habe ich mir den Code nochmal angesehen und tatsächlich einen ganz blöden Fehler gefunden..

    Ich hatte vergessen den Modus beim Öffnen der Datei zum Schreiben auf "wb", als binär Modus, zu setzen. Der stand noch auf "w+"

    mit der Korrektur auf "wb+" in deinem Windows-Konsolenprogram funktioniert auch das laden der entpackten MNUCHR18.LIB


    ergibt sich dadurch ein anderes Bild bei deiner Analyse - irgendwelche unbekannten Bytes die nach deinem Fix nicht mehr vorhanden sind?

    Nein, da hat sich nichts geändert.

    Ich habe den Fehler ja auch zunächst nicht bemerkt, da bei mir auch mit "wb+" fehlerfreie Dateien zustande kamen.

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • Zitat

    Ich habe den Fehler ja auch zunächst nicht bemerkt, da bei mir auch mit "wb+" fehlerfreie Dateien zustande kamen.

    unter Windows (und eingentlich auch nur dort) ist "wb+" zwingen nötig sonst werden \r in \r\n umgewandelt

  • Wenn ich mich recht erinnere ist das unter DOS auch ein Problem, weil sonst das EOF Zeichen als Ende der Datei interpretiert wird. Unter Linux/Unix ist das Flag hingegen relativ egal.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • was mir aber immer noch komisch vorkommt ist das wenn man z.B. die MNUCHR14.LIB entpackt scheint es manchmal so als wenn das Menü nicht richitg funktioniert - obwohl ich davon ausgehen das jedes Dateiladen so ein Komprimiert(Ja/Nein) Test beinhaltet - als wenn die Dekomprimierung immer noch nicht zu 100% richtig wäre - was ich mir aber echt nicht vorstellen kann


    Ich werde, wenn ich Zeit finde, das Ergebnis der Dekomprimierungen mal versuchen zu speichern - dann koennen wir es für alle Dateien mit deinem Ergebnis vergleichen - nur zur Sicherheit

  • Wenn ich mich recht erinnere ist das unter DOS auch ein Problem, weil sonst das EOF Zeichen als Ende der Datei interpretiert wird. Unter Linux/Unix ist das Flag hingegen relativ egal.


    Ja, unter DOS ist es leider auch ein Problem. Das ich das "b" für den binary mode vergessen hatte, war einfach ein Tippfehler an einer denkbar ungünstigen Stelle, den ich durch copy&paste dann auch schön in die Windowsversion mitgeschleppt habe. Wird weder binary nocht text mode angegeben, also nur "w" bzw. "w+" ohne "b" oder "t" dabei, dann wird ja einfach der default verwendet (der sich ja auch mit _fmode setzen lässt).

    was mir aber immer noch komisch vorkommt ist das wenn man z.B. die MNUCHR14.LIB entpackt scheint es manchmal so als wenn das Menü nicht richitg funktioniert - obwohl ich davon ausgehen das jedes Dateiladen so ein Komprimiert(Ja/Nein) Test beinhaltet - als wenn die Dekomprimierung immer noch nicht zu 100% richtig wäre - was ich mir aber echt nicht vorstellen kann


    Ich werde, wenn ich Zeit finde, das Ergebnis der Dekomprimierungen mal versuchen zu speichern - dann koennen wir es für alle Dateien mit deinem Ergebnis vergleichen - nur zur Sicherheit

    Ich habe gestern Abend auch nochmal getestet und mit der neuen DOS-Version einfach mal alle Dateien im LIB Unterverzeichnis und im Hauptverzeichnis des Spiels entpackt. Das Spiel läuft, dass Menü wird korrekt angezeigt und ich kann auch ein Spiel starten. Ich hatte beim Entpacken mit "*.*" nur einmal eine "abnormal program termination" bei meinem Packer, dem werde ich nochmal nachgehen.

    Da ich ein bisschen Zeit hatte, habe ich sogar noch ein kleines Tool geschrieben, das die Ressourcen aus den LIB Dateien als einzelne Dateien speichert oder bei Angabe der ID nach einer bestimmten Ressource sucht und diese einzelen speicher. So konnte ich testen, ob meine Vermutung zum Aufbau der Dateien stimmt und auch nochmal, ob der Entpacker richtig arbeitet, denn sonst dürften ja die in der Datei hinterlegten Offset-Angaben nicht mehr passen. Funktioniert ebenfalls gut.

    Also die neue DOS-Version vom Entpacker scheint jezt korrekt zu arbeiten und Code um Grafiken aus den LIB Dateien zu laden haben wir jetzt auch. :)

    Jetzt müssen wir nur noch das Format dieser Grafiken rausbekommen um sie darstellen zu können...


    Ich habe mir die Daten in der MNUCHR14.LIB angeschaut und das Format ist identisch mit dem der PARTS.LIB. Hier sind ebenfalls Grafiken mit dem ID String "INFOILBM" gespeichert, aber viel kleinere mit nur 114 Byte. Meine Vermutung, dass die beiden nicht 0-Bytes kurz nach dem ID-Sting die Bildgöße angeben, scheint sich zu bestätigen:

    An Offset 0Eh und 10h jeder Grafik steht bei denen aus PARTS.LIB ja 18h, hier, bei denen aus MNUCHR14.LIB jetzt 08h und 0Ch. Der Dateiname deutet ja schon auf Character / eine Schrift hin und in der Datei haben wir passend 8x12 Grafiken. Und bei den Grafiken aus PARTS.LIB passt ja auch 24x24 Pixel gut für ein Hex-Feld.

    Soweit so gut. ABER... 8x12 würden bei einem Byte pro Pixel 96 Byte ergeben + 18 Byte Header (so scheint es), wären dann 114 Byte!

    Also doch ganz einfache, unkomprimierte Bilddaten? Habe ich direkt nochmal ausprobiert, aber leider passt es nicht.

    Hier zwei DOSBox-Screenshots wie es aussieht, wenn man die Daten mit der Bildgröße aus dem Header einfach in den Bildschirmspeicher schreibt:


    Die Grafik "0" aus der MNUCHR14.LIB


    Die Grafik "SBUIL009" aus der PARTS.LIB


    Hat jemand von euch eine Idee, wie die Bilddaten gespeichert sein könnten? Erst dachte ich ja, dass es einfach die Bitmapdaten aus Deluxe Paint (ILBM) Dateien sind, was ja naheliegend wäre, aber dann wären sie ja komprimiert....


    Meine Tools für die LIB-Dateien und zum Ansehen der Grafiken habe ich angehängt. Natürlich auch wieder mit Quelltext.

    Dateien

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • Einfach als Laie mal ins Blaue phantasiert: könnten die Pixel schlicht in anderer Reihenfolge sein?

    Weil von den Farben scheint das ja schon irgendwie zusammen zu passen.

    Daily Driver: MSI X470 Gaming Plus - Ryzen 7 1700 - 32 GB - Geforce GTX 1060 6GB - 1 TB NVMe SSD - 2 x 1 TB Raid-0 SATA

    Projekt #1: ASI 486-33 - Projekt #2: PC Chips M912 486 VLB - Projekt #3: Biostar MB8500TVX-A Pentium MMX 166 - Projekt #4: ASUS TXP4 K6-III 400 - Projekt #5: Gigabyte GA-6BXDS Dual Slot 1 PIII-650 -

    Projekt #6: ASUS P2B-DS Dual Slot 1 PIII-1000 - Projekt #7: Gigabyte GA-6VXD7 Dual Sockel 370 PIII-1000 - Projekt #8: TYAN S2505T Dual Tualatin 1400

  • Die Farben stimmen natürlich nicht, ist jetzt einfach die standard VGA Palette. Aber ich finde auch, da lässt sich schon etwas erahnen.

    Vor allem bei der 0...


    Liest man die Bilddaten nicht zeilenweise von links nach rechts, sondern "spaltenweise" von oben nach unten, dann sieht die 0 so aus...

    pasted-from-clipboard.png


    Homeoffice ist echt gefährlich! Jetzt verbringe ich meine Mittagspause mit einem Bilder-/Zahlenpuzzle :D

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • Zitat

    Hmm ist das vielleicht ein Tileset? Für mich schaut es ein wenig nach Straße aus.

    die ähnlichkeit lässt sich kaum leugnen


    @Dragonsphere: kannst du die richtige Farb-Palette nutzen? das würde es noch leichter machen :)

    TSRs zum Palette dumpen

    PlDmpTSR.zip von hier https://www.vogons.org/viewtopic.php?t=88159 (https://github.com/PeterSwinkels/Palette-Dumping-TSR)

    oder siehe SAVEPAL.COM aus dem zip im Anhang

  • Hmm ist das vielleicht ein Tileset? Für mich schaut es ein wenig nach Straße aus.


    tileset.png

    Sieht wirklich sehr so aus, ist aber aus der falschen Datei dafür. Die MNUCHR14.LIB enthält sehr eindeutig nur Buchstaben und Zahlen.


    Hier mal die 0 mit richtiger Palette, spaltenweise gelesen:


    und so, wenn man die Bilddaten zeilenweise liest:


    Und hier mal die korrekte 0 aus einem Screenshot:


    llm Danke für die Palette-Tools. Die Palette vom Menü habe ich gedumpt, die hätten wir aber auch durch die MNUTIT.IFF und MNUSCORE.IFF, die ja die Menuscreens als Bilder mit Palette enthalten. Die Ingame-Paletten haben wir auch ganz problemlos zur Verfügung: 00.PAL,01.PAL,02.PAL (normale Palette, schrille Palette, Monochrom). Entpackt haben die jeweils genau 768 Byte (256*3 Byte für R,G,B), können also einfach eingelesen und an port 3C9 geschrieben werden :)


    Wenn man bei den Kartendaten in den FIN-Dateien einen ungültigen Wert für ein Feld angibt, erscheint übrigens ein Verbotsschild mitt einem kleinen Totenkopf anstelle der Feld-Grafik:

    pasted-from-clipboard.png



    Die Grafik dazu findet man in der PARTS.LIB unter der ID "VERBOTEN" :D und ich dachte mir, die ist auch schön klar und ein guter Testkandidat.

    Wenn ich versuche die anzuzeigen, kommt da aber was ganz merkwürdiges bei rum:


    Zeilenweise:

    pasted-from-clipboard.png


    ..und spaltenweise gelesen

    pasted-from-clipboard.png



    Aber das ist die erste Grafik, wo ich ein gewisses Muster erkennen kann, was hier wohl falsch läuft.

    Dieses "zerstückelte" haben alle Hex-Felder/Geländegrafiken.

    Bilder

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • Ich habe ja keine Ahnung von so das aber wird hier evtl. mit Halbbildern gearbeitet?

    386SX- 20 Mhz "Erster eigener Rechner!2" NoName Komponenten

    486DX -30 "Industrie PC" auf Steckkarte

    Super Sockel 7 Gigabyte GA-5AA 3Dfx Voodoo 3500 TV

    AMD "Geode" ebenfalls Steckkarte für Backplane

    3x IBM Netvista 8364 "ThinRetroSystem" 1-2 von denen würde ich tauschen...


    "und noch so einiges mehr... "

  • Ist das vielleicht planar?

    Habe ich auch schon dran gedacht, aber dann würde die Dateigröße, die ja byte=pixel ist, ja nicht passen. Oder denke ich da falsch?


    Ansonsten dachte ich gerade, ob wir hier vielleicht wieder ein Amiga-Phänomen mit geänderter Byte-Reihenfolge haben und die Daten Word-Weise geschrieben wurden....

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

  • Ich habe ja keine Ahnung von so das aber wird hier evtl. mit Halbbildern gearbeitet?

    Dachte ich auch dran. Und zwar an die Bildpyramide:

    Raster pyramids—ArcMap | Documentation

    Man liest zunächst ein kleines Bild und ergänzt es je nach Zoomstufe mit weiteren Details. Für ein kleines Bild muss so nicht zuerst die volle Auflösung gelesen und dann wieder heruntergerechnet werden.


    Normalerweise macht man das aber mit sehr großen Bildern (Fotos, Röntgenbilder, Satellitenbilder). Also vielleicht hat es eher etwas damit zu tun, dass man es schneller in Planes einteilen kann für unterschiedliche Bildmodi.

  • Wobei viele Spiele damals Feste Auflösungen hatten, also mit rein und herauszoomen war da eher nichts...

    386SX- 20 Mhz "Erster eigener Rechner!2" NoName Komponenten

    486DX -30 "Industrie PC" auf Steckkarte

    Super Sockel 7 Gigabyte GA-5AA 3Dfx Voodoo 3500 TV

    AMD "Geode" ebenfalls Steckkarte für Backplane

    3x IBM Netvista 8364 "ThinRetroSystem" 1-2 von denen würde ich tauschen...


    "und noch so einiges mehr... "

  • Zitat

    Ansonsten dachte ich gerade, ob wir hier vielleicht wieder ein Amiga-Phänomen mit geänderter Byte-Reihenfolge haben und die Daten Word-Weise geschrieben wurden....

    gar nicht so unwahrscheinlich nach den bisherigen Erkenntnissen - würde zu eine ordentlichen visuellen zerwüfelung führen

  • Gerade noch mal ganz schnell was ausprobiert...


    Da das Spiel ja nun, wo der Entpacker gefixt ist, auch die Lib-Dateien unkomprimiert annimmt, können wir doch einfach das Spiel selber zeigen lassen, welches Byte für welchen Pixel steht.

    Warum habe ich da nicht früher dran gedacht? ?(


    Ich dann mal direk in in der MNUCHR14.LIB die ersten vier Byte der Bilddaten der Ressource "0" mit einem Hexeditor auf 00 gesetzt.


    Und in der Highscoreliste sieht die 0 jetzt plötzlich so aus:


    pasted-from-clipboard.png


    Wir können also zwei Dinge bestätigen: Die MNUCHR14.LIB enthält wirklich die Schrift für Highscoreliste u.ä.

    Und ein Byte steht für einen Pixel.

    Nur sind die nicht einfach der Reihe nach abgelegt. Ich habe mit verschiedenen Werten/Farben rumprobiert und das erste Byte entspricht, wie zu erwarten, dem ersten Pixel in der ersten Zeile (oben links).

    Das zweite Byte aber dem fünften Pixel in der ersten Reihe, das dritte dem ersten in der zweiten Zeile und das vierte dem fünften in der zweiten Zeile.

    Sind die beiden Spalten abgeschlossen, geht es mit den nächsten weiter.... Also in diesem Fall, bei einer Bildhöhe von 12 Pixeln, steht Byte 13 für den zweiten Pixel der ersten Zeile und Byte 14 für den sechsten.


    Das Bild ist 8x12, 5 ist also der erste Pixel ab der Bildmitte.

    Es ist also wohl so eine odd/even Byte Geschichte. Ungerade Bytes beginnen am linken Rand, gerade ab der Bildmitte.

    Muss jetzt leider los und habe erstmal keine Zeit mehr, das mal wirklich zu testen.
    Ich denke aber, damit habe ich's. :D

    Meine DOS-Rechner:

    Kleiner Industrie-486er mit 100 MHz (Intel 80486DX-4), 32 MB SD-RAM, Diamond SpeedSTAR 24 und SB 16 ( CT2770 ) + TNDY

    "Frankenstein" Pentium II mit 266 MHz, Elsa Winner 1000 TrioV + Voodoo I, SB 16 (CT2290) + Yamaha DB50XG


    Von mir geschriebene DOS-Programme gibt es hier.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!