Reverse Engineering der NLT

[Shihan]

So, habe weiter herumgespielt. Für die Analyse des 3DM-Formats von Riva ist es sicherlich sehr hilfreich, wenn man die Daten verändern kann. Riva entpackt ja erstmal alles, was zu einem 3D-Level gehört, in CTEMP. Dort kann man dann die Dateien manipulieren. Rauslaufen und wieder Betreten der Umgebung bringt Riva dazu, die Dateien wieder einzulesen, allerdings aus CTEMP und nicht aus DUNGEON.ALF. Das ist super, denn so kann ich an den 3DM-Dateien rumspielen und probieren, was im Spiel dann passiert.

Ein kleines Beispiel für diesen Mechanismus ist im folgenden Bild zu sehen. Da habe ich (bis auf die Baum-Textur) alle Texturdateien mit der Marmor-Boden-Textur des Boron-Schreins überschrieben. Einmal raus aus dem Boronsacker und wieder rein zwingt Riva zum Neuladen und ergibt folgendes Ergebnis:


Jetzt habe ich mal eine kleine Grid-Textur erstellt (schwarz-weiß-Schachbrett) und die als Grundlage genutzt:


Eine größere Textur war mir noch nicht möglich. Eventuell habe ich den PIX-Header falsch angepackt, oder aber Riva kann keine 512 ². Wenn das doch gehen würde, wäre einem High-Quality-Texturmod nichts entgegenzusetzen

Man kann den "Beleuchtungsmechanismus" von Riva gut sehen, besonders beim 2. Bild: Die Entfernung gibt einfach eine Helligkeitszunahme an. Das war's auch schon an Shading. Bei den Gräbern kann man das gut erkennen. Es ist noch nichtmal Gouraud-Shading, sonst könnte man die Kanten sehen. Nix, nur Helligkeit. Sehr lustig.

Immerhin ist nun klar, dass man wunderschön mit den Dateien experimentierten kann, ohne die Archive anpacken zu müssen. Das ist ja schonmal was


@HenneHW und andere Debugger-Experten:
Habt ihr schonmal probiert, mit IDApro durch die RIVA.EXE zu gehen? Es verschluckt sich beim DOS4/GW-Loader, wie mir scheint. Hat da jemand eine Idee? Würde gerne den Engine-Code ansehen, aber die Code-Analyse bricht weit vor dem eigentlichen Spiel ab.



EDIT: 2. Versuch hinzugefügt

[Shihan]

Geht auch auf anderen Maps:


Na, wer errät, wo ich da stehe?

Hier kann man übrigens das Shading auch wieder sehr gut erkennen. Nach hinten raus leicht heller und gelber. "Atmospheric scattering" im Stil der 90er

[Zurgrimm]

Na, wer errät, wo ich da stehe?

Das Haus mit dem Pultdach vorne könnte das vom Rattenfänger sein. Und daneben steht, meine ich, auch noch ein anderes Privathaus. Dahinter ist eigentlich keine Wand, sondern das Hafenbecken. Aber das ist sicher nur eine Frage der Textur, technisch gesehen ist das ja eine Wand, wo man nicht durchlaufen kann.

[Alrik Alrikson]

Ich hätte jetzt auf das Haus von Thorgrim getippt...

[Shihan]

Richtig, Alrik, das ist Thorgrimms Haus

@Zugrimm: Die Blockaden wie beim Hafenbecken werden scheinbar über wirklich unsichtbare Blöcke erzeugt, nicht durch spezielle Texturen. Zumindest vermute ich das zum jetzigen Zeitpunkt.


Bin jetzt schon ein wenig weiter in das 3DM-Format reingestiegen. Scheinbar kann man verschiedene "Groups" oder "Meshes" oder "Objects" definieren (bin mir noch nicht sicher, wie man das nennen sollte). Diese Objekte haben einen internen Namen (z.B. N_MH_CEILING in der Markthalle) und verweisen auf die ihnen zugeordnete Textur (bei o.g. Objekt wäre das dann bspw. MH1_CEIL.PIX).

Das habe ich nun genutzt, um die Texturen innerhalb einer 3DM zu ändern, nicht durch doofes Überschreiben der Texturen. Das funktioniert sogar, habe hier dem Dach in der Markhalle (o.g. Objekt) mal die Textur des Baldachins der beiden Marktstände gegeben:


So langsam komme ich dahinter. Das nächste wären dann die geometrischen Daten, die die Objekte erzeugen. Bin mal gespannt, wie hart das wird.

Bisher fühle ich mich wie ein Goldgräber

[Wetzer]

Ich schaue mir auch die Markthalle an, da es ein kleines Gebiet ist. Ich bin totaler Anfänger, was es mit Hex-Editoren und dem rausfinden von Daten betrifft. Ich habe mir deshalb die 3dm mit dem schnöden Editor angeschaut und habe folgendes (auch) rausgefunden:
Nach dem header kommen anscheinend die "3D-Objekt-Bezeichnungen" (z.B. "N_MH_CEILING"), in der Markhalle sind das 17 Stück.
Danach kommen Bezeichner in der Art "01N9999_01". Ich habe diese mal nach ersten Teil bis zum "_" sortiert und bin zu 16 unterschiedlichen Gruppen gekommen. Die größte Gruppe hat 40 Einträge.
Ich vermute, das es sich dabei um die "Flächen" der Objekte handelt.
Danach werden die Texturen aufgeführt (die Namen der pix-Dateien).

Danach kommen Daten, in denen sehr oft eine Gruppe von drei Zeichen wiederkommt (sieht wie ein seitenverkehrtes "L" aus).

Außerdem scheint es so zu sein, dass nicht alle "Objekt"-Einträge relevant sind. So gibt es Einträge die nur "N_" heißen. Das scheinen "Leichen" zu sein. Eine weitere Vermutung die das unterstützt ist, dass in der market01.dsc-Datei es Animationseinträge für eine Fackel gibt, aber man in der Markthalle keine Fackel sieht.

Ich weiß, es ist nicht viel, ich wollte es nur mitteilen. Vielleicht kann ja jemand etwas damit anfangen.

[Shihan]

Wetzer, ich glaube fast, wir beide sind die einzigen, die sich aktuell mit "Reverse-Riva" beschäftigen
Aber danke für deine Infos, das bestätigt einige meiner Gedanken.

[Lippens die Ente]

Tolles Projekt, das ihr beide ins Leben gerufen habt. Wollt ihr nur das Aussehen von Riva verändern oder auch Gebäude neu definieren?

Aber mal was anderes: Weiß jemand, wie man die Kampfbeute gezielt verändern kann? (Schick/Schweif/Riva)
ich habe schon viel rumprobiert, wo mag sie nur stecken?

[Wetzer]

Naja, vielleicht schaut ja Henne "von der anderen Seite des Codes" mal rein und gibt ein paar Hinweise.

[Helios]

@Lippens
Das steht zumindest bei Schweif in der FIGHT.LST

[Wetzer]

In der Market01.3dm gibt es 59 Einträge in der Form "01N9999_01".

Nach diesen Einträge kommen 59 Codegruppen, die durch mehrere Nullen getrennt sind.

[Alrik Alrikson]

@Lippens
Das steht zumindest bei Schweif in der FIGHT.LST

Beim Durchsehen des o.g. Artikels fiel mir auf, dass es beim Ottaskin-Kampf in Thorwal einen Runenknochen zu erbeuten geben soll, der Autor des Artikels diesen aber noch nie zu Gesicht bekommen hat.

Falls es noch von Belang ist: in der Diskettenversion gab es diesen Knochen als Beute. Habe dies zwar nun nicht jüngst nachgeprüft, aber ich bin mir absolut sicher, dass dem so ist. Manche Vorkommnisse vergisst man (warum in diesem Fall auch immer) auch nach Dekaden nicht. ;-)

[Shihan]

Tolles Projekt, das ihr beide ins Leben gerufen habt. Wollt ihr nur das Aussehen von Riva verändern oder auch Gebäude neu definieren?

Erstmal verstehen, wie was aufgebaut ist Danach kann man überlegen, ob und inwiefern man ändern kann. Bisher gehe ich davon aus, dass man zumindest funktionslose Gebäude ganz gut einbauen kann, sobald man das Format kapiert hat. Mit Funktion wird eher nichts, solange die RIVA.EXE kein Teil von BrightEyes ist

Davon abgesehen würde ich gerne einen OpenGL-Renderer dafür schreiben. Bin überzeugt, dass die Texturen bei einer etwas höheren Auflösung gar nicht mal so schlecht aussehen. Da sind ein paar dabei, die ganz gut sind. Riva hat halt kein gescheihtes Texture-Filtering.


Mein Stand der Dinge:
Habe nun die oben gesagten Dinge bezüglich der "Objects" nochmal verfeinern können. Es gibt einmal Materials, die steuern, ob eine Fläche mit Textur belegt ist oder unsichtbar ist. Das sind bspw. bei der Markthalle die 17 Stück, von denen einige als unsichtbar gekennzeichnet sind (oder irrelevante Überbleibsel, davon gibt es auch einiges, insb. in anderen Karten).
Dann gibt es Faces (die 59 bei der Markthalle). Bei beiden Gruppen habe ich auch die Zuordnung von Objekt und Name herausgefunden. Das Format ist total käsig, es wird die Anzahl der Bytes angegeben, die von Beginn der Stringtabelle an zum Zielstring zurückgelegt werden müssen. Dummerweise mit 1er Index, nicht 0-basiert. Naja, früher waren binäre Formate meist noch bescheuerter als heute

Welches Material jetzt auf ein Face geklatscht wird, ist meine nächste Frage. Das ist nicht so einfach. Muss erstmal rausfinden, was da noch an anderen Daten rumliegt. Irgendwo müssen ja auch die Vertexdaten sein. Und wenn die Debug-/Error-Strings in der RIVA.EXE stimmen, auch noch Normalen. Texturkoordinaten scheint es nicht unbedingt zu geben, die kann man auch leicht interpolieren. Sieht bescheuert aus (siehe mein Bild mit dem Baldachin an der Markthallen-Decke; da kann man es gut erkennen), aber kostet dann keine Bytes. Mal sehen...

Ja, es gibt noch viel zu tun

Ich denke, dass ich in den nächsten Tagen nochmal neue Infos ins Wiki stellen kann.


NACHTRAG:
Die 59 Dinge bei der Markthalle sind keine Faces allein, sondern scheinbar wirklich 3D-Objekte, sozusagen "Unterobjekte", die in der Map platziert wurden. Jedes der Objekte mit Namen wie 01N9999_40 o.ä. beinhaltet einen Verweis auf einen anderen Bereich in der Datei. Nimmt alle Verweise der Objekte zusammen, wird die ganze Datei abgedeckt. Das ist sozusagen der erste richtige Meilenstein. Es gibt in der Datei keine zusammenhängenden Blöcke mehr, die nicht irgendwo zu gehören. Das ist super!

Als nächstes steht also dann die Frage auf dem Plan, was innerhalb der Blöcke wohl drin stehen mag
Darum kümmere ich mich morgen.
Jetzt sehe ich alles wie Neo in der Matrix, nur in Hexcodes. Wird Zeit, den Rechner auszumachen!

[wiese.hano]

Riva hat halt kein gescheihtes Texture-Filtering.

Kann man in dem Zusammenhang überhaupt von "Texture Filtering" sprechen? Ist das nicht eher ein Begriff aus der (modernen) 3D-Grafik?

[Shihan]

Eigentlich schon. Riva ist ja 3D-Graphik. Von der Mathematik her im Endeffekt das selbe wie bspw. Crysis o.ä.

Und es nutzt auch Texturen. Die Texturen werden ja auf eine Fläche übertragen. Wenn die Fläche auf dem Bildschirm genauso viele Pixel hat wie die Textur, kann die Textur Pixel für Pixel direkt übertragen werden. Sobald auf der Fläche aber weniger oder mehr Pixel vorhanden sind, muss eine Filterung durchgeführt werden. Bei Riva ist das die einfachste, schnellste und "hässlichste" Filterung, nämlich Nearest-Neighbour. Da wird ein Pixel einfach mehrfach gezeichnet. Das sieht man, wenn man so nah an eine Wand rennt wie es irgendwie geht. Die Pixel der Textur werden dann richtig groß (mehrfach so groß wie ein wirkliches Pixel auf dem Bildschirm). Kann man hier gut sehen (übrigens die Haustür von Thorgrim )


Moderne Graphiksoftware nutzt andere Methoden der Filterung, die "weicher" und "sauberer" aussehen (in "", weil die Begrifflichkeiten natürlich auch subjektiv sind). Beispiele sind bilineare, trilineare und anisotropische Filterung. Dabei wird nicht nur der einzelne Pixel mehrfach gezeichnet, sondern eben auch seine Umgebung mit in die Berechnung einbezogen. Damit bleibt die Qualität besser erhalten.

Als Beispiel hier mal die Holztextur aus der Markhalle. Einmal, wie Riva sie rendert, einmal mit höherer Auflösung und besserem Filter:


Die Textur ist also gar nicht so schlecht. Sieht nur in 90er Technik nicht so gut aus wie sie könnte, wenn sie wollte

[Wetzer]

Der Unterschied zwischen heute und damals ist nur, dass man heute Spezialhardware im Rechner hat, die es ermöglicht, rechenintensivere Verfahren anzuwenden. Die Riva-Engine kann das aber nicht, ist also ein sogenannter SW-Renderer.

[Wetzer]

Als Beispiel hier mal die Holztextur aus der Markhalle. Einmal, wie Riva sie rendert, einmal mit höherer Auflösung und besserem Filter:

Wie bekommt du die Texturen aus der pix_-Datei?
Will haben! :-)

[Shihan]

Das ist mehr so ein Hack. Das Programm selbst ist noch nicht in einem veröffentlichenswerten Zustand
Kommt aber noch!

[HenneNWH]

Es freut mich sehr, dass sich hier so intensiv mit RIVA beschäftigt wird.
Ein Grund, warum Bright-Eyes noch kein "RIVA kann" ist tatsächlich der,
dass ich mit DOS4GW noch nicht beschäftigt habe und ich somit keine Informationen habe,
wie das Programm wirklich aufgebaut ist.

Der andere Grund ist folgender: Das Abfangen von near-calls (Funktionsaufrufe innerhalb des Segments) funktioniert nur bei den langsamen CPU-Emulationen von DOSBox. Mit diesen ist RIVA allerdings nicht spielbar.

Im nächsten Monat werde ich allerdings kaum dazu kommen etwas daran zu machen

[Rabenaas]

Ich habe eine ziemlich gute Dokumentation zur low-level-Programmierung unter DOS und DPMI. Wenn da Bedarf besteht, kann ich die gerne zur Verfügung stellen.