Level-/Karteneditor für Historyline 1914-18

  • Ja, lass uns gerne eine Windowsversion ins Auge fassen. Ist schön komfortabel, auch bei großen Karten übersichtlich und man muss sich um den Arbeitsspeicher und geringe Auflösungen nicht kümmern. SDL soltle allemal ausreichen, denn eigentlich müssen ja nur Bitmaps gezeichnet werden können.

    Später würde ich mich dann aber auch an eine DOS-Version machen, denn ich will auch auf meinem 486er Karten editieren können :)


    An die Moddingwiki habe ich auch schon gedacht, dort History Line zu ergänzen ist wirklich ein muss. Und höchstwahrscheinlich passt das, was wir hier herausbekommen haben ja auch für Battle Isle. Das fehlt dort nämlich auch noch :D


    Eine Grafikmod hatten wir hier ja schon thematisiert und ein kleines Tool zu schreiben, das Grafikdateien in das Format in den Lib-files konvertiert und umgekehrt ist ja machbar.


    Auch im Editor die Spielmusik zu haben, wäre natürlich das Sahnehäubchen oben drauf :) .

    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.

  • Kann man den Code so portabel halten, dass er auch unter Linux / macOS mit wenig Aufwand kompiliert? Sollte mit SDL ja möglich sein.

    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

  • Zitat

    Kann man den Code so portabel halten, dass er auch unter Linux / macOS mit wenig Aufwand kompiliert? Sollte mit SDL ja möglich sein.

    ich denke ein Win/Linux/MacOS/DOS portabilität aus einer Quelle sollte gehen so lange man nur normales C oder einfaches C++ macht und ein bisschen vorsichtig ist mit Resourcen


    kommt denke ich relativ stark darauf an wie der Editor aussehen soll - wie eine native Applikation mit Fenstern und Buttons oder eher so eine selbstgemalte Oberfläche


    bei den Konsolen-Tool sollte das definitiv kein Problem sein

  • Ich konnte es natürlich nicht abwarten zu testen und habe gestern am späten Abend noch kurz ein bisschen mit Grafiken aus den verschiedenen LIB-Dateien rumprobiert.

    Mit dem angepassten Algorithmus werden jetzt alle Gelände-Grafiken aus PARTS.LIB und PARTW.LIB korrekt angezeigt. Nur passen die gespeicherten Farbpaletten irgendwie noch nicht 100%ig, aber das ist ja das kleinste Problem.


    Leider habe ich aber auch eine schlechte Nachricht: Die Einheiten aus der UNIT.LIB werden nicht korrekt angezeigt. Wieder nur Pixelsalat, da müssen wir also nochmal ran :(


    Der einzige sichtbare Unterschied ist beim Blick auf die Daten: "ILBM " bei den Einheiten anstatt "INFOILBM" als ID-String.

    Anscheinend nicht nur andere ID sondern auch anderes Format. Ich habe das dann mit den verschiedenen LIB-Dateien getestet und ja, alle ILBM ergeben leider noch Pixelsalat, alle mit INFOILBM werden korrekt gelesen.

    Ich vermute mal, dass die ILBM vielleicht komprimiert sind, die INFOILBM nicht. Werde ich bei Gelegenheit testen.


    Hier, in diesem alten Beitrag zu Siedler II steht übrigens, dass Blue Byte dort ein seltenes und wenig unterstütztes Format unkomprimierter, planarer (PBM) LBM/IFF Grafiken verwendet hat. Es ist auch Quellcode verlinkt, den ich mir aber noch nicht angesehen habe. Vielleich hilft uns das weiter.


    Was ich bei der Gelegenheit aber zufällig erkannt habe, ist die Bedeutung des ersten Bytes hinter der ID im Header der Grafiken.

    Hier ist die Nummer der nicht zu zeichnenden/transparenten Hintergrundfarbe gespeichert.


    Die jetzt lesbaren LIB-Dateien mit INFOILBM Grafiken enthalten schon eine Menge interesseanter Sachen:


    EXP.LIB - enthält die Bilder für die kleinen Explosions-Animationen aus den Kampfsequenzen.

    MNUFAHN.LIB - wie der Name vermuten lässt, sind hier die beiden Flaggen abgelegt.

    MNUICON.LIB - Die verschiedenen Schalter-Icons aus den Spielmenüs.

    MNUMISC.LIB - Der Hand-Mauszeiger aus dem Menü, die Hilfebox unten, der Button um ein Menü zurück zu gehen.

    UMAP*.LIB - In diesen Dateien sind die Miniatur-Grafiken für die Übersichtskarte abgelegt.

    MNUCHR*.LIB - Die Schriftartenaus den Menüs

    PARTS.LIB - Geländefelder Sommer

    PARTW.LIB - Geländefelder Winter



    llm, in der GFXVIEW.CPP ist noch ein kleiner Fehler in deinem Code zur Ausrichtung des Bildes:

    Die halbe Bildlgröße muss von der Bildschirmmitte abgezgen werden, nicht addiert. ;)

    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 jahrelang mit Qt gearbeitet. Damit bekommt man eigentlich auch recht gute Programme hin die trotz GUI portabel sind und auch gut aussehen.

    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

  • Zitat

    Leider habe ich aber auch eine schlechte Nachricht: Die Einheiten aus der UNIT.LIB werden nicht korrekt angezeigt. Wieder nur Pixelsalat, da müssen wir also nochmal ran :(

    ist bestimmt nur ein Bedingungsfehler vom Anwender :)


    Zitat

    Was ich bei der Gelegenheit aber zufällig erkannt habe, ist die Bedeutung des ersten Bytes hinter der ID im Header der Grafiken.

    Hier ist die Nummer der nicht zu zeichnenden/transparenten Hintergrundfarbe gespeichert.

    sehr gut - ich hab mich schon gefragt wie die das machen


    Zitat

    ... in der GFXVIEW.CPP ist noch ein kleiner Fehler in deinem Code zur Ausrichtung des Bildes:

    Die halbe Bildlgröße muss von der Bildschirmmitte abgezgen werden, nicht addiert. ;)

    hab ich schon lange gefixt - war eher so eine Art Review-Test ob du meinen Code auch richtig anschaust

    in deinem LIB-Zerleger wird eine deiner Error-Routinen ohne () aufgerufen == nix passiert


    in GFXVIEW.CPP steht irgendwo


    IDstr[9] = '\0';

    das muesste eine 8 sein

    2 Mal editiert, zuletzt von llm ()

  • Zitat

    Ich vermute mal, dass die ILBM vielleicht komprimiert sind, die INFOILBM nicht. Werde ich bei Gelegenheit testen.


    haben auf jeden Fall mal den selben Header-Aufbau:




    vielleicht mit diesem einfach RLE vefahren


    ILBM - Wikipedia
    en.wikipedia.org


    aber irgendwie passt das nicht - sonst wären doch da nicht so viele 0x99 am Stück


    die Bytes die das Bild darstellen sollen sind die hälfte von Width*Height - also schon "komprimiert", andere Bilder haben ein paar bytes mehr oder weniger


    Zitat

    http://justsolve.archiveteam.org/wiki/ILBM#Compression


    The image compression algorithm is indicated by a coded integer. The known compression types are 0 for no compression, 1 for PackBits, and 2 for a special "vertical" RLE format (see VDAT, below).


    http://justsolve.archiveteam.org/wiki/PackBits scheint nicht zu passen



    Mir sind für eine "richtige" Komprimierung irgendwie auch zu viel gleiche bytes in dem Salat

    7 Mal editiert, zuletzt von llm ()

  • ich glaub ich hab die ILBM Verarbeitungs-Routine gefunden


    IDA hat ein bisschen Probleme die Parameter zu erkennen aber es wird hier nach dem Byte[9] in 3 verschiedene Routinen gesprungen (ich glaube was mit zeichnen)



    wenn ich 18 bytes bei ds:si an Stelle seg068:001B trace kommen dabei solchen Ausgaben


    Code
    inside MAYBE_ILBM_STUFF_sub_3A4AC(data='49 4E 46 4F 30 30 00 00 00 55 00 00 00 00 13 00 01 00')
    inside MAYBE_ILBM_STUFF_sub_3A4AC(data='49 4E 46 4F 30 30 00 00 00 55 00 00 00 00 13 00 01 00')
    inside MAYBE_ILBM_STUFF_sub_3A4AC(data='49 4E 46 4F 30 30 00 00 00 55 00 00 00 00 13 00 01 00')
    inside MAYBE_ILBM_STUFF_sub_3A4AC(data='49 4E 46 4F 30 30 00 00 00 55 00 00 00 00 13 00 01 00')
    inside MAYBE_ILBM_STUFF_sub_3A4AC(data='49 4E 46 4F 30 30 00 00 00 55 00 00 00 00 13 00 01 00')
    inside MAYBE_ILBM_STUFF_sub_3A4AC(data='49 4E 46 4F 30 30 00 00 00 55 00 00 00 00 13 00 01 00')
    ....


    d.h. es könnte schon passen


    leider sehe ich dann nur INFOx und INFOILBM - nicht den (nur) ILBM Header :(

    2 Mal editiert, zuletzt von llm ()

  • Ich habe auch ein paar neue Erkenntnisse:


    die Bytes die das Bild darstellen sollen sind die hälfte von Width*Height


    Damit hast du mich auf eine Idee gebracht. Erst dachte ich ganz kompliziert, dass vielleicht nur halbe Einheiten als Grafik gespeichert sind.


    Das war es nicht. Aber die halbe Bildgröße zu nehmen hilft trotzdem weiter.


    Mit

    Code
    blocks = (header.width/2) / PLANES;
    
    if (((header.width/2) % PLANES) != 0)
    ++blocks;

    kann man plöztlich etwas erahnen.



    Das ist "EAARISUA", ARIS steht wohl für die schwere Artillerie und die ist doch durchaus schon zu sehen.


    Zum Vergleich, so sollte es aussehen:


    Die Farbinfos stimmen noch nicht, aber einen aufwändigen Kompressionsalgorithmus müssen wir wohl nicht knacken. 😊


    Für jede Einheit sind in der UNIT.LIB übrigens 6 Grafiken abgelegt, die die jeweilige Einheit in einem anderen Winkel gedreht abbilden.


    EAARISUB sieht zum Beispiel so aus:




    Was ich auch hinbekommen habe, sind die richtigen Farbpaletten. Auch direkt aus den Spieldateien eingelesen.


    Die Dateien 00.PAL,01.PAL,02.PAL enthalten die R,G,B-Werte als 8-Bit Werte. Unter Windows und bei neueren Grafikkarten kann man die so übernehmen. Aber die alten VGA-Register sind ja aber 6 Bit, also braucht es hier noch einen /4, damit auch auf echter (S)VGA und unter DOSBox die Palette stimmt. Das war alles, was hier noch falsch lief.


    Dann habe ich noch die im Header angegebene Hintergrundfarbe weg lasse, wird nun alles aus PARTS.LIB korrekt und mit den richtigen Farben dargestellt.

    pasted-from-clipboard.png

    Code
    "INFOILBM" 49 4E 46 4F 49 4C 42 4D|4B 55 00 00 00 00|06 00|0C 00
                                       ?? ??             ww ww hh hh

    Die 0x4B ist sicher die Hintergrundfarbe, passt bei allen Grafiken in PARTS.LIB. Nur die 0x55 ist noch zu klären.



    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.

  • Zitat

    Das war es nicht. Aber die halbe Bildgröße zu nehmen hilft trotzdem weiter.

    also könnte man da vielleicht auch einfach mal mit den Farbwerten spielen (ich hab immer 0 oder FF genommen) und schauen wie die Pixel sich bewegen


    Zitat

    Nur die 0x55 ist noch zu klären.


    auch wenn der Code den ich gefunden habe so nicht für 'ILBM ' verwendet wird glaube ich das der Offset 9 den Typ der Grafik definiert: es gibt 0x50('P'), 0x58('X') - und dein 0x55 ('U')


    die Routine wird u.a. für das Zeichnen der Blue-Byte Animation am Anfang verwendet - das wandern der Reflektion ist jeweils ein Aufruf von der Funktion

  • Zitat

    Das war es nicht. Aber die halbe Bildgröße zu nehmen hilft trotzdem weiter.

    es ist aber nicht immer so - manche bilder haben nicht die width*height/2 byte menge - sondern bischen weniger/mehr (nicht genau geprueft)

  • Zitat

    Das war es nicht. Aber die halbe Bildgröße zu nehmen hilft trotzdem weiter.

    es ist aber nicht immer so - manche bilder haben nicht die width*height/2 byte menge - sondern bischen weniger/mehr (nicht genau geprueft)

    Ja und auch bei der schweren Ari passt es ja noch nicht perfekt. War ja nur ein Test und reichte, um das Motiv erkennen zu können.


    In der BIGUNIT.LIB sind übrigens größere Bilder, auch als "ILBM"-Variante. Wenn man im Spiel die Details zu einer Einheit aufruft, werden diese ja mit einem Foto der echten Einheit angezeigt. Das dürften die wohl sein. Hier ist nur darauf zu achten, dass die LIB Datei selber nicht gepackt ist, aber alle Einzelgrafiken sind jeweils TPWM-gepackt.

    Hier passt width*height/2 byte bei einigen Bildern auch schon recht gut und man kann das Motiv erahnen, nur die Farben stimmen absolut nicht.

    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 schnell mal einzelne Bytes einer Grafik in UNIT.LIB mit dem Hexeditor geändert und im Spiel getestet.


    Das Rumprobieren ergab folgendes:

    Code
    Byte 0 ändert Pixel 0/0 und 4/0
    Byte 1 ändert Pixel 8/0 und 12/0
    Byte 2 ändert Pixel 16/0 und 24/0
    Byte 3 ändert Pixel 0/1 und 4/1
    Byte 4 ändert Pixel 8/1 und 12/1
    ...

    Ein Byte ändert hier also gleich zwei Pixel und zwar den ersten mit der Farbe in den unteren vier Bit und den zweiten mit der Farbe in den oberen.

    Die Einheitengrafiken scheinen also einfach 4-Bit Farbtiefe zu haben und das ist alles! Damit passt ja dann auch die halbe Größe und trotzdem die Auflösung im Header.

    Und auch für die großen S/W Fotos in BIGUNIT.LIB passen 16 Grau- bzw. Braunstufen.


    Werde heute Abend mal probieren, den Code entsprechend anzupassen und hoffe, damit ist das Rätsel gelöst. :)

    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.

  • Wäre es mit den gewonnenen Erkenntnissen auch möglich einen Einheiteneditor zu erstellen? z.B. um Grafiken, Werte und Beschreibungen zu ändern? Oder zumindest eine Batchdatei welche die einzelnen Assets wieder bündelt? Dann könnte ich mich z.B. an "Datadisks" oder ein anderes Setting wagen.

  • Werde heute Abend mal probieren, den Code entsprechend anzupassen und hoffe, damit ist das Rätsel gelöst. :)

    baust du eine Prüfung auf Byte 9 im header ein und machst zwei eigene draw routine dafür die dann darin aufgerufen werden - dann haben wir eine haupt-draw die 2 unter-draws aufruft für 0x50 und 0x55

    der Header sieht ja jetzt so aus:


    Code
    char id[8] "ILBM    " oder "INFOILBM"
    uint8_t transparent_color;
    uint8_t type; // 0x50 und 0x55
    uint16_t width
    uint16_t height


    und dann so eine


    Code
    draw(...)
    {
      if(header.type == 0x50) draw_0x50
      if(header.type == 0x55) draw_0x55
    //   vielleicht kommt da noch was dazu
    }

    Einmal editiert, zuletzt von llm ()

  • Wäre es mit den gewonnenen Erkenntnissen auch möglich einen Einheiteneditor zu erstellen? z.B. um Grafiken, Werte und Beschreibungen zu ändern? Oder zumindest eine Batchdatei welche die einzelnen Assets wieder bündelt? Dann könnte ich mich z.B. an "Datadisks" oder ein anderes Setting wagen.

    also bei den Grafike sehe ich da keine Probleme - für Werte und Beschreibungen müssten man rausfinden ob die in Dateien stecken oder (teilweise) direkt hart in die HL.exe kodiert sind (keine Ahnung)

  • Code
    draw(...)
    {
      if(header.type == 0x50) draw_0x50
      if(header.type == 0x55) draw_0x55
    //   vielleicht kommt da noch was dazu
    }

    switch(header.type) ... :)

    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

  • Kurze Erfolgsmeldung: :)


    Mit 4 Bit pro Pixel sieht die "EAARISUA" so aus:

    pasted-from-clipboard.png


    Und der Code so:

    Letzte Frage dazu ist nun, wie die das mit den Farben gelöst haben. Mit den Paletten des Spiels sieht es so aus wie oben und irgendwie muss diese ja einmal in den Farben für die deutschen und einmal in denen für die französischen gezeichnet werden können. Ich vermute, es wird ein Wert zu den Farbwerten der Grafik addiert, je nach deutscher oder französicher Seite. Gucke mir nachher mal die Palette dahingehend an.

    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

    Kurze Erfolgsmeldung


    sehr erfolgreich :)


    ist ja alles kurz vor fertig - ich denke dann sollte geschaut werden das wir aus einer Quelle für Win/Dos/Linux bauen können - mit eine paar Defines+Macros sollte das gut gehen

  • Zitat

    Kurze Erfolgsmeldung


    sehr erfolgreich :)


    ist ja alles kurz vor fertig - ich denke dann sollte geschaut werden das wir aus einer Quelle für Win/Dos/Linux bauen können - mit eine paar Defines+Macros sollte das gut gehen

    Da kann ich gerne auch bisserl unterstützen. Ich empfehle CMake -- das kann Makefiles, Ninja, VisualStudio, xcode solutions bauen. Ist am Anfang etwas ungewohnt, hat aber den Vorteil, dass alles Textdateien sind, die man einchecken kann.

    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

Jetzt mitmachen!

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