Beiträge von llm

    Zitat

    Die 34 Byte könnten doch die Instrumentdefinition für den jeweilgen Channel/Track sein.

    sorry das hast du falsch verstanden - ich wollte einen Bezug herstellen zwischen diesem trck_value und der Größe der Track Daten - also ob das irgendwie Bezug dazu hat


    daher habe ich einfach mal trck_value - trck_data.size gemacht und kam damit auf die 34 oder 33 - das ist nur die Differenz


    für alle adl/afx Dateien gilt:


    • die Offsets der Header Komponenten (wo fangen die IDs an usw.) liegen immer am selben Ort - also statisch für Historyline, im Code wird aber der ahdr_data und der imap_data block gezielt ausgelesen - d.h. es könnten variante Größen sein
    • ahdr_data_size ist immer 10
    • imp_data_size ist immer 0
    • adlx_value immer gleich trck_value (einmal big- einmal little-endian)


    ich glaube das der Wert in trck_value irgendeine size ist, komme nur nicht drauf auf welcher Angabe die basiert


    wenn man vom trck_value die trck_data.size abzieht kommt immer 33 oder 34 als Rest raus fuer alle adl/afx Dateien

    in den Daten selber sehe ich aber keine Bezug dazu

    Zitat

    Request für einen Account ist raus :) Bisher war ich dort noch nicht angemeldet.

    Fein, fein



    Zitat

    Den Aufbau der Daten der Tracks könnte man sich eventuell erschließen, in dem man mal mit DOSBox die Adlib-Ausgabe als RAW speichert und etwas analysiert. Dann hat man ja alles, was an den OPL2 geschrieben wird und kann sich z.B. die erste abgespielte Frequenz aus den Werten für Registern 0xA0 und 0xB0 ziehen und zu Note/Oktave umrechnen.

    Wenn es ein Tracker Format ist, müssten diese Informationen dann ja auch am Anfang von Track 0 stehen. Eventuell aber in einem Byte zusammengefasst oder auch als Midi-Befehle.

    Noch einfacher wäre es, wenn die Tracks auch einfach einen Stream aus Werten für den OPL2 und Timing-Befehlen enthalten, was es in selteneren Fällen ja auch gibt.

    Danke für den Tip mit DOSBox - ich schaue da immer mal wieder drauf - vielleicht kommt was bei raus

    die AFX-Dateien haben einen LIB-artigen Aufbau - die ersten 4 bytes sind ein Offset in einen Id/Data-Offset Table

    hinter dem Offset am Anfang kommt dann eine Liste mit ADLX+AHDR+IMAP+TRACK Blöcken



    den ADL Datei-Aufbau hab ich bisher so weit verstanden (jeder Block in einer AFX sieht auch so aus)



    Es gibt scheinbar paar Varianten von dem AHDR Aufbau - nicht suber relevant für einen Editor aber ich wollte wissen wie schnell ich aus dem Code die Struktur rauslesen kann

    ich hab beim stöbern auf jeden Fall mal 1-2 Routinen gefunden die "ADLX","AHDR","IMAP" und "TRCK" suchen - vielleicht für gaaanz viel später wenn die schreckliche Langeweile hochkommt :)

    (Side-Story: für das Spiel Stunts hab ich mal den MT15.DRV (Roland MT-32-Treiber) reverse engineeered und nach C portiert: https://github.com/LowLevelMahn/UnifiedMT15)


    hier eine der Funktion aus der HL.EXE die mit ADLX usw. rumspielt - ab Label loc_3FC60


    die Routine scheint direkt in Assembler programmiert zu sein - enter/leave ist nicht so typisch für Kompiler, und dieses ständige re-initalisierung von es:bx mit les bx, dword ptr [bp+var_4.ofs] alle paar Zeilen sieht auch nicht aus wie der sonstige Code den der Kompiler generiert hat

    brauchen wir Bitmap-Skalierer?: https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms so hqx oder xBR oder sowas? viele sind in C oder C++ geschrieben - also recht problemlos zu integrieren

    oder reicht dir Pixelskalierung - 2x,3x,4x - damits so richtig nostalgisch bleibt :)



    Zitat

    Farbe in der Bitmap + 32

    Farbe in der Bitmap + 48

    Farbe der Bitmap +64 ergbit die Sepia-Töne für die alten Fotos in BIGUNIT.LIB

    was ist mit den Farben 0..31 und 80..255 ? reserviert?

    Zitat

    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.

    CMake ist ok - damit mache ich auch meine VStdio und GCC builds usw. - soweit ich das gesehen haben gibt es auch direkt support für Open Watcom d.h. für DOS könnte man das auch benutzten


    hier ein Mini-Beispiel für ein Uncompress-Tool von mir: https://github.com/LowLevelMah…ompress_cc/CMakelists.txt
    damit kann man sofort unter Windows/Linux bauen - out of the box


    mit Open Watcom haben ich das noch nicht probiert - da habe ich bisher immer nur Batch-Dateien verwendet, aber wenn es geht wär es super


    hier ein Beispiel wie man CMake und Open Watcom nutzt - direkt von dem Open Watcom Maintainer:
    Discussion: https://github.com/open-watcom…discussioncomment-1040368

    Wiki: https://github.com/open-watcom…OW-tools-usage-with-CMake

    Wäre natürlich auch schön wenn das für den Borland C++ 3.1 oder so gehen würde - wobei der Watcom auch mit dem 64bit Kompiler/Linker für DOS bauen kann :)

    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)

    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
    }
    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

    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 :(

    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

    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

    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