Reverse Engineering der NLT II

[cmfrydos]

Vielen Dank für die vielen positiven Rückmeldungen!
Größtenteils sollte das Lob natürlich an Attic gehen, da das Entwickler- und Arts-Team sich für 1997er Verhältnisse wirklich Mühe mit den vielen verhältnismäßig hochauflösenden Texturen gegeben haben. 

Sieht gut aus! Und das ist dann in der Vollbildauflösung des Monitors gewesen?

Ja, alle Bilder wurden im 3840x2080 Vollbildmodus aufgenommen, wobei ich eines auf HD runterskaliert habe.
Das Programm unterstützt sowohl einen Fenstermodus in variabler Auflösung, als auch einen Vollbildmodus in nativer Auflösung des Monitors, und läuft mit konstant 60 FPS.
Später kann ich noch Features wie einen rahmenlosen-Vollbild-Fenstermodus, variable Framerate und Grafikoptionen aus einem anderen Teamprojekt von mir kopieren, aber ich müsste wohl vorher noch etwas UI-System (Buttons, Panels, etc.) für ein Menü schreiben, oder einen Komilitonen bitten, ob ich seinen Code verwenden darf.

Oh, toll. Was hast du verwendet, um die Daten zu laden und zu durchfliegen? Unity, Unreal, Blender?

Das Projekt habe ich in .NET C# erstellt, und als Engine benutze ich MonoGame (eine freie XNA Cross-Platform Implementierung).
Das Framework ist einfacher als direkt OpenGL oder DirectX anzuprechen, aber nicht so komplex und "einschränkend" wie Unity oder Unreal. Dafür muss man aber alles was über Basisfunktionaliät geht selber schreiben.
Um die Daten zu Laden, habe ich wie erwähnt die zusammengetragenen Infos und Entpacker hier aus dem Forum verwendet Rießen Danke dafür!.

Das ist ja richtig geil! Du hast also den Schritt gemacht, der mir noch nicht gelungen ist. Sehr cool
Was meinen Renderer angeht: Das war ja eigentlich kein Renderer, sondern ein Exporter für Blender. Damit konnte ich die Vertex- und Face-Daten in Blender importieren. Daher kamen damals auch die Bilder (die jetzt nicht mehr da sind).
Wenn ich mir Deine Bilder ansehe, wird mir sofort klar, dass dieser alte Code nichts beisteuern kann.

Mit Blender und 3D kenne ich mich leider noch nicht so gut aus, weswegen ich erst einmal MonoGame benutzt habe, das ich schon für einige kleinere 2D-Games benutzt habe. Wahrscheinlich bringst du da deutlich mehr 3D Knowhow als ich mit. Man könnte sicherlich einen Exporter in ein moderneres Format schreiben, falls das hilfreich ist. Ich freue mich, falls wir hier dann zusammen noch zu weiteren Erkenntnissen kommen

So jetzt mal, was ich so (entgegen oder ergänzend zu den Infos im Wiki) herausgefunden habe. Die können gerne übertragen werden, oder mit einem Account könnte ich es auch selber machen. Außerdem mal alles, das noch Rätsel bereitet.

Ich gehe mal in der Reihenfolge durch, wie man die Dateien am Besten lesen sollte:

Spoiler

.DSC (Textdatei):

Ganz wichtig, um an die Namen der Animationstexturen zu kommen, und die Auflösung eines Frames.
Nur damit kann man korrekt die entsprechende .PIX parsen.
Animierte Objekte habe ich implementiert, was fehlt sind noch "bewegte" Objekte. Diese haben nur die Felder Höhe und Speed, aus denen ich noch nicht schlau wurde. Muss man mal mit dem Spiel abgleichen. Außerdem sind noch manche Animationen (Zwergenbinge wo die Orks am Esstisch schlafen) kaputt, da muss man noch forschen.

.3DM (3D Modelle und Texturierung im Binärformat)

Objektheader:

Größe Inhalt
int     Name als String-Verweis (siehe String-Tabelle)
short Anzahl der Vertices im Objekt
short Anzahl der Faces im Objekt
short NEU: Anzahl der Vertex-UV Mappings.
short NEU: Anzahl der Zeichenaufträge
short ??? noch unbekannt, oft Anzahl der Vertex-UV Mappings oder etwas größer, aber selten auch kleiner
short NEU:  Anzahl der (Materialgruppen?). Ich weiß noch nicht, was da genau steht.
int Bounding-Box: X-Komponente des Mittelpunkts
int Bounding-Box: Y-Komponente des Mittelpunkts
int Bounding-Box: Z-Komponente des Mittelpunkts
int NEU:  Distanz vom Mittelpunkt zu den Ecken, dh. eine halbe Diagonale
int Bounding-Box: X-Komponente des 1. Punktes
...
int Offset für die Faces
int GEÄNDERT: Offset für UV Mappings
int GEÄNDERT: Offset für Zeichenaufträge
...

"Die unbekannten Integer-Einträge in der Mitte des Blocks könnten vermutlich Platzierungsinformationen darstellen. So hätte jedes Objekt ein eigenes Koordinatensystem, unter dem es seine Vertices speichert, und einen Wert in Form von Weltkoordinaten in der Karte. Dies ist aber bisher nur eine Vermutung." - Stimmt also nicht. Alle Koordinaten in den Objektdaten sind immer Weltkoordinaten.

Unbekannter Datenblock:

Weiterhin unbekannt. Meine Vermutung ist, dass jeder 88 Byte Eintrag, (der nicht komplett aus Nullen besteht), mit einem Int beginnt, der einen String-Index darstellt. Der Wert liegt nämlich fast immer in dem Bereich. Außerdem könnte manchmal auch das letzte Byte ein String-Index sein (aber deutlich seltener). Die Mitte ist mir vollkommen unbekannt. Vermutung aus der Vermutung: Könnte "Weltveränderungen" wie Objekt1 verschwindet bei Event 1, Objekt3 ersetzt Objekt2 bei Event2, Objekt4 bewegt sich um X,Y,Z bei Event3, etc. darstellen. Außerdem fehlen noch die Positionen der Lichtquellen, die irgendwo kodiert sein müssen. Könnte natürlich auch direkt im Material stehen.
Der vierte Wert "Meistens 0x0000, aber manchmal 0x1000 (nur bei sichtbaren Objekten)" ist auch manchmal 0x1000 bei nicht-sichtbaren Objekten.

Objektdaten:
1. Erstmal Vertices (wie im Wiki mit XYZ Weltkoordinaten). Größe: Anzahl der Verticesim Objekt * 12 Byte

2. Dann Faces. Größe: Anzahl der Faces im Objekt * 12 Byte. Wahrscheinlich Normalen. Habe ich bisher nicht benutzt.

3. Dann eine Liste von Vertices auf UV Mappings. Auf diese wird im nächsten Block verwiesen. Größe: 16Bytes * Anzahl der Mappings. Aufbau: short VertexIndex, short IrgendeineGruppierung(War ein Red Herring), signed int U, signed int V
U und V muss man durch 256 teilen um zu Pixelkoordinaten zu kommen (vom Ursprung rechts unten), und nochmal um 256 für Koordianten zwischen 0 und 1. Das erste Byte würde also 1/256el Pixel zählen, was irgendwie komisch ist, aber wahrscheinlich so ist. Vielleicht steckt hier aber noch eine weitere Info drin, (was auch komisch wäre, weil dann U V 12 Bit lang wären). U V Koordinaten können übrigends oft auch negativ sein! Die Texturen werden standardmäßig alle "gewrapped"

4. Jetzt kommen die Zeichenaufträge:
Die fangen zB. so an: [0, 4, 0, 0, 1, 0, 2, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 2, 0, 3, 0, 0, 0, 0, 0, 0, 0]
Habe das Pattern erst ganz spät entdeckt (siehe der Red Herring oben, dem hatte ich erst diese Bedeutung gegeben), aber das ist eine fixed-length Liste von Indices. Genauer gesagt zeigen diese auf verschiedene UV-Mappings. Hier soll ein 4-seitiges Polygon aus den UVMappings 0,1,2,3 gemalt werden. Das Material steht danach. Genauer: Länge: 48 Byte * Anzahl der Zeichenaufträge. Aufbau: Byte Unbekannt(oft 0 oder 16), Byte Anzahl der Elemente im folgenden Array, 15 Shorts: Jeweils ein Short für eine UVMappingIndex. (Am Ende steht komischerweise eine redundante Kopie der Indices..), es folgen 8 unbekannte Bytes, dann ein Int als Offset (in die Datei) auf das verwendete Material. Dann schließlich noch 4 unbekannte Bytes.

5. Jetzt kommen komische Materialgruppen: Größe: Anzahl Materialgruppen * 12 Byte. Int WohlIrgendeineAnzahl, int Materialoffset (vom Dateianfang), dann (vermutlich) ein Offset auf die UV-Mappings(vom UV-Mapping Offset), könnte aber (jetzt wo ich drüber nachdenke) ein Zeiger auf jede 16 Byte große Struktur sein. UV-Mappings hatten irgendwie wenig Sinn ergeben..

.PIX

Wichtig ist das 24. Byte. Dessen Wert + 40 ergibt den Start der Texturdaten. Dann width * height Byte Texturdaten (Referenz auf Pallette), immer 256*256, außer bei den Animationen. Bei denen sollte man vorher die Height und Width aus der .DSC kennen, um so die Frameanzahl (aus der Gesamtgröße - Header - Footer) und schließlich die Breite der Gesamttextur (Width * Frameanzahl). Animationsframes sind nämlich immer nebeneinander platziert. Der Footer ist immer 8 Bytes lang und genullt.

.PAL

Hier ist das  24. Byte + 41 interessant. Hier startet die Palette aus RGB0 byte Quadrupel. Das letzte Byte ist immer 0.
Wobei, wo ich das schreibe, wahrscheinlich startet es bei 24. Byte + 40 (wie .PIX) und es sind 0RGB Quadrupel.

So, das wars. Sollte man wirklich noch mal übersichtlich ins Wiki übertragen. xD

Zu meinem Viewer: Ich bezweifle, dass Hendrik und Helios hier noch regelmäßig reinschauen, deswegen werde ich u.A. einfach die beiden mit ihren Tools im Loadingscreen erwähnen.
Etwas Bammel habe ich noch vor dem Urheberrecht von Attic an den Spieldaten, da es ja als Modifikation des Programmes zählen könnte (alter Code weg, neuer Code rein), was in vielen Fällen verboten ist. Das Riva HD Remake ist ja noch nicht ganz weg vom Crafty Studios Agenda, und haben damit sicherlich ein finanzielles Interesse daran, dass kein anderes Remake erscheint. Das hat Guido sogar mal geschrieben: https://www.crystals-dsa-foren.de/showth...t#pid22045 Aber da er hier das Forum kennt, weiß was wir in diesem Thread treiben, und sich noch nicht beschwert hat, hoffe ich, dass ein HD-Viewer, der hauptsächlich als Tool zum Erkenntnisgewinn dient, urheberrechtlich ok ist. Da steht was zu in Paragraph 69 glaube © Urheberrechtsschutzgesetz dass das OK sein könnte. Aber ich verstehe leider kein Juristendeutsch.. Seid ihr da besser unterwegs, und könntet das einordnen? Wenn ich den Thread richtig in Erinnerung habe, gab es sogar mal einen nachgebauten SchickViewer, was ja recht ähnlich ist.

Also, wenns keine Einwände gibt, mache ich den Ladebalken/Credits noch fertig (bei mir lädt die Dungeons.ALF in 5-10s), und dann könnt ihr zum Wochenende mit den Binaries rechnen, um selbst mal durch alle Dungeons/Karten zu schauen.