Reverse Engineering der NLT

[Obi-Wahn]

Neue Version vom 27.09.2014!

Auch ich habe die DosBox/BrightEyes inzwischen bei ca. 100 Cycles laufen, zum Teil sogar unter 100. Nur das Intro stockt ein bisschen.

[Wetzer]

Nur das Intro stockt ein bisschen.

Ist das nicht eine eigene exe-Datei (INTRO.EXE) und dadurch nicht von Brigt Eyes beschleunigt?

PS: Es ist schon erstaunlich mit nur 100 Cycles zu spielen. Umso mehr vermisse ich einen Android-Port. :-D

[Obi-Wahn]

Ist das nicht eine eigene exe-Datei (INTRO.EXE) und dadurch nicht von Bright Eyes beschleunigt?

Klar, das Intro ist eine eigene Datei und wohl zusätzlich noch in einem Format, dass es nicht so einfach macht, es nachzubauen. Es fällt halt nur auf, dass das Intro mehr Power braucht.

[Lippens die Ente]

also bei mir sind die anfangs eingestellten 3000 cycles für die meisten Spiele zu wenig. Was ist denn der Vorteil einer so niedrigen Spielgeschwindigkeit?

[Wetzer]

also bei mir sind die anfangs eingestellten 3000 cycles für die meisten Spiele zu wenig. Was ist denn der Vorteil einer so niedrigen Spielgeschwindigkeit?

Naja, so einen richtigen Vorteil gibt es nicht bei den heutigen hochgezüchteten Boliden. Es zeigt nur, wieviel Power in der Dosbox-Emulation im Gegensatz zu einem nativen Port verblasen wird.

PS: Benutzt du denn Brighteyes anstatt der normalen Dosbox?

[Obi-Wahn]

Die immer weniger nötigen Cycles sind eigentlich nur der Hinweis/Beweis darauf, dass immer mehr Programmteile durch den eigenen Code von BrightEyes ersetzt wurden. Dieser neue Code läuft direkt auf Windows/Linux/... und braucht keinen rechenintensiven Emulator mehr

Dabei fällt mir noch eine Frage an Henne ein: Imitierst du eigentlich den Programmierstil von damals oder ist das überhaupt nicht mehr möglich und benutzt deinen eigenen modernen Programmierstil?

[Rabenaas]

Da Hennes Code ja binär identisch ist, kann er sich gar nicht besonders weit vom Original entfernen. Deswegen auch meine Frage nach der Skriptsprache.

[HenneNWH]

Die immer weniger nötigen Cycles sind eigentlich nur der Hinweis/Beweis darauf, dass immer mehr Programmteile durch den eigenen Code von BrightEyes ersetzt wurden. Dieser neue Code läuft direkt auf Windows/Linux/... und braucht keinen rechenintensiven Emulator mehr

Genau so ist es!

Dabei fällt mir noch eine Frage an Henne ein: Imitierst du eigentlich den Programmierstil von damals oder ist das überhaupt nicht mehr möglich und benutzt deinen eigenen modernen Programmierstil?

Hm, ich verstehe nicht ganz was Du meinst.
Durch den Identitätsvergleich sind meine Möglichkeiten schon sehr eingeschränkt.

Zum Programmieren hatte Attic die Sprachen C (kein C++) und Assembler benutzt.
Das schränkt die Möglichkeiten weiter ein.

Ob Attic Funktions- und Variablennamen auf Deutsch oder Englisch geschrieben hat weiss ich nicht.
In diesem Punkt habe ich mich für Englisch entschieden.

Weiterhin benutzte ich das Dokumentationssystem Doxygen. Attic hatte das sicherlich noch nicht.

Also: Immitieren? Ja, wenn es die, für mich naheliegende Möglichkeit ist.
Nicht möglich? Das ist es meistens, oder zumindest nicht eindeutig.
Moderner Stil? Alles was C hergibt und was die Wartbarkeit erleichtert.

[Rabenaas]

Zum Programmieren hatte Attic die Sprachen C (kein C++) und Assembler benutzt.

Ab Schweif ist es aber C++, oder?

[Lippens die Ente]

Wie weit seid ihr denn mit der Nachimplementierung der Funktionen der Schweif.exe/Riva.exe? ich habe immer hier von einem Prozentsatz gelesen, der sich nur auf die schickm.exe bezieht. Wie weit seid ihr also mit den anderen beiden Hauptdateien?

[Shihan]

Ich glaube fast, dass da noch nichts bzw. weit weniger gelaufen ist. War da überhaupt jemand dran?

Generell denke ich, dass es sehr aufwendig wird, alles modern zu refaktorieren. Gerade bei C++ hat sich in den letzten Jahren (C++11) soviel getan, was man vor 10 Jahren noch nicht dachte. Und nun noch ältere Software wird da wohl noch weiter von entfernt sein.

Henne: Mich interessiert Deine Meinung dazu! Denkst Du, es wäre nachher möglich, die Präsentation (Grafik, Menüs, Texte, etc.) und die Benutzereingaben komplett von der Spielmechanik zu trennen? D.h. mal ganz simpel betrachtet eine Art Library "DSA1-3" zu machen, die alle Spielweltdetails enthält (Karten, Charaktere, Quests, Items, Gegner, Kämpfe berechnen, ...) und dann nur von einer Präsentationsschicht ausgelesen wird? Also MVC, wobei M=Deine nachgebauten Funktionen, V/C=Ein moderner Aufsatz?
(Ich mag bei so Überlegungen immer gerne rumspinnen, also nicht ganz bierernst nehmen )


Zum Stand bei mir:
3D-Reverse Engineering schläft gerade etwas, da ich z.Z. privat und beruflich Land unter habe. Wird aber wieder besser.

[Lippens die Ente]

Ist die Technik bei Schweif (1994) und Riva (1996) wirklich so viel komplizierter als bei Schick (1992) ?

[Shihan]

Klar! Schick baut sich die "3D-Sicht" aus Bildern zusammen. Schweif und Riva sind "echteres" 3D.
(Kein Quake-3D, sondern eher 2.5D wie Duke Nukem oder Doom 1/2)

Das ist in der Herangehensweise ganz unterschiedlich. Daher wird der Code -- zumindest für die Darstellung -- weitaus komplizierter sein. Der Code für die Welt/Chars/Regeln ist wohl eher ähnlich.

[HenneNWH]

Ab Schweif ist es aber C++, oder?

Das, was ich mir bis jetzt angesehen habe, sah mir mehr nach C aus.
Die Frage ist von welchem C++ wir überhaupt reden.
Von "ersetzte printf mit cout" bis zu "Allem was sich Bjarne Stroustrup 1979 ausgedacht hat" liegen Welten.
Und nicht jeder C++-Compiler setzt die ganze C++ Spezifikation um.
Borland C++ 3.1 zum Beispiel kennt keine Namespaces.

Wie weit seid ihr denn mit der Nachimplementierung der Funktionen der Schweif.exe/Riva.exe?

Bei Schweif wurde schon ein wenig nachimplementiert: 18 von 3203 Funktionen. Das sind 0.5 Prozent.
Diese Funktionen werden aber auch noch nicht auf Gleichheit mit dem Original geprüft.

Bei Riva fehlt es noch an Grundlegenderem: dem Abfangen der Funktionen.
Riva wurde mit einem anderen Compiler Watcom C++ 10 übersetzt und benutzt den "Protected Mode".
Ich hatte mal unterwegs etwas damit herumgespielt, bin aber zu keinem befriedigenden Ergebnis gekommen.
Freiwillige vor!

Henne: Mich interessiert Deine Meinung dazu! Denkst Du, es wäre nachher möglich, die Präsentation (Grafik, Menüs, Texte, etc.) und die Benutzereingaben komplett von der Spielmechanik zu trennen? D.h. mal ganz simpel betrachtet eine Art Library "DSA1-3" zu machen, die alle Spielweltdetails enthält (Karten, Charaktere, Quests, Items, Gegner, Kämpfe berechnen, ...) und dann nur von einer Präsentationsschicht ausgelesen wird? Also MVC, wobei M=Deine nachgebauten Funktionen, V/C=Ein moderner Aufsatz?
(Ich mag bei so Überlegungen immer gerne rumspinnen, also nicht ganz bierernst nehmen )

Schwierig: Zum Teil ist eine Trennung erkennbar, manchmal ist es aber auch wieder sehr verzahnt.
Eine klare Trennung wie im Modell-View-Controller Konzept halte ich schon für erstrebenswert,
aber im Moment kann dazu noch nichts gesagt werden.

Weiss jemand von Euch wie das bei SCHICK HD umgesetzt ist?

Klar! Schick baut sich die "3D-Sicht" aus Bildern zusammen. Schweif und Riva sind "echteres" 3D.
Das ist in der Herangehensweise ganz unterschiedlich. Daher wird der Code -- zumindest für die Darstellung -- weitaus komplizierter sein. Der Code für die Welt/Chars/Regeln ist wohl eher ähnlich.

• Schick: ca. 1200 Funktionen
  
• Schweif: ca. 3200 Funktionen
  
• Riva: ???
  

[Helios]

Schwierig: Zum Teil ist eine Trennung erkennbar, manchmal ist es aber auch wieder sehr verzahnt.
Eine klare Trennung wie im Modell-View-Controller Konzept halte ich schon für erstrebenswert,
aber im Moment kann dazu noch nichts gesagt werden.

Weiss jemand von Euch wie das bei SCHICK HD umgesetzt ist?

Sofern es möglich ist, wäre eine klare Trennung gut.
Ich vermute SCHICK HD nutzt ein Component-Based System.

• Schick: ca. 1200 Funktionen
  
• Schweif: ca. 3200 Funktionen
  
• Riva: ???
  

Riva: ca. 5400 Funktionen

[Lippens die Ente]

Gibt es denn schon ein vernünftiges Programm, das die verdeckt gewürfelten Proben in Riva anzeigt? In Schick ist die Liste ja schon ellenlang, in Schweif noch dürftig und in Riva kaum vorhanden.

An Rabenaas: ich spiele die NLT unter normaler DosBox, Schick bei etwa 7000 cycles, Schweif und Riva auf cycles=auto , da brauche ich schon mehr Energie, bei Riva macht Brighteyes sogar Sinn, aber dort wurde ja nch nicht mal angefangen, deshalb scheidet Bright Eyes erst einmal aus, weil es mir keinen Nutzen bringt.

[Hendrik]

Ist das nicht eine eigene exe-Datei (INTRO.EXE) und dadurch nicht von Bright Eyes beschleunigt?

Klar, das Intro ist eine eigene Datei und wohl zusätzlich noch in einem Format, dass es nicht so einfach macht, es nachzubauen. Es fällt halt nur auf, dass das Intro mehr Power braucht.

Ja, das sind diese .ULI-Dateien, von denen wir das Format noch nicht so richtig kennen. Wenn das aber einmal entschlüsselt ist, sollte ein Nachbau der INTRO.EXE kein Problem mehr darstellen.

Wie weit seid ihr denn mit der Nachimplementierung der Funktionen der Schweif.exe/Riva.exe? ich habe immer hier von einem Prozentsatz gelesen, der sich nur auf die schickm.exe bezieht. Wie weit seid ihr also mit den anderen beiden Hauptdateien?

Wie HenneNWH schon gesagt hat, da ist noch nicht so viel. Schweif ist hauptsächlich mein Schwerpunkt, und ich bin da nicht so emsig wie HenneNWH. Ich versuche vor allem, die Datenformate nachzuvollziehen, exakte Gleichheit des Codes steht für mich momentan nicht im Vordergrund.

[HenneNWH]

Einige Neuigkeiten:

Ersetzte Funktionen (Segmente sind komplett identisch)

• seg033: Kampfmenu
  
• seg035: Kampfsystem: looting, cleanup
  

Behobene Fehler (Bright-Eyes)

• Einige BigEndian-Probleme
  

Was kommt als Nächstes?

• Code: Die restlichen sechs Funktionen des Kampfsystems
  
• Code: vermutlich noch mehr BigEndian fixes
  
• Code: reibungsloses Spielen auf ARM
  
• Doku: Skripte zur Anzeige des Fortschritts von Bright-Eyes
  
• Check: Skripte zum Vergleichen der Binärdateien (erfordert eigenen Borland C++ 3.1 Compiler)
  

Nach Erwerb eine Raspberry Pi kann ich jetzt Bright-Eyes auch auf bequem auf ARM Hardware testen.
Leider gibt es hier ein Problem im Zusammenspiel von Bright-Eyes und DOSBox, welchem ich schon auf der Spur bin.

Viel Spaß!

[Obi-Wahn]

Neue Version vom 10.10.2014!

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?

Was meinst du mit einem "eigenen" Compiler?

[Rabenaas]

Lustig. 5.5 und 1.01 gibt es zum kostenlosen Download bei Embarcadero (ehemals Borland). 3.1 nicht.