Crystals-DSA-Foren
Reverse Engineering der NLT - Druckversion

+- Crystals-DSA-Foren (https://www.crystals-dsa-foren.de)
+-- Forum: Allgemeines zur Nordlandtrilogie DOS (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=20)
+--- Forum: Technische Werkstatt (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=34)
+--- Thema: Reverse Engineering der NLT (/showthread.php?tid=700)

Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98

RE: Reverse Engineering der NLT - Shazu - 21.09.2007

Mein Script kann inzwischen NVF Container des Typs 05 entpacken, das sind alle Texturen, die man in Städten und Dungeons zu sehen bekommt....alle sind schief!

Das ist der Teil des Scripts, der die Daten entpackt. Da ich Anfangs diesen Script quasi alleine hatte und ihn mit den Rohdaten gefüttert habe und das selbe Ergebnis bekommen habe, ist ein Fehler in der Weiterverarbeitung sehr sehr unwahrscheinlich.
Code:
local rl
for j = 1, images[i].size do
    local byte = file:readbyte()
    if not byte then
        break
    end
    if byte - 127 < 0 then
        rl = byte
    else
        obj.images[i].data = obj.images[i].data..string.char(byte - 127):rep(rl or 1)
        rl = nil
    end
end

Da fehlt eher noch etwas an der Spezifikation, irgendwas muss ich wohl übersehen haben :/


Die Sache mit den schwarzen Pixeln würde auch erklären, warum ein Bild mit der korrekten Breite noch schlimmer aussieht:

[Bild: LTURM-115.GIF][Bild: LTURM-127.GIF]

Links ist das Bild 115 Pixel breit, so steht es im Header der NVF Datei, rechts ist die Breite auf 127 Pixel angepasst. Das Bild im Spiel ist 112 Pixel breit.

RE: Reverse Engineering der NLT - Shazu - 21.09.2007

Ich glaub ich hab's. 0x7F ist nicht wie ich vermutet hatte das die niedrigste mögliche Farbe sondern irgendein Steuerzeichen.

Das löst auch das Problem mit der Palette, die "falschen" Farben waren nämlich nur um 1 verschoben.
Wenn man diese Steuerzeichen einfach komplett ignoriert, dann erhält man folgendes:

[Bild: LTURM-fixed-1.gif]

RE: Reverse Engineering der NLT - daniel - 21.09.2007

cool, sieht so aus als wäre nur mehr ein Pixel pro Zeile zu wenig. Erklärt möglicherweise auch die schwarze zeile am unteren Rand (oder kommt das vom ausschneiden? :o)

cu
Daniel

RE: Reverse Engineering der NLT - Borbaradwurm - 21.09.2007

[Bild: turm1.gif][Bild: LTURM-fixed-1.gif]
Jetzt sieht das Bild aus als ob die erste Zeile zu wenig Pixel hat, ich würde mal auf einen Pixel tippen, daher kommt die Schräge außerdem sieht die letzte Zeile nicht so aus wie im Screenshot. und es gibt transparente Pixel (Screenshot unten links).

RE: Reverse Engineering der NLT - Shazu - 21.09.2007

daniel schrieb:cool, sieht so aus als wäre nur mehr ein Pixel pro Zeile zu wenig. Erklärt möglicherweise auch die schwarze zeile am unteren Rand (oder kommt das vom ausschneiden? :o)

cu
Daniel
Jo, ein Pixel fehlt, wenn man einfach pro Zeile einen hinzufügt, so erhält man das korrekte Bild:

[Bild: LTURM-fixed-2.gif]

Edit: Komisch, Bild 2 und 3 sind noch verzerrt, aber Bild 4 sieht auch richtig aus mit diesem Zusatzpixel:

[Bild: LTURM4.gif]

RE: Reverse Engineering der NLT - Shazu - 21.09.2007

Komisch, das zieht sich durch alle Texturen. Einige sind ohne Korrekturpixel schief, andere sind mit schief und noch andere brauchen ganz andere Korrekturpixel, komisch.

RE: Reverse Engineering der NLT - daniel - 21.09.2007

Ohne jetzt die Bilder gesehen zu haben klingt das was Du beschreibst nach einer variablen Bildbreite.
Vielleicht hängt das mit dem Steuerzeichen zusammen, das zu zuerst anders interpretiert hast..

Die Lauflängen-Dekompression muß ja passen, ansonst wären die Bilder ungleichmäßig verzerrt, wie es am Anfang war.
ps: Kann es sein, dass der "Korrekturpixel" am Anfang der Zeile eingebaut ist? Vergleiche ich Dein letztes Ergebnis mit dem Original, sitzt Dein Bild zu weit rechts. Ich glaube der Pixel fehlt am Ende der Zeile.

Auf jeden Fall eine coole Arbeit:up::up:,
Daniel

RE: Reverse Engineering der NLT - SiENcE - 23.09.2007

Von mir auch herzlichen Glückwunsch.

Eigentlich könnte man schon anfangen, die Städte und Dungeons zu implementieren, wenn die Grafiken fertig sind. Die Kämpfe wird nochmal eine ganz andere Sparte.

Ich guck mir mal an, was du so die letzten Wochen im svn getan hast.

RE: Reverse Engineering der NLT - Obi-Wahn - 23.09.2007

Sieht super aus! :) :)

Edit: ich hab mir mal nen svn-checkout gemacht und einfach mal mit Wine das Programm ausprobiert. Es läuft mit ein paar Wine-Fehlern durch und gibt die Bilder aus.

Edit2: Nativ unter Linux klappt es auch. http://freedsa.schattenkind.net/index.php/Linux:)

RE: Reverse Engineering der NLT - Shazu - 23.09.2007

Die Meldung kommt unter Windows auch beim entpacken der Schiffstexturen, liegt daran dass laut meiner NVF Spezifikation alles unter 0x80 keine Farbe ist. Was aber wohl nicht so ganz zu stimmen scheint.

RE: Reverse Engineering der NLT - daniel - 23.09.2007

Hi,

Ein Vorschlag meinerseits zur Aufteilung HEX Thread / Reverse Engineering - bitte ansehen, nachdenken und melden:
Beitrag 276:
http://www.crystals-dsa-foren.de/showthread.php?tid=80&page=14

Bitte im HEX Thread diskutieren, da wir sonst alle in verschiedenen Threads durcheinanderquatschen (-schreiben :o)

cu
Daniel

RE: Reverse Engineering der NLT - Crystal - 23.09.2007

Ein kleiner Tipp, daniel. Die Beitragsnummern (rechts) sind auch Links. Damit kann man beitragsgenau verlinken. :)

RE: Reverse Engineering der NLT - SiENcE - 24.09.2007

Wie wäre es mit einem unterforum für die FreeDSA Entwicklung? Da könnte man alle threads reinpacken. Im wiki verlinke ich ja auf das Forum hier :-).

@obiwhan: klaro klappt das unter linux genauso wie unter win. wir nutzen später auch lugre+ogre3d und das läuft auch nativ unter win/linux/mac.

RE: Reverse Engineering der NLT - Crystal - 25.09.2007

SiENcE schrieb:Wie wäre es mit einem unterforum für die FreeDSA Entwicklung? Da könnte man alle threads reinpacken. Im wiki verlinke ich ja auf das Forum hier :-).
Ich bin kein Fan von Unterforen. Aber eine Extra-Rubrik wie hier die "Allgemeine Diskussionen" könnte ich euch einrichten. :)

Allerdings müsste ich Gewissheit darüber haben, dass ihr auch am Projekt dranbleibt. ;) Wenn du die Leute unter deiner "Flagge" anführen willst und motivierst, wäre das für mich Gewissheit genug. Dann ließe sich auch darüber reden, Mod-Rechte in dieser Rubrik zu vergeben, damit ihr euch sortieren und einrichten könnt wie z.B. Sticky-Threads oder sowas. :)

RE: Reverse Engineering der NLT - Obi-Wahn - 25.09.2007

@Sience: Im Moment klappt das vielleicht noch problemlos, aber wenn ihr erstmal mehr Bibliotheken mit bestimmen Versionsnummern benutzt, klappt das ganz schnell nicht mehr so leicht. Bestes Beispiel ist die neuste Version von DboxFE, die ich aufgrund von Abhängigkeitsschwierigkeiten nicht mehr kompiliert bekomme.

RE: Reverse Engineering der NLT - daniel - 26.09.2007

:new: Ich habs! :jippie::jippie:

Shazu hat mir heute die sourcen für's Image-Dekodieren geschickt - nach 5h herumtüfteln habe ich es geschafft, dass die Bilder des Leuchtturms sauber in ein BMP-File umcodiert werden:

[Bild: LTURM1_d.gif]
[Bild: LTURM2_d.gif]
[Bild: LTURM3_d.gif]
[Bild: LTURM4_d.gif]

Shazu, ich schicke Dir morgen die Änderungen, die ich im Dekoder eingebaut habe.

Danke nochmals für das ganze Script :ok:, und die Doku zum Fileformat!
cu - Daniel

RE: Reverse Engineering der NLT - Guido Henkel - 26.09.2007

Hier eben was, das ich in den Riva Sourcen auf die Schnelle gefunden habe...

Code:
//  NVF-Format (only for crunchmode 1 !)
//
//   +--------------------------------------------------+
//   | byte   crunchmode;                               |   Header
//   | uword  blockcount;                               |   3 byte
//   +--------------------------------------------------+
//   | uword  block 1 ->width                           |   Blocksizes
//   | uword  block 1 ->height                          |
//   |  ....                                            |   n * 4 byte
//   | uword  block n ->width                           |
//   | uword  block n ->height;                         |
//   +--------------------------------------------------+
//   | Data block 1 (width*height of block 1 bytes)     |   ? bytes
//   |    ....                                          |
//   | Data block n (width*height of block n bytes)     |
//   +--------------------------------------------------+
//   | uword  # Colors;                                 |   2 bytes
//   +--------------------------------------------------+
//   | byte   Palette[# Colors][3]                      |   # Colors * 3 bytes
//   +--------------------------------------------------+


RE: Reverse Engineering der NLT - Borbaradwurm - 26.09.2007

daniel schrieb:Shazu hat mir heute die sourcen für's Image-Dekodieren geschickt - nach 5h herumtüfteln habe ich es geschafft, dass die Bilder des Leuchtturms sauber in ein BMP-File umcodiert werden:
Dann fehlt nur noch die Antwort auf die Frage der Transparenz.

Guido Henkel schrieb:Hier eben was, das ich in den Riva Sourcen auf die Schnelle gefunden habe...
Okay, die Datenstruktur aus der Originaldokumentation ist natürlich vollkommen unschlagbar...

RE: Reverse Engineering der NLT - daniel - 26.09.2007

Farbindex 0 ist anscheinend die Transparenz, ich habe gerade die entsprechenden Bilder im Wiki ersetzt. Also wenn bei diesem Beitrag im Browser auf 'aktualisieren' klickt, dann sollten die Bilder in meinem ursprünglichen Beitrag#76 rosa Pixel als Zeichen für Transparenz haben (nur Bild 1 und Bild 4 sind ersetzt)

RE: Reverse Engineering der NLT - SiENcE - 26.09.2007

@Guido: danke.