Reverse Engineering der NLT II

[cmfrydos]

So, ich konnte jetzt die fehlenden Werte (siehe Tabelle meines vorherigen Beitrags) des Unbekannten Blockes in der .3DM durch Beobachtung im Spiel entschlüsseln:

• Ersteinmal gibt es genau 2 verschiedene Beleuchtungsarten: "L"(Lichter) und "F"(Fackeln). Die Art wird durch die 3. Position im Namen mitgeteilt, wobei wenige Lichter hiervon abweichen und mit dem Präfix "Light" beginnen.
  
  
• In U1 steht die maximale Leuchtkraft, wobei die vorkommende 63 volle Helligkeit, die 44 eine mittlere Helligkeit, und 17 eine sehr sehr geringe Leuchtkraft darstellen. Siehe die .TAB Dateien im Beitrag #257, dort erstreckt sich der komplett schwarze Bereich relativ weit rein.
  
  
• Lichter beleuchten, ohne zu flackern. Dabei wird die Beleuchtung mit steigendem Abstand schwächer.
  Für Abstände =< U2 ist die Beleuchtung immer U1, dh. für dieses Licht maximal.
  Für Abstände >= U3 ist die Beleuchtung 0.
  In den Abständen [U2, U3] wird die Leuchtkraft linear auf den Bereich [U1, 0] gemappt.
  Beleuchtungen addieren sich (zB. Kaminfeuer + Stabzauber) bis maximal 63.
  
  
• Fackeln funktionieren genau wie Licht (linearer Abfall), haben darüber hinaus aber noch die Eigenschaft, dass diese flackern.
  Ich vermute, dass in zufälligen Zeiträumen überall ein kleiner konstanter Wert abgezogen wird.
  
  
• Die Lichtquellen des Spielers (Stabzauber, Flim Flam, Fackeln, etc.) funktionieren wie Fackeln, dh. flackern. Hier stehen die maximale Leuchtstärke (U1) sowie innerer und äußerer Radius (U2, U3) vermutlich in der .EXE. Die Werte zu approximieren ginge auch, aber wahrscheinlich nur mit aufwendigen Tests und Pixelzählerei
  
  
• Für den Wert den ich Light? getauft habe gilt: Aus Light? == 1 folgt immer U2==U3==0, dh. das Licht ist aus.
  

Damit sollte der bisher Unbekannte Datenblock vollständig geklärt sein, bis auf die Daten des deaktivierten Lichtes in STAR02

[cmfrydos]

Ersteinmal das, was mir auf der Zunge brennt:
Ich weiß wo in der Riva.exe die Probenwürfe stattfinden  Zumindest einige. Aber ich ahne, wie man alle finden könnte.
Was ich nicht weiß ist, ob uns das einem Logger näher bringt, oder ob mein Ergebnis vielleicht für den ein oder anderen Minutenarbeit gewesen wäre, und schon bekannt?
Das einzige was ich gerade machen kann, ist die Würfel zu zinken, aber leider nicht anzuschauen, bzw. auszugeben .. (also welcher Wurf á la aWb + c eigentlich gedacht war)

Ich, als kompletter DOS und Assembler-Noob, würde als nächstes hergehen, und versuchen, entsprechende Stellen so umzuschreiben, dass sie
a) noch funktionieren, und ich
b) auch irgendeine Ausgabe bekomme. Vielleicht kann man leicht an irgendeine Adresse schreiben, die man mittels DosBox auslesen kann.
Oder irgendwie neue Funktionen ans Ende der .exe schreiben, die man hoffentlich auch irgendwie erreichen kann, und die mir entsprechende Daten auf die Platte schreiben.

Wahrscheinlich liegt hier mit das Hauptproblem. Wollte aber trotzdem mal in die Runde fragen, ob jemand eine Idee hat, wie man hier am besten weiter machen könnte?

EDIT: Jetzt frisch ausgeschlafen, denke ich, dass ich das hinbekomme. Kompiliere gerade die DosBox, und wenn ich das richtig sehe, kann ich dort einfach den Instruction Pointer (IP) prüfen,
ob er gerade an den spannenden Stellen im Code ist, und dann die interessanten Register/Stack - Werte ausgeben. Damit sollte ich zumindest erstmal alle Würfe bekommen (dh. welcher Würfel mit welchem Ergebnis).
Als nächsten Schritt finde ich dann bestimmt in der Nähe die Stellen, an denen das Ergebnis je nach Probe mit den Charakterwerten verglichen wird, und kann auch das ausgeben.
Damit sollten wir hoffentlich bald auch für Riva einen Proben-Logger haben.

---

Der eigentliche Grund, wieso ich gerade in die .Exe schaue, ist, dass dort fast alles hart "geskripted" ist. Also was passiert, wenn man auf Feld X der Karte kommt, welcher Ausgang zu welchem Eingang führt, etc.
Daten zu letzterem habe ich schon (und ausschließlich) in der .Exe gefunden, die aber so komisch verstreut liegen, dass mir das ohne Codeverständnis leider nichts bringt.
Und die restlichen Daten aus der RIVA.ALF (also v.a. die jeweils anders kodierten .DAT Dateien), sehen leider nicht vielversprechend aus.
Also zumindest in einem Überflug konnte ich dort nichts spannendes mehr finden.
Das heißt, ich muss wohl mehr Assembler lernen..

[Rabenaas]

Mich wundert das nicht so. Bei Schick war es auch schon so, dass viel von der Logik einfach in der EXE im Code festgelegt wurde. Die Idee mit dem DosBOX-Monitor halte ich daher für ziemlich gut.

[Shihan]

Der eigentliche Grund, wieso ich gerade in die .Exe schaue, ist, dass dort fast alles hart "geskripted" ist. Also was passiert, wenn man auf Feld X der Karte kommt, welcher Ausgang zu welchem Eingang führt, etc.
Daten zu letzterem habe ich schon (und ausschließlich) in der .Exe gefunden, die aber so komisch verstreut liegen, dass mir das ohne Codeverständnis leider nichts bringt.
Und die restlichen Daten aus der RIVA.ALF (also v.a. die jeweils anders kodierten .DAT Dateien), sehen leider nicht vielversprechend aus.
Also zumindest in einem Überflug konnte ich dort nichts spannendes mehr finden.
Das heißt, ich muss wohl mehr Assembler lernen..

Wie schaust du rein? Gidhra oder IDA?

Hast du schon viele Funktionszuordnungen gefunden?

[cmfrydos]

Wie schaust du rein? Gidhra oder IDA?

Hast du schon viele Funktionszuordnungen gefunden?

Ich habe den Code über das Watcom Disassembly Tool (https://github.com/fonic/wcdatool) bekommen, und ersteinmal darin gesucht. Als ich dann fündig wurde, und quasi einen Kristallkeim (in Form der Zufallsfunktion) hatte,
bin ich mehr auf den DosBox-Staging Debugger umgestiegen, und hangel mich da anhand von Rücksprungadressen und Breakpoints durch den Code, um mehr interessantes zu finden.

Bisher konnte ich etwa 20 Funktionen verstehen, vielleicht 30, wenn man so etwas wie Bildschirmschoner und wahrscheinlich, weil in anderem Codesegment, DOS-Renderschleife mitzählt,
die ich nur identifizieren konnte, aber mich ersteinmal nicht interessieren ;D.
Das repräsentiert, wenns man großzügig schätzt, vielleicht 30 der 4083 Funktionen, und etwa 500 der 44109 Funktionsaufrufen.
Hauptsächlich verstanden habe ich bisher nur 3 Würfelfunktionen, 4 Probenfunktionen(und unterfunktionen), 9 EW/TW/ZW Getter/Setter/Adder und eine GebeIndexVonElementInListe Funktion

Fürs Auge hier mal ein schon stark eingedampfter Jump&Call Graph mit über 100tsd Kanten und 50tsd Knoten (Sprungstellen), wobei die blauen Kanten Funktionsaufrufe sind, und die schwarzen alle bedingten Sprünge respräsentieren.

   
Meine gefundenen Funktionen sind noch nichtmal in einem größerem Cluster, also in Richtung eines Riva-BrightEyes wäre das leider nur ein Tropfen auf heißem Stein..

[Tiefhusen]

Ersteinmal das, was mir auf der Zunge brennt:
Ich weiß wo in der Riva.exe die Probenwürfe stattfinden  Zumindest einige. Aber ich ahne, wie man alle finden könnte.
Was ich nicht weiß ist, ob uns das einem Logger näher bringt, oder ob mein Ergebnis vielleicht für den ein oder anderen Minutenarbeit gewesen wäre, und schon bekannt?

Auch wenn ich mit meinen dürftigen IT-Kenntnissen leider keine Hilfe zu diesem Projekt beisteuern kann, wollte ich nur kurz zum Ausdruck bringen, wie sehr ich mich freue, dass es offensichtlich schon Fortschritte auf dem langen Weg zum Riva-Logger gibt! Das wäre echt der Hammer, wenn dieser eines Tages einmal Wirklichkeit werden sollte!!! 

[cmfrydos]

Auch wenn ich mit meinen dürftigen IT-Kenntnissen leider keine Hilfe zu diesem Projekt beisteuern kann, wollte ich nur kurz zum Ausdruck bringen, wie sehr ich mich freue, dass es offensichtlich schon Fortschritte auf dem langen Weg zum Riva-Logger gibt! Das wäre echt der Hammer, wenn dieser eines Tages einmal Wirklichkeit werden sollte!!! 

Das ist er schon . Ich warte gerade nur noch ab, ob ich vielleicht noch etwas an der Geschwindigkeit, und der Bedienungsfreundlichkeit schrauben kann.

Habe den Logger in einen eigenen Thread verlagert: https://www.crystals-dsa-foren.de/showth...p?tid=6059

Wenn da ein Kenner Ideen und Vorschläge zu beisteuern kann, würde ich mich freuen.

---

Ich bin gerade ziemlich happy, weil das was ich mir gerade in den Kopf gesetzt habe, wohl leichter ist, wie gedacht.

Hier ein paar Teaser. Wer mit weniger Infos errät, an was ich gerade arbeite, kriegt einen .

Spoiler

   

Spoiler

Man sieht, ich bin noch nicht ganz fertig..

Spoiler

   

Spoiler

Natürlich am Ende über geteilten Arbeitsspeicher..

Spoiler

https://www.crystals-dsa-foren.de/showth...#pid132650

nur anders herum

Spoiler

   

Spoiler

   
So ungefähr soll dann das Endresultat aussehen. Vielleicht muss man dann nochmal an die 3D Daten und ein paar Löcher flicken, die low-res wohl nie aufgefallen sind.

[cmfrydos]

https://www.crystals-dsa-foren.de/showth...#pid132612 :

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.

Mich verwirrt das Shading. Wenn man sich genau umguckt, kann man uA. Gouraud erkennen, aber eben noch mehr.
Leider ist dein Bild offline, daher kenne ich das dortige Setting nicht.

Die Lichtquelle der Gruppe kann ich noch einigermaßen erklären. Am Tag lüftet diese den Nebel, bei Nacht erhellt es die Karte. Das spielt nur Distanz eine Rolle.
Habe ich in meiner 3D Engine mit einer Depth-Map realisiert.

Kompliziert wird es z.B bei den auf den Karten platzierten Fackeln. Meine Verwirrung lässt sich am Leichtesten anhand von Bildern erklären.
Erst einmal ein Wireframe, damit man eine Idee bekommt, wo die Polygone liegen. Ich habe die Ecken der hier interessanten Flächen mal farblich markiert.
   
So, und als nächstes dann wie es im Original aussieht. Nicht wundern, ich habe hier das Zeichnen von Billboard"ähnlichem", wie z.B Animationen deaktiviert,
deshalb sieht man hier die Flamme nicht. Der aktuelle Held trägt keine Lichtquelle (wobei die Gruppe von sich aus auch immer etwas strahlt, aber sollte hier keinen Effekt haben).
Die grobe Position des Lichtes habe ich mal markiert.
   
Ich kann mir das nur erkären, wenn die Beleuchtung aus der Summe zweier verschiedener Algorithmen basiert.

a) Ganz deutlich sieht man eine Art kugelförmige Aura um das Zentrum der Lichtquelle. Ich verstehe nur nicht, was hier benutzt wurde. Ich würde ShadowMaps nehmen, aber gab es das schon 1997? Oder ist das einfach Per-Pixel Lighting?
b) Wenn man das Wireframe kennt, sieht man zusätzlich Per-Vertex Lighting, also wohl Gouraud-Shading. Es fällt nämlich auf, dass hinter der Lichtquelle kein Vertex ist, und es dort auch unerwartet (bzw. nach Per-Vertex dann doch erwartet) dunkel ist. Das Licht strömt vielmehr von den Ecken der Wand auf die Fackel zu. Man sieht sogar recht deutlich die Kante zwischen den beiden Wandpolygonen (Aufgrund der unterschiedlichen Distanz zu den entsprechenden Vertices). Das wohl auch ein Gouraud-Algorithmus in der .exe steckt, lässt sich auch daran sehen, dass "Gouraud" in einem String der .exe vorkommt. 

Das Resultat der Beleuchtung ist ganz klar ein Mix aus Beidem - da man beides sieht. Ich habe nur keine handfeste Idee, wie der 'Halo' realisiert wurde. Ich kenne mich dafür mit den verschiedenen Shading Algorithmen nicht genug aus. Und warum wurde Gouraud überhaupt mit in die Gleichung eingebracht? Reines Per-Pixel Lighting (wenn es das denn ist), sollte dem Mix ja überlegen sein.

Normalen spielen übrigends auch eine Rolle. Hier mal die Feuerstelle aus der ersten Ebene des Magierturms. Dass die linke Wand hier leuchtet, kann man ignorieren, dort ist einfach eine weitere Lichtquelle.
Aber die Wand vor einem liegt ganz klar im Schatten der Feuerstelle.
   

@Shihan, ich glaube du kennst dich mit der Thematik besser aus. Bestätigungen, oder Erklärungen würden mir sehr helfen. Natürlich auch von anderen.
Würde das Licht in meiner Engine gerne so nah wie möglich zum Original implementieren.

Edit: Zum Halo Effekt habe ich eine Idee. Man bestimmt den Schnittpunkt der an die Leuchtquelle angelegten Normale mit dem zu einer Ebene erweiterten Face. Ich weiß gar nicht, ob man per-Face Informationen an den Pixel-Shader weitergeben kann, sonst macht man es notfalls für alle drei Vertices, wobei jeweils das selbe herauskommt. Anhand des Schnittpunktes, der Position des Pixels, und ggbfs. der Größe des Face, kann im Pixelshader der Halo-Glow erzeugt werden. Gibt man noch mit, ob der Schnittpunkt vor, oder hinter der Lichtquelle liegt, kann man bestimmen, ob das Face im Schatten liegt. Dieses Procedere macht man für jede Lichtquelle, den Spieler eingeschlossen.
Keine Ahnung, ob das der echte Algorithmus ist. Aber der sollte ziemlich nah an den Effekt im Spiel herankommen.