Reverse Engineering der NLT

[HenneNWH]

Hier noch ein paar Patches:

Behobene Fehler (Bright-Eyes)

• Abstürze bei AE-Verlust im "3D-Modus"
  

Sonstiges

• Benutzung von Namen für einige globale Variablen für bessere Lesbarkeit (z.B. CURRENT_TOWN statt 0x2d63)
  

Der behobene Fehler war übrigens der besagte Fehler, welcher mir auf ARM aufgefallen ist.
Auf allen anderen Prozessoren (x86, x86_64, PPC) ist dieser Fehler auch aufgetreten.

Viel Vergnügen!

Auf die ARM-Version bin ich gespannt! Dann muss ich doch mal glatt den Raspberry Pi meines Vaters klauen! Wie weit wäre der Schritt dann noch zu einer Android-Version?

Gute Frage! Gibt es denn hier im Forum potentielle NLT-Androidnutzer?

Eine Androidversion könnte man vermutlich relativ einfach bauen,
indem man den DOSBox-Quellcode in einem funktionierenden und quelloffenen DOSBox-Port (z.B. aDOSBox)
durch den Bright-Eyes Quellcode ersetzt und das ganze dann baut.

Ich habe gerade versucht aDOSBox mit dem aktuellen Andriod NDK zu bauen, aber das Bauen bricht leider ab.

Mir fehlt dafür allerdings die Zeit um eine Androidversion zu pflegen.
Interessenten bitte vortreten.

Was meinst du mit einem "eigenen" Compiler?

Aus Lizenzgründen darf ich doch keine Kopien verteilen.
Desshalb muss jeder Entwickler seine eigene Version vom "Borland C++ 3.1" Compiler besitzen,
wenn er diese Vergleichstests durchführen möchte.

[Obi-Wahn]

Neue Version vom 17.10.2014!

Ich hätte da diverse Android-Geräte mit denen ich das ausprobieren könnte. Es wäre allerdings eher ne Spielerei als eine echte Anwendung.

[NewProggie]

Guten Abend,

ihr meint nicht zufällig sowas wie das hier, oder?

http://www.crystals-dsa-foren.de/showthr...p?tid=3079

[Obi-Wahn]

Nein, nicht ganz. Es soll ähnlich laufen wie auf dem PC. Die aDosBox soll nur noch die Teile von Schick übernehmen, die von BrightEyes noch nicht ersetzt worden sind. Gerade auf den Android-Geräten, die noch nicht so viel Rechenleistung "über" haben, sollte sich da eine Geschwindigkeits- oder besser "Geschmeidigkeits-"Verbesserung zeigen.

Ich habe gerade versucht aDOSBox mit dem aktuellen Andriod NDK zu bauen, aber das Bauen bricht leider ab.

Vermutlich braucht man da noch die Android/ARM-Variante von SDL, oder? (Vielleicht das hier?)

[HenneNWH]

Nein, nicht ganz. Es soll ähnlich laufen wie auf dem PC. Die aDosBox soll nur noch die Teile von Schick übernehmen, die von BrightEyes noch nicht ersetzt worden sind. Gerade auf den Android-Geräten, die noch nicht so viel Rechenleistung "über" haben, sollte sich da eine Geschwindigkeits- oder besser "Geschmeidigkeits-"Verbesserung zeigen.

Genau so ist es.

Vermutlich braucht man da noch die Android/ARM-Variante von SDL, oder? (Vielleicht das hier?)

Das ist nicht nötig.
Bei aDOSBox sind alle benötigten Bibliotheken im Quellcode dabei, also auch SDL.
Das Android NDK baut den ganzen C++ Code in eine neue Bibliothek. (Habe jetzt Version 5b probiert, damit ging es.)

Diese Bibliothek wird dann von der JAVA-App, welche mit dem SDK gebaut wird aufgerufen.
An dieser Stelle hänge ich gerade fest.

[Obi-Wahn]

Viel Erfolg!

[Wetzer]

Hi NLT-Freunde,
was machen denn die verschiedenen SW-Projekte? Sommer ist vorbei und Wetter wird ideal zum programmieren.

[HenneNWH]

Bright-Eyes macht große Fortschritte:

Der Kampfmodus ist jetzt vollständig nachgebaut.
Gerade bastle ich an ein paar Gebäuden von Phexcaer.

Ich teste Morgen meine Version nochmal und werde morgen wieder mal releasen.
Dann mit genaueren Infos.

[HenneNWH]

Einige Neuigkeiten:

Wie schon im letzten Beitrag erwähnt: das Kampfsystem läuft jetzt komplett auf dem Hostrechner.

Ersetzte Funktionen (Segmente sind komplett identisch)

• seg043: Kampfaktionen von Monstern ausführen
  
• seg042: Kampfaktionen von Helden ausführen
  
• seg032: Kampfsystem: Kampfrunde, gesamter Kampfablauf
  
• seg097: GUI Elemente: Textboxen, Popup-Menus
  
• seg028: Fileloader: Karten, NPCs, besondere Texturen, Dialoge, Kampfhintergründe
  

Ersetzte Funktionen

• seg070: Phexcaer: Fuhrhaus, Stadthaus, Spielhaus, Villa Gremob
  

Behobene Fehler (Bright-Eyes)

• Programmabbruch beim Öffenen von Schatztruhen
  
• Zauberanimationen in Kämpfen an der falschen Stelle
  
• Weitere BigEndian-Probleme (aber noch nicht alle)
  

Fehler aus dem Original

• Fehldeutung des Glücksspielergebnisses in Phexcaer
  
• Kaputter Dialog im Stadthaus
  
• Tippfehler in der "Saft, Kraft, Monstermacht" Meldung
  

Dokumentation:

• Doxygen-File (zum Erzeugen der Dokumentation)
  
• details.html (Übersicht über den Fortschritt der Bright-Eyes Entwicklung)
  

Was kommt als Nächstes?

• Check: Skripte zum Vergleichen der Binärdateien (erfordert eigenen Borland C++ 3.1 Compiler)
  
• Weitere Arbeiten an Phexcaer
  

Statistik:

• Es sind 762 von 1236 Funktionen sind nachgebaut (61,65%).
  
• Davon sind 702 identisch mit dem Originalcode.
  

Die Fortschrittsmessung anhand der Anzahl der Funktionen ist manchmal ein wenig irreführend.
Es gibt Funktionen, die in der SCHICKM.EXE sehr viel Platz wegnehmen.
Der Maschinencode für das Menu im Kampfsystem ist z.B. über 6KB groß (mehr als 1% der SCHICKM.EXE).
Andere Funktionen sind dagegen winzig.
Das macht sich auch in der Bearbeitungszeit bemerkbar.

Desshalb habe ich noch eine alternative Metrik zu Messen des Bright-Eyes Fortschritts,
welche die Größe des fertigen Maschienencodes ins Verhältnis zum Maschinencode in der SCHICKM.EXE setzt.
Der folgende Wert ist noch etwas kleiner als der Tatsächliche, da ich im Moment nur komplett fertige Segmente zähle:

Nach der Byte-Metrik ist der Code von SCHICK schon zu 71,91% fertig.
Das klingt doch schon viel besser.

Viel Spaß!

[Shihan]

Henne, großartig! Wieviel Cycles brauchst Du mittlerweile? Oder anders: Wie wenige sind es noch?

@Wetzer:
3DM schläft z.Z.
Habe zwar einen kleinen OpenGL-Viewer geschrieben. Dabei sind mir aber noch ein paar Unstimmigkeiten aufgefallen. Die Face-Zuordnung stimmt nicht ganz. Was falsch ist, weiß ich aber noch nicht. Habe gerade auch -- trotz Winter -- wenig Zeit dafür.
Schaue aber immer mal wieder rein. Hoffentlich kommt da bald der Heureka-Moment.

[Wetzer]

@Wetzer:
3DM schläft z.Z.
Habe zwar einen kleinen OpenGL-Viewer geschrieben. Dabei sind mir aber noch ein paar Unstimmigkeiten aufgefallen. Die Face-Zuordnung stimmt nicht ganz. Was falsch ist, weiß ich aber noch nicht. Habe gerade auch -- trotz Winter -- wenig Zeit dafür.
Schaue aber immer mal wieder rein. Hoffentlich kommt da bald der Heureka-Moment.

Sehr Schade.
Wäre es möglich, dass du deine bisherigen Arbeiten veröffentlichst, damit man darauf aufbauen kann?

[Obi-Wahn]

Neue Version vom 20.11.2014!

Der Kampf funktioniert grundlegend. Angreifen, Magie usw... Mehr habe ich noch nicht getestet.

[Rabenaas]

Das lesbar machen ist ja eigentlich klassisches Refactoring. Hat sich schon mal jemand Gedanken darum gemacht, mit welchen Tools sich das unterstützen ließe? (z.B. Eclipse)
Damit könnte man ja eigentlich jetzt schon anfangen, oder?

Der Kampf funktioniert grundlegend. Angreifen, Magie usw... Mehr habe ich noch nicht getestet.

War never changes ... :d

[Shihan]

Sehr Schade.
Wäre es möglich, dass du deine bisherigen Arbeiten veröffentlichst, damit man darauf aufbauen kann?

Naja, außer dem Text in der Wiki und dem Viewer gibt es nichts, was ich da veröffentlichen könnte. Und der Viewer ist bisher so geschrieben, dass ich den nicht veröffentlichen möchte. Zu dreckig, um es mal anders zu sagen

Aber wie gesagt, ich denke, die Zeit kommt wieder.

[HenneNWH]

Henne, großartig! Wieviel Cycles brauchst Du mittlerweile? Oder anders: Wie wenige sind es noch?

Also wenn man eine leicht verzögerte Startphase in Kauf nimmt,
in der DOSBox das CD-Image mountet und die SCHICKM.EXE startet,
kann man Schick mit 100 Cycles flüssig spielen.

Das lesbar machen ist ja eigentlich klassisches Refactoring. Hat sich schon mal jemand Gedanken darum gemacht, mit welchen Tools sich das unterstützen ließe? (z.B. Eclipse)
Damit könnte man ja eigentlich jetzt schon anfangen, oder?

Ich lese parallel die Wikipedia Seite zu Refactoring.
Einige Änderungen können gemacht werden, andere noch nicht.

Was ist im Moment möglich:

• Lesen und nachvollziehen des Quelltextes
  
• Fehler im Original melden / beheben (als ORIGINAL_BUGFIX)
  
• Ändern der Symbolnamen von lokalen Variablen z.b. signed short l_di; signed short l1;
  
• Ändern der Symbolnamen von Funktionen z.B. void seg044_02a()
  
• Ersetzen von Adressen im Datensegment durch Präprozessorkonstanten z.B ds_readbs(0x2d67) => ds_readbs(CURRENT_TOWN)
  
• Schreiben von Doxygen-Kommentaren für Funktionen
  
• Ändern des alten Kommentarstils in Doxygen-Kommentare
  

Die Borland-C-Version des Quelltextes darf nicht in ihrer Funktionalität geändert werden,
da ich bei jedem Commit automatisch den Quellcode mit dem BCC kompiliere und prüfe ob dergleiche Binärcode rauskommt.
Ist das nicht der Fall wird der Commit nicht zugelassen.

Unit-Tests wären schön, aber ich hab noch keine Idee wie und womit diese umgesetzt werden können.

[HenneNWH]

Einige Neuigkeiten zun Nikolaus :

Der Code von der Spezialgebäude von Phexcaer ist komplett nachgebaut.

Ersetzte Funktionen (Segmente sind komplett identisch)

• seg070: Phexcaer Spezialgebäude 1/2
  
• seg071: Phexcaer Spezialgebäude 2/2
  
• seg073: Taverne: Gerüchte,
  
• seg120: Misc: Tollwutanfall, Spielinititalisierung, Game-Over-Screen, Starten von GEN.EXE
  

Ersetzte Funktionen

• seg050: Steigerung: Erhöhen von Zauberfertigkeiten im Fortgeschrittenenmodus
  

Behobene Fehler (Bright-Eyes)

• Falsche Speicherzugriffe beim Freigeben von EMS-Speicher (tritt nie auf)
  

Dokumentation:

• Aktualisierung details.html (Übersicht über den Fortschritt der Bright-Eyes Entwicklung)
  

Was kommt als Nächstes?

• Check: Skripte zum Vergleichen der Binärdateien (erfordert eigenen Borland C++ 3.1 Compiler)
  

Statistik:

• Es sind 774 von 1236 Funktionen sind nachgebaut (62,62%).
  
• Davon sind 716 identisch mit dem Originalcode.
  
• Byte-Metrik: 74,51% des Codes sind nachgebaut.
  

Anmerkungen zu Phexcaer:
Die vollständige Umsetzung dieser Stadt scheint dem frühen Releaseterm in zum Opfer gefallen zu sein.

Fragt man im Fuhrhaus oder im Spielhaus nach Alrik Derondan, so trifft man ihn in der nächsten Taverne in Phexcaer.
Im Gespräch mit Ihm führen die Antwortfolgen 1->3->1 oder 3->1 dazu, dass eine Variable im Spielstand gesetzt wird,
welche allerdings nirgendwoanders abgefragt wird.

Hier tritt somit das gleiche Problem auf, wie bei der Verabredung mit der Prostituierten.

Viel Spaß!

[Obi-Wahn]

Neue Version vom 07.12.2014!

[Rabenaas]

Bin gerade über eine interessante Bibliothek gestolpert. Was haltet ihr von der Idee, ein Backend für die DATs in physicsfs zu schreiben?

[Hendrik]

Ja, Physicsfs...

Wenn ich dich recht verstehe, möchtest du (langfristig) die Lade-Routinen der 3 NLT-Teile durch Aufrufe von PhysicsFS ersetzen, so dass ich die Archivdateien auch ungepackt verwenden könnte? Geht durchaus, aber das ist eher etwas für den "dritten Schritt", nachdem die Spiele vollständig rückübersetzt und lesbar gemacht worden sind.

Was mich beim Schreiben von nltpack an den NLT-Archiven am meisten gestört hat ist, dass es durchgehend keine "echten" Archivformate sind - man kann jeweils nur bestimmte Dateien speichern. Für die SCHICK.DAT sind das genau die Dateien, die in der SCHICK.EXE am Ende stehen, für Schweif die Dateien aus der jeweiligen .FN, und Riva hat zwar theoretisch sogar Unterverzeichnisse, praktisch hingegen sind die Archive (bzw. der Code in der RIVA.EXE) recht empfindlich gegen eine solche "universelle" Nutzung. Daher hatte ich mich auch für das - zugegeben nicht besonders nutzerfreundliche - Bedienkonzept mit den .FN-Dateien entschieden.

EDIT: Ein PhysicsFS-Backend hätte, als Bibliothek verstanden, natürlich auch andere Einsatzmöglichkeiten: nutzerfreundliche Reimplementationen von nltpack, Nutzung in Editoren, Nachbau der NLT (statt RevEng), ...

[Rabenaas]

Wenn ich dich recht verstehe, möchtest du (langfristig) die Lade-Routinen der 3 NLT-Teile durch Aufrufe von PhysicsFS ersetzen,

Ja

so dass ich die Archivdateien auch ungepackt verwenden könnte?

Jein, über PhysicsFS kann man ja (soweit ich das verstehe) z.B. auch auf Zips zugreifen. Insofern würde die Bibliothek u.a. den Zugriff auf die Ressourcen als Middleware vereinheitlichen und transparent machen. (Ent-)Packer, Editoren und Spiele könnten über den selben Code auf die Archive wie auf normale Verzeichnisse (und umgekehrt) zugreifen und bräuchten sich nicht mehr mit den Details auseinandersetzen.

Geht durchaus, aber das ist eher etwas für den "dritten Schritt", nachdem die Spiele vollständig rückübersetzt und lesbar gemacht worden sind.

Stimmt.