Animationen extrahieren

[Shazu]

Okay, nochmal einen Schritt zurück. Ihr habt noch kein Tool das alle Dateien aus dem Schick.dat File extrahiert? Falls nicht, dann ist das das erste was ihr machen solltet, damit Ihr Zugriff auf die individuellen Datenfiles habt.

Doch, da wäre z.B. der Entpacker von Borbaradwurm: http://mitglied.lycos.de/noctrun/dsa/reen_index.php
Dann gibt es noch unseren Loader, der kann die Schick.dat auch entpacken: svn://freedsa.schattenkind.net:20681
Und dann gibt es noch meinen DungeonDesigner (gleicher Code wie der freedsa loader), der lässt sich zum Entpacken der Schick.dat missbrauchen: http://www.crystals-dsa-foren.de/showthread.php?tid=577

Also so weit sind wir schon, ich vermute jetzt einfach mal, dass die Dateien ANIS, MONSTER, WFIGS und MFIGS in der SCHICK.DAT ebenfalls wieder irgendwelche Archive sind, oder?
Gibt es da irgendwo eine Liste der Dateinamen in diesem Archiv oder sowas?

[VolkoV]

Genau das hatte ich auch vermutet, bin aber zu keinem brauchbaren Ergebnis gekommen. Da diese vier Dateien die größten sind, liegt diese Vermutung nahe. Nachdem ich dort weiter nix gefunden hatte, habe ich die gesamte schick.dat durchsucht, aber ebenfalls nix gefunden.

[Shazu]

Also:
Beispiel ANIS/ANIS.TAB:

Die ANIS.TAB enthält die Offsets für die 37 Dateien innerhalb der Datei ANIS, jedes Offset ist 4 Byte lang. Das scheint soweit zu stimmen, an den Offsets befinden sich Daten die irgendeine Art Header darstellen könnten.

Eine Liste von Dateinamen wie in der SCHICKM.EXE für die SCHICK.DAT vorhanden ist findet sich aber leider nicht, naja man wird dann schon sehen was die Animation darstellt ;P

[SiENcE]

@Guido:

SVN infos siehe hier (bin grad noch dabei Trac einzurichten):

http://freedsa.schattenkind.net/index.php/Herunterladen

[daniel]

Hi Guido,

Habt ihr für die Kampf-Animationen auch einfach nur 'normale fullsize Bilder' unter Berücksichtigung der Transparenz übereinandergestapelt? Oder war das ein spezielles Animations-Format mit "Speichere die Änderung von Bild zu Bild" Funktion?

thnx,
Daniel

ps: Ich hab' grade die Hyggelik.nvf/HygBack.nvf entpackt und angesehen. Wie erwartet ist das die Sequenz, in der Hyggelik auf seinem 'Trohn' das Schwert an die Helden übergibt.
Es besteht aus dem Hintergrundbild + Einzelbildern für die bewegten Teile.

Legt bei mir den Verdacht nahe, dass die Kampf-Animationen in ähnlicher Form abgespeichert sein könnten (zB in FigthObj.nvf, welches ich mit dem loader noch nicht entpacken kann).

[Guido Henkel]

Kampfanimationen waren Sprite Animation und ich glaube nicht, dass wir die mit dem Delta Verfahren abgespeichert haben das wir für die relativ statischen Bildanimationen verwandt haben. Der Grund dafür war, dass wir jederzeit auf individuelle Sprites Zugriff haben mussten, was mit Deltakompression nur umständlich zu machen ist.

Allerdings hatten wir unsere Grafik Tools alle so ausgelegt, dass sie eine Reihe von Kompressionsalgorithmen und Optimisierungen automatisch durchcheckten und dann das Format wählten, das am Ende am kleinsten ausfiel. Das bedeutet, dass Kampfanimation A mit Packer X komprimiert sein konnte während animation B mit einem simple RLE kodiert wurde. Genau weiss ich das aber nicht mehr. Ic hwünschte ich hätte die Tools oder die Sourcecodes noch hier, aber leider hab ich in der Richtung nix.

[Guido Henkel]

Vielleicht hilft Euch das hier ja weiter...

Code:

ACE-Datei-Format                            (ab Version 1.06)


1.    Ace-Header:    
        char    Label[4]    = "ACE\0";        // Kennbytes
        int    Version    = 1;            // Versions-Nummer
        UByte    Sequences;                // 0..250
        UByte    Speed;                    // 0..99

2.    a.    falls (Sequences == 1):      Ass-Header (Ace-Single-Sequence-Header):
        int    CelWidth;                // Größe der Cels
        int    CelHeight;
        UByte    Amount;                // Anzahl der Cels
        UByte    PlayMode;                // Abspielmodus

      b.    sonst:    [Sequences] mal:    Sequence-Header:
        long    Offset;                    // Seek-Offset zur Sequenz
        int    Label;                    // Kenn-Nummer der Sequenz
        int    CelWidth;                // Größe der Cels
        int    CelHeight;
        int    HotSpotX;                // Koordinaten des Hot-Spots (< 0!)
        int    HotSpotY;
        UByte    Amount;                // Anzahl der Cels
        UByte    PlayMode;                // Abspielmodus

3.    [Sequences] * [Amount] mal:
    a.    NewCelHeader:
        long    Size;                    // Größe der Cel-Daten            int    XOffset;                // Position des Frames in der Cel
        int    YOffset;
        int    Width;                    // Größe des Frames in der Cel
        int    Height;
        UByte    Compression;                // verwendeter Packer
        UByte    Action;                    // Action-Button der Cel

    b.    [Size]    Bytes;

4.    Farbpalette:
        768    Bytes;                    // 256 Farben * 3 Farbtöne

[Shazu]

Super, danke!
Das sollte uns helfen...jedoch findet sich kein ACE\0 in den ganzen Daten. Aber das Format wird wohl irgendwie ähnlich sein nehme ich jetzt mal an

[Borbaradwurm]

Das sollte uns helfen...jedoch findet sich kein ACE\0 in den ganzen Daten. Aber das Format wird wohl irgendwie ähnlich sein nehme ich jetzt mal an

Einzelne .ACEs gibt es erst ab Sternenschweif, das mit den ersten vier Bytes hat Die Schicksalsklinge noch nicht: so sind die CHR/NPC Dateien auch noch ohne "DSA Version\0" + Versionsnummer (Header). In dem Punkt ist Die Schicksalsklinge das komplizierteste Spiel der Trilogie.

[VolkoV]

Danke, da werde ich bei Zeiten mal ein bisschen suchen, ob ich diese Schablone auf die Daten kriege.

Das Problem liegt natürlich in diesem Parameter:

Code:

        UByte    Compression;                // verwendeter Packer

[daniel]

Hi beisammen,

Ich habe ein wenig nach einer Liste von existierenden, *historischen*, Grafikformaten gesucht, am besten mit Einführungsdatum oder einer Angabe welches Programm sie verwendet hat (=> Datum der Einführung)
Leider habe ich nichts gefunden, kennt wer von Euch so eine Liste?

Es wäre zwecks Einschränkung der möglichen Kompressionsalgorithmen interessant..

cu, Daniel

[Guido Henkel]

Versuch's mal hiermit

http://en.wikipedia.org/wiki/List_of_file_formats

Das wird Dir in diesem Fall aber nicht weiterhelfen, weil das ein internes Flag war und nichts mit existierenden Grafikformaten zu tun hatte.
Wie ich bereits erwähnte haben unsere Tools eine Reihe Kompressionsalgorithmen durchprobiert um immer die Variante zu finden, die das kleinste Output File liefert. Diese Flag besagt dann, welcher Algorithmus intern verwandt wurde.

[daniel]

bedeutet dass, ihr habt innerhalb der files keine existierenden Fileformate nachgebaut, sondern einfach Bitmaps durch Kompressionsalgorithmen geschickt?

[Guido Henkel]

Statische Bilder wurden an sich so abgelegt, ja, ohne existierende Grafikformate zu verwenden.
Animationen wurden direkt von unseren Tools in einem Format exportiert das diverse Daten in sich bereits gepackt hatte, aber wiederum ohne auf irgendein existierendes Format zurückzugreifen.

Anders als heute, wo jeder eigentlich fast nur standard formate verwendet war das damals nicht üblich. Zum einen weil Formate die wir benötigten nicht existierten oder nicht dokumentiert waren, oder weil existierende Formate zu ineffizient waren. Das einzige Format das damals halbwegs brauchbar war, war PCX, aber eben auch nur für statische Bitmaps, und selbst da war unser eigenes Format meist überlegen.

[daniel]

ok, verstehe.
Na das wird ein Spaß !

Weißt Du vielleicht noch, ob die Kompressionsalgorithmen die damaligen Standard Kompressionsverfahren wiederspiegeln, oder ob ihr auch da frei schaffend an die Sache heragegangen seid?

ps: Guido, danke dass Du uns hier so unterstützt

[daniel]

@VolkoV
Ich habe mich heute ein wenig mit der WEAPONS.NVF beschäftigt, da ich vermutet habe die Waffenbilder (aus dem Inventory und die beim Waffenhändler) darin zu finden.
Testweise habe ich darin ein wenig Bitsalat eingebaut und Probegespielt => im Inventory war alles fein und klar wie am ersten Tag.. so weit so schlecht :o(

Ich bin dann in Thorwall kämpfen gegangen, und siehe da:
sobald der gegnerische Thorwaller sein Schwert geschwungen hat schmiert Schicksalsklinge ab.

Ich vermute, dass diese Datei Kampfanimationen enthält. (14x14 = 196 Pixel)

ersten Bytes: [02 09 00 0E 00 0E 00]
->02 - Crunshmode / 90 00 - Anzahl Datensätze, 144 Stück / 0E 00 = width(?), dezimal 14 / 0E 00 = height(?), dezimal 14

folgende Bytes:
[144 dwords = Längenangaben der einzelnen Datensätze]

folgende Bytes
[144 Datensätze, bestehend aus
{ 1. dWord: Datensatzlänge minus 8 Byte
2. dWord:immer 09090909h
... Daten Bytes, wobei das jeweils letzte dWord sich von Datensatz zu Datensatz nur minimal unterscheidet.
}

Was den Inhalt der Datensätze angeht, habe ich noch keine Ahnung..
Für mich ist es auch unverständlich, wie man 196Pixel auf eine Datensatzlänge von ~20 Byte komprimieren kann - das ist ja 1:10.
Außer sie verwenden weniger Farben; 16 Farben zB; dann wird es realistischer.

ok, vielleicht hilft Dir das, ich suche jetzt mal nach den Inventory Bildern weiter.

cu, Daniel

[daniel]

WEAPANI.DAT -> 66 Datensätze, keine Bilder sondern eher eine Verweis-Tabelle oder so.. Ich habe einen Datensatz herauskopiert und andere damit überschrieben > Viele KampfAnimationen werde nur mehr mit Knüppeln dargestellt.
Interessanterweise ist es egal, ob der Kämpfer ein Elfe/Thorwaller/Krieger ist - alle Animationen werden weiterhin mit Typusspezifischen Sprites dargestellt:
ein Elf bleibt ein Elf, doch mit Knüppel
ein Krieger ein Krieger, doch mit Knüppel...

Diese Datei steuert wohl, welche Animation wann (Abhängigkeit Waffe und Aktion) zum Einsatz kommt.

[SiENcE]

Klingt gut. Hast Du schon nen loader geschrieben und ins svn committed?

[daniel]

Nein, kein Loader, keine Dokumentation. Meine letzten zwei Beiträge waren eher als Support für VolkoV gedacht, der sich ja des Themas annehmen wollte.
Auch kann ich derzeit das Format der Animations-Grafikdaten nicht durchblicken. Das ist irgendwie komprimiert, aber es ist keine Lauflängencodierung.. das ist etwas komplexeres. Und ohne Verständnis kein Loader :o(

Ich bin durch Zufall drauf gestoßen, denn ich suchte die Bilder der Items im Inventory (Schwert-Item, Heiltrank-Item, ..).

Die habe ich mittlerweile auch gefunden (GGSTS.NVF). Die Bilder dort sind im selben Format abgelegt, wie die Animationen hinter denen VolkoV her ist.

Hier zB ein Schwert-Icon (16x16 Pixel):
0000029bh: 3C 00 00 00 09 09 09 09 AE 01 DC 05 78 77 DF FF ; <....... ®.Ü.xwßí¿
000002abh: FF FF FF EE 1E 80 DB 87 4A 31 DC 3A 12 FA 13 B8 ; í¿í¿í¿í®.€í€ºÃ¢â‚¬Â¡J1Ü:.íº. ¸
000002bbh: 62 42 57 4A 77 0C 48 30 8E C0 08 83 82 92 17 C3 ; bBWJw.H0Ž킬.ƒ‚’.Ã
000002cbh: A2 A2 62 48 00 48 5D 0C CA 8A 4E 01 81 02 08 05 ; ¢ ¢bH.H].ÊŠN. ...
000002dbh: 00 01 00 14 ; ....

Das erste dWord (3c 00 00 00) ist eine Längenangabe, der Rest sind Grafikdaten.
Änderungen im String führen zu mehr oder weniger ausgedehntem Pixelsalat im Schwert.. aber leider nicht zu Gedankenblitzen bei mir.
Mein Plan geht in die Richtung, das Schwert-Icon mit einem Screenshot zu erfassen, und dann mittels IrfanView in verschiedenen Grafikformaten zu speichern. Wenn eines davon einen ähnlichen Bytestring erstellt (Palettendaten weggedacht), dann bin ich wohl bei einem ähnlichen Kompressionsalgorithmus gelandet. Damals war LZW ja recht 'in' was Grafiken/Kompression anging..

Leider habe ich diese Woche kaum Zeit dafür, also wenn sich jemand anders daran versuchen will - gerne.

[VolkoV]

Danke. Im Moment komme ich dort aber auch nicht weiter. Vor allem aus zeitlicher Hinsicht.