Reverse Engineering der NLT II

[cmfrydos]

Ja, gewissermaßen. Ziel wäre es, einige größere „UI-/Medienfunktionen“ bzw. Screens für hochauflösende Auflösungen nachzubauen. Gleichzeitig hilft mir das Nachbauen der Visualisierung dabei, den Originalcode besser zu verstehen.

Ich konnte inzwischen einiges an Code rund um die Dialoge identifizieren. Allerdings sind die Bedingungen keine einfachen gesetzten Flags, sondern ebenfalls Switch-Logik im Code: Hinter jeder ID steckt ein Case, der die entsprechende Prüfung ausführt. Die Konditionen [RVA 0x55650] sind damit quasi Prädikate (sie führen Code aus und liefern einen Wahrheitswert zurück), während die Trigger/Actions [RVA 0x56030] Code ausführen und dabei vor allem Zustände ändern.

Trotzdem gibt es definitiv einen Block an Flags [Object2 RVA 0x1bca74] in den globalen Daten, der sehr häufig eine Rolle spielt. Es lohnt sich vermutlich, diesen während der Laufzeit sichtbar zu machen bzw. zu visualisieren.

Ich habe außerdem testweise einen Libretro-DOSBox-Kern in den Viewer integriert. Lizenzrechtlich ist das allerdings nicht ganz trivial: DOSBox ist GPL-lizenziert, und je nach Einbindung könnte das Auswirkungen auf die Lizenzierung des restlichen Projekts haben. Ich muss noch prüfen, ob ich diesen Weg gehen will. Eventuell wäre es für mich aber einfacher, eine Globals-UI dort einzubauen, als mich direkt mit SDL herumzuärgern. Außerdem ließe sich so auch der Tracer vermutlich schöner darstellen und leichter bedienen.

Edit: Lizenzrechtlich dürfte es weniger problematisch sein, eine DOSBox so zu modifizieren, dass sie den Speicher des Spiels nicht als privaten, sondern als geteilten Speicher anlegt. Dann könnte ein externer Prozess wie der Viewer darauf zugreifen, ohne selbst „Teil von DOSBox“ zu werden.