Reverse Engineering der NLT II

[cmfrydos]

Ihr habt natürlich Recht, ich meinte Raycasting. Ein einzelner Strahl reicht,

Muss ja nicht durch Mandaras Spiegel die Welt untersuchen .

Das Reverse Engineering ist durchaus in Europa (im Gegensatz zur USA) für Forschungszwecke ausdrücklich erlaubt. Und genau das ist der Hintergrund für mich gewesen, weil ich wissen wollte, wie eine 3D-Engine, die Integers anstatt Floats verwendet, wohl funktioniert

Engine Reimplementation ist da leider etwas undurchsichtiger, einfach, weil das dazu bisher wenig Präzedenzfälle gibt. Aber wie oben gesagt, solange man niemandem auf die Füße tritt, sollte einiges möglich sein.

Wenn man es als Forschung betrachtet, denke ich auch, dass es rechtlich ok ist - immerhin lüften wir hier den ein oder anderen Nebel, und teilen unsere Ergebnisse: 

• In den .TAB Dateien stehen Mappings von allen 256 ColorCodes auf jeweils 64 ColorCodes (oder wie man die nennt ). Damit wird die Beleuchtung realisiert.
  Wenn man die ColorCodes über die Palette auflöst, kommt zum Beispiel so etwas raus: RIVA01.TAB
  
     
  
  Auf der X-Achse sieht man alle Farben der Palette, und jeweils darunter Abwandlungen davon, je nach Lichtlevel. Auf den Außenkarten (Riva, Boronsacker, Umland, Magierturm Sumpf und Garten, aber auch blau Unterwasser) bewirkt es den bekannten Schleier.
  Ich habe es mal so interpretiert, dass die Y-Achse die "Lichtintensität" darstellt, und diese damit auf offenen Karten, bei Tag, mit steigender Distanz zunimmt . Anders kann ich mir das hier nicht erklären: SEWER01.PAL:
  
     
  
  In Leveln ohne Tageslicht sieht das immer ähnlich aus, dass es hier oben Rabenschwarz ist.
  Diese Verläufe erklären z.B. wieso das Rathaus bei mir rot war, in Riva aber (aus normaler Distanz) bräunlich aussieht.
  => Wer keine Lust hat, alle paar Stunden mit einer Nicht-Magiebegabten Gruppe Fackeln zu verbraten - schaut euch diese Dateien an
  

• In den .PPD Dateien wird es jetzt lustig. Was passiert draußen bei Nacht? Zu Sonnenaufgang und -untergang beobachtet man in Riva ein Schauspiel, dass man beim normalen Spielen nicht oft zu sehen bekommt.
  Es wird allmählich immer heller, bzw. immer dunkler. Um das zu Realisieren haben die Entwickler aus meiner Sicht etwas geklotzt:
  20 Helligkeitsverläufe (wie die .TAB formatiert). Und jeder Verlauf hat seine ganz eigene Palette .
  Dateiheader sind 8 Bytes und dann folgen 20x (1024 Bytes (4 Byte pro Farbe) Palette, direkt dahinter 16.384 Bytes (256*64px) an Helligkeitsverläufen, und dann 10 Bytes an noch unbekannten Daten).
  
  Ich traue mich nicht, hier alle zu posten, wollte aber erwähnen, dass die Farbverläufe ab einem bestimmten Stand ('Uhrzeit') von dem "nebligen" in den "dunklen" Verlauf umspringen, bzw. umgekehrt.
  Hier zB. Riva bei Nacht:
  
     
  
  
• Nachfolgend noch ein paar Impressionen zum Licht aus meinem Engine Nachbau. Ich habe hier zum Vergleich ein paar Szenen aus dem Original mit meinem Viewer verglichen.
  https://www.youtube.com/watch?v=397DfR-tBs8
  

Die Erkenntnisse zum Licht haben mir ziemlich die Nerven geraubt. Dass hier die Texturdaten X-Indizes innerhalb des aktuellen Helligkeitsverlaufes sind (Y kommt vom Grad der Beleuchtung), die dann wiederum die Indizes von den RGB-Farben sind, macht u.A. sinnvolles Mipmapping und Lineares/Anisotropes Samplen quasi unmöglich.
Aber ich fande es mega spannend zu sehen, wie "Shading" unter DOS funktioniert haben könnte. Heute versteht man unter Shader den Code, der auf der Grafikkarte ausgeführt wird, aber ich denke mal dass man damals VGA-Karten nur ganz rudimentär ansprechen konnte  Da scheint mir dieses mehrfache Nachschlagen von ColorCodes, um Beleuchtung zu realisieren, doch recht smart.

Als nächstes schaue ich mir mal an, ob ich die (externen) Lichter als Lichter in der .3DM identifizieren kann, und probiere mich damit mal an neuen Shadern.