Reverse Engineering der NLT II

[Obi-Wahn]

[Hirukan]

Ich habe ein AppImage von BrightEyes erstellt.
Diese ist speziell einfach zu installieren (herunterladen, ausführbar machen und fertig). 
Ich habe diese speziell für mein Steam Deck gemacht. Läuft aber unter jeder anderen Linux Distro genau so, da alle abhängigkeiten wie z.B. SDL 1.2 bereits in der AppImage integriert sind.

Ich möchte das gerne mit der Community hier teilen, bin mir aber nicht sicher wie ich das am besten sollte.
Ich poste einfach hier den Link und hoffe, dass die fleißigen Administratoren hier im Forum das an die richtige Stelle bringen.

https://github.com/Waldegger/Bright-Eyes...tag/v1.0.0

Zu benutzen ist das ganz einfach. Z.B.: "./Bright-Eyes.AppImage -conf ./dsa_config.conf"

Ich hoffe es bringt das Spielchen mit allen Verbesserungen auf viele Steam Decks.

Bald werde ich auch ein gutes Controller Layout veröffentlichen, aber zuerst muss ich selbst eine Weile spielen, bis ich eines habe was für mich gut und einfach funktioniert.

[Obi-Wahn]

Moin! Super Sache! Das wollte ich eigentlich schon längst mal ausprobieren, bin aber bisher noch immer gescheitert.
Eine Frage: Hast du die Dateien von BrightEyes oder von Bright-Eyes genommen? BrightEyes ohne Bindestrich ist der aktuelle Neu-Aufbau und Bright-Eyes mit Bindestrich ist der"alte" Nachbau für die DosBox.
Die Spiele-Daten der Schicksalsklinge sind nicht enthalten, oder?

[Hirukan]

Eine Frage: Hast du die Dateien von BrightEyes oder von Bright-Eyes genommen? BrightEyes ohne Bindestrich ist der aktuelle Neu-Aufbau und Bright-Eyes mit Bindestrich ist der"alte" Nachbau für die DosBox.
Die Spiele-Daten der Schicksalsklinge sind nicht enthalten, oder?

Natürlich hab ich die mit Bindestrich genommen. Ich mache einfach ein neues AppImage mit BrightEyes ohne Bindestrich. Ist ja schnell erledigt

[Hirukan]

Ach so einfach wie ich es mir gedacht habe ist das doch nicht, das GitHub Repository von BrightEyes ohne Bindestrich ist ein wenig kryptisch. Es sieht nicht so aus, dass hier noch eine DosBox erstellt wird. Auf den ersten Blick sieht es so aus, als ob da Sachen konvertiert werden und nicht unbedingt eine DosBox erstellt wird. Aber da brauche ich wohl HenneNWH um mich da reinzufuchsen was genau da passiert.

Edit: Jetzt verstehe ich es! Also ngen hab ich schon zum Laufen gekriegt. Das sind vollständige Binaries. Da hat er doch einfach die Engine nachgebaut. Sehr schön, da wird ja wirklich keine DosBox mehr gebraucht

[Hirukan]

Ja hier stecke ich ein wenig fest. Also ich habe alles so aufgesetzt dass eine DosBox mit Borland compiler gestartet wird, Die OBJ Dateien werden erstellt aber kein BIN dateien die der disassembler gerne hätte. Also für Sichsalsklinge habe ich es nicht geschafft dass eine Ausführabre Datei ausgespuckt wird

[HenneNWH]

Willkommen im Forum Hirukan,

wie ich sehe hast du dich schon etwas eingefuchst.

Kurze Erklärung:
* Bright-Eyes = DOSBox + Schicksalsklinge (gilt als veraltet und ist eher als brachiales Reverseengineering-Framework gedacht),
* BrightEyes = Schicksalsklinge/NGEN als nativer Quellcode, welcher weiterentwickelt wird und auf möglichst vielen Plattformen laufen soll

Die Schicksalsklinge ist aktuell noch nicht lauffähig, da erst ein binäräquivalenter Zustand des Projekts erreicht werden soll.
Daran arbeite ich zur Zeit. Der GCC kompiliert zwar schon mit

Code:

make -f Makefile_old

aber das Binary ist aktuell noch nicht benutzbar (Grafik, Tastatur, Maus, ...), wurde von mir aber schon am Charaktergenerator erfolgreich mit SDL2.0 umgesetzt. Geduld ist gefragt.

Der Borland-C++ Kram ist prinzipiell nur für mich zum Testen notwendig.
Um AppImages zu erstellen, sollte das für dich nicht erforderlich sein.

Wichtig: Es dürfen keine Original-Spieledateien/Audiofiles weiterverteilt werden!

Edit: Jetzt verstehe ich es! Also ngen hab ich schon zum Laufen gekriegt. Das sind vollständige Binaries. Da hat er doch einfach die Engine nachgebaut. Sehr schön, da wird ja wirklich keine DosBox mehr gebraucht

Joah, weil er es kann!    


Zwischenstand:

Hab heute herausgefunden, wie ich die Adressen von den Overlay-Funktionen so anpassen kann,
dass sie wie im Original sind. Schön ist es nicht, aber solange die Zahlen sinken ist mir das recht!

Code:

# host_read  : 173
# host_write : 0
BAE CODE     : 120
BAE OVR      : 22124

EDIT: Die globalen Variablen sind jetzt identisch zum Original!

EDIT2: @Hirukan: geh mal in src/tools und gib "make" ein und versuchs nochmal.

[Hirukan]

Hallo Henne,

vielen Dank für die Ausführliche Antwort.

EDIT2: @Hirukan: geh mal in src/tools und gib "make" ein und versuchs nochmal.

Ich habe es gemacht und die Tools sind auch erstellt worden. Auch habe ich die schick_gcc erstellt und ins Spieleverzeichnis kopiert. Ich bekomme folgende Ausgabe:

Code:

WEATHER1=5, WEATHER2=3 -> Heutige Wetter-Anpassung der Schiffs-Geschwindigkeiten: 157,5%.

Und mein armer Prozessor läuft auf 100 % und mein armer Laptop wird ganz schön heiß hahahaha. Da läuft das Schiff aber schon gescheit schnell 

Dann werde ich mich noch ein wenig Gedulden bis das alles lauffähig ist und inzwischen die Bright-Eyes DosBox benutzen, da die ja auch schon ein paar Bugfixes enthält.
Auch möchte ich eine Anleitung machen ob, und wie man die BrightEyes DosBox mit der GOG version des Spieles benutzen kann. Die haben da glaube ich ein eigenes imgmount geschrieben, das .inst Dateien als Image mounten kann, was eine übliche DosBox ja nicht kann.

Und vielen Dank für dein Bemühen. Mir ist bewusst wie unglaublich viel Arbeit Reverse Engineering ist. Besonders wenn alte Compiler benutzt wurden, die ihre ganz speziellen Eigenheiten hatten.

Achja, auch in der Bright-Eyes AppImage, da ist nur die abgewandelte DosBox und ein Icon enthalten. Also da werden keine Copyrrights verletzt.

[Obi-Wahn]

@Hirukan: Danke für die Erläuterung und den Einsatz, das AppImage zu erstellen! Ich werde es bei Gelegenheit mal ausprobieren.
Kann ich die Parameter für die ausführbare Datei und für die Konfiguration gleichzeitig anhängen? Oder was ist die beste Methode die Schicksalsklinge zu starten?

[Hirukan]

@Hirukan: Danke für die Erläuterung und den Einsatz, das AppImage zu erstellen! Ich werde es bei Gelegenheit mal ausprobieren.
Kann ich die Parameter für die ausführbare Datei und für die Konfiguration gleichzeitig anhängen? Oder was ist die beste Methode die Schicksalsklinge zu starten?

Hallo Obi-Wahn. Das AppImage reagiert wie die originale DosBox. Du kannst alles machen was die Originale DosBox auch kann. Also im Grunde tauschst du 

Code:

dosbox /pfad/zu/SCHICKM.EXE

mit 

Code:

DOSBox_Bright-Eyes-x86_64.AppImage /pfad/zu/SCHICKM.EXE

aus.

Edit: Und du kannst auch gerne die Datei umbenennen hahaha. Ist schon recht lang der Dateiname

[HenneNWH]

@Hirukan: DOS-Anwendungen wurden so programmiert als wären es die einzigen Anwendungen, die auf dem Rechner laufen. Aktuell wird die Hauptschleife des Spiels ausgeführt, welche in Ermangelung von Eingabemöglichkeiten eine Endlosschleife ist. Hab schon Mal mit dem GDB reingeguckt.

[Crystal]

DOS-Anwendungen wurden so programmiert als wären es die einzigen Anwendungen, die auf dem Rechner laufen.

Wundert einen nicht, wenn man bedenkt, dass Multitasking zu der Zeit ein Fremdwort für MS-DOS war. Der Amiga war damit schon vorausgeeilt...

[HenneNWH]

Mein Prof. für Betriebssysteme hat mal bei M$-Research gearbeitet. Dort wurden DOS und Windows (95 - ME) als Spielzeug-Betriebssysteme bezeichnet. Kerningham & Ritchie (Erfinder von C und UNIX) hatten Unix 1969 schon als Multitasking-OS entworfen.
Diese Idee hat erst mit Windows XP (2001) in den Consumerbereich erhalten.
Zum Leidwesen von 16-Bit und DOS-Anwendungen.

[HenneNWH]

Zwischenstand: Die Unterschiede werden langsam überschaubar!

Code:

# host_read   : 172
# host_write  : 0
BAE CODE      : 67
BAE OVR       : 2892

[Shihan]

Auch möchte ich eine Anleitung machen ob, und wie man die BrightEyes DosBox mit der GOG version des Spieles benutzen kann. Die haben da glaube ich ein eigenes imgmount geschrieben, das .inst Dateien als Image mounten kann, was eine übliche DosBox ja nicht kann.

Ist das ein Mac-spezifisches Ding?

Unter Win kann ich nämlich die GOG-ISO ganz normal mit

Code:

imgmount d C:\Games\NLT\riva.ins -t iso

mounten. Und da nutzen wir auch nicht die GOG-DOSBox, sondern einen eigenen Fork von cmfrydos und mir...

Zumindest für RIVA geht das ohne Probleme, würde mich aber wundern, wenn es mit SCHICK anders wäre.

[Hirukan]

@Hirukan: DOS-Anwendungen wurden so programmiert als wären es die einzigen Anwendungen, die auf dem Rechner laufen. Aktuell wird die Hauptschleife des Spiels ausgeführt, welche in Ermangelung von Eingabemöglichkeiten eine Endlosschleife ist. Hab schon Mal mit dem GDB reingeguckt.

Sind viele heutige Spiele nicht auch so programmiert? Dass die raushauen was die Grafikkarte bzw. der Prozessor hergeben? Eventuell hat die Hardware ein wenig Luft wenn vsync die Framerate etwas limitiert?

[Shihan]

Ja, durchaus. Aber sie sind als Applikationen für Multitasking-Systeme gebaut, mit Hardware-Abstraktion und im Bewusstsein, nicht die einzigen zu sein.
DOS-Applikationen hatten immer die Situation, tatsächlich die einzigen zu sein, die aktiv laufen (von Treibern und TSR-Shenanigans abgesehen).
Inklusive der nicht vorhandenen HAL ist das schon von Grundprinzip her deutlich anders, würde ich sagen.

[HenneNWH]

Das hängt ganz von der Anwendung ab. Ich bin der Auffassung, dass die Qualität eines Spiels nicht von einer hohen Framerate oder CPU-Auslastung bestimmt wird, sondern von einer guten Idee und einer guten Story. Aus meiner Sicht ist da in den Jahren wenig interessantes nachgekommen, obwohl die Technik in den letzten Jahren enorme Sprünge gemacht hat.
Die Schicksalsklingen war für einen 286 mit 16 MHz konzipiert und hat mich damals wie heute beeindruckt.
Wer die Entwicklung von Gen mitverfolgt oder dazu beigetragen hat, wird festgestellt haben, dass der Ressourcenverbrauch deutlich gesunken ist.
Mit schick_gcc wird das hoffentlich genauso werden.

[Shihan]

Die Frage nach der Qualität des Spiels in der Spieler-Rezeption ist ja eine ganz andere Frage
Hier ging es soweit ich das sehe ja nur um die softwaretechnische Ebene.

[Hirukan]

Hmm was ich meinte. Im Grunde schaut ja ein Spiel (natürlich ganz vereinfacht dargestellt) heute ja auch noch so aus oder?

Code:

while(running)
{
    process_input();
    update();
    draw();
}

Also was qualitativ in der Endlosschleife passiert hängt ja ganz vom Spiel und der Idee ab   
Aber im Grunde wenn man dem Prozessor keine Luft gibt (am Ende der Schleife ein sleep einbaut, das die Framerate drosselt oder es halt vom Grafikkarten Treiber und vsync machen lässt), dann egal wie "primitiv" das Spiel ist, es haut raus was die Hardware mitmacht oder?