Reverse Engineering der NLT II

[NewProggie]

Ich hab es mal auf SDL3 portiert eben, so dass es fehlerfrei kompiliert, aber man sieht leider (noch) nichts :-)

[Obi-Wahn]

Super! Danke für die Umsetzung! Schade, dass es nicht vollständig geklappt hat.

[HenneNWH]

Noch eine kleine Statusmitteilung: Die Aufspaltung ist erfolgt!
Das Verzeichnis src/gen_dos ist ab heute für reine Rekonstruktionsarbeiten gedacht,
im Verzeichnis src/gen wir der Charaktergenerator weiterentwickelt und auf einen aktuellen Stand gebracht.

Zur Einstimmung habe ich die Version auf V1.06 erhöht, ein paar Altlasten entfernt und den Dateien aussagekräftige Namen verpasst.

[Obi-Wahn]

Wow, da hast du aber bis spät in die Nacht dran gearbeitet! 

Für mich ist es echt interessant, welche Wege und Entscheidungen du hier gehst und triffst! :-)

Edit: Auch die neue Version läuft.

[HenneNWH]

Schön, dass dir das auffällt, Obi-Wahn.

Ich habe beschlossen, weiterhin die best möglichsten Entscheidungen zu treffen (nicht nur für Bright[-]Eyes).
In den letzten Jahren habe ich sehr abenteuerliche Erfahrungen machen müssen,
einmal als Lehrer/pädagogischer IT-Koordinator während der Pandemie und einmal als Softwareentwickler in einem weltweit agierenden Softwareunternehmen.
Mehrmals wurde ich schwer enttäuscht und bin froh wieder konzentriert dieses Projekt weiter nach vorn zu bringen und sowohl meine konservative- als auch meine progressive Seite ausleben zu können.

Konservativ (bewahren) bedeutet in diesem Fall, das was war für die Nachwelt möglichst dokumentarisch aufzubereiten.
Dafür ist gen_dos gedacht. Damit sollte man in nicht alzuferner Zeit alle 5 DOS-Versionen vom Charaktergenerator ansehen und mit dem BCC bauen können.
Dieses Programm ist mit seinen 10k Zeilen klein genug um sich schnell einzuarbeiten und alles was für Spieleprogrammierung notwendig ist ansatzweise verstehen zu können.
Umsetzten, Changelog schreiben, fertigstellen und Haken ranmachen.

Meine progressive Seite möchte natürlich genau eine funktionstüchtige Version weiter pflegen, welche als Desktopanwendung auf aktuellen Rechnern läuft,
meinen Anforderungen an moderner Softwareentwicklung entspricht und die Seele dieses Spiels in der Form, welche Attic ihm gegeben hat, weiterhin aufrechterhält.
Ich habe mit 15 Jahren mit programmieren angefangen und kann sagen, dass sich in den letzten 30 Jahren vieles getan hat und vieles existiert was für ein professionell betriebenes Softwareprojekt aus meiner Sicht ein Muss ist. (Dokumentation, Testen, Portabilität: mit Linux heute einfach umsetzbar, wenn man weiß was gut ist).

Die NLT ist deshalb für mich interessant, weil dort hervorragendes Storytelling in den Grenzen der damaligen Zeit umgesetzt wurde.
So eine Spieltiefe findet man heute eher selten (Ultima 4-8, Drakensang 1+2, Satinavs Ketten & Memoria, Baldurs Gate, Planescape Torment).
Für mich ist die NLT ein absoluter Klassiker, deshalb hab ich dieses Projekt gegründet.
Für die internationalen Klassiker gibt es mit: SCUMMVM, GemRB, Xoreos ähnliche Projekte.
Weiterhin habe ich mit 27 Jahren beschlossen nicht mehr soviel zu spielen,
sondern meine Fähigkeiten und mein Fachwissen zu nutzen um genau so etwas umzusetzen und einen Blick hinter die Kulissen zu werfen.
Damit geht für mich zwar etwas von der damaligen Illusion kaputt, aber ich kann sagen: Es lohnt sich. :-D

[HenneNWH]

Kleine Zwischenmeldung:
* Die englische Version V3.00 ist gestern komplett binäräquivalent nachgebaut worden.
* Im Anhang ist noch ein kleines Video von BrightEyes auf einem RaspberryPi (32-Bit, ARM Prozessor, Linux ohne GUI).
   Das hat DOS-Feeling, nur mit einem richtigen Betriebssystem. ;-)
* Mit SDL2 hab ich außerhalb von BE auch Fortschritte gemacht und denke, dass in den nächsten Tagen noch ein paar Überraschungen auf euch warten.

[HenneNWH]

Noch eine kleine Zwischenmeldung:
* Der Clang-Compiler hat auf meinem Raspi1 mit Standardoptionen keinen korrekten Code für diesen Prozessor erzeugt.
Darum hab ich meinen Raspi2 reaktiviert und siehe da, es geht.
* Aktuell arbeite ich gerade an der Version V1.04 des Charaktergenerators.
Dieser unterscheidet sich von den aktuelleren Versionen durch eine andere Soundbibliothek zum abspielen von AWS-Dateien (Audios Wave Slave).
Die beiden fertigen Versionen (GEN105DE und GEN300EN) benutzen das Miles Sound System (AIL) zum Abspielen von XMIDI-Dateien.
Das war damals sehr beliebt, da sehr viele verfügbare Soundkarten unterstützt wurden.
* Mit SDL2 habe ich ein kleines Testprogramm geschrieben, welches ein beliebig großes Fenster erzeugt und Mausklicks innerhalb des Fensters auf einen Bereich von 320x200 Pixeln
abbildet. Ein paar Tastaturabfragen sind auch dabei und es funktioniert alles wie es soll.

* Zur Version G300EN:
* Es existiert kein Audio-CD Support (obwohl dieses Spiel auf CD ausgeliefert wurde),
* Es gibt ein paar Unterschiede beim Bildschirmlayout (wo steht welcher Text),
* Das Gewicht des Helden / der Heldin wird in Fuß und Inches angezeigt, aber wie in der deutschsprachigen Version gespeichert,
* Im Intro wird das "Realms of Arkania" Logo anstelle des "schwarzen Auges" angezeigt.

[HenneNWH]

Hello Again:
Es gibt wieder ein kleines Video!
Setup: RaspberryPi2 über VNC, Clang und eine englische DSAGEN.DAT welche seit eben unterstützt wird.
Viel Spaß!

[Obi-Wahn]

Und bei mir läuft BrightEyes auf dem Steam Deck. ;-)

   

[siebenstreich]

Aktuell zeigt es mir an, dass sich nur noch 12/52336 Bytes (< 0,02 %) im Code vom Original unterscheiden.
Besser geht es meinerseits nicht mehr. Die restlichen 12 Byte im Audio-CD-Teil haben jedoch dieselbe Funktionalität.
MISSION COMPLETE

Glückwunsch! Was ist denn mit den 12 verbleibenden Bytes, warum geht das nicht besser? Ist davon auszugehen, dass auch Attic hier mit Assembler-Code gearbetet hat?

Ausgehend von dem aktuell angepeilten Status des Projekts habe ich folgenden Plan gefasst:
Die Version G105de ist die umfangreichste von den 5 verschiedenen Versionen des Charaktergenerators.
Mit dem Quellcode von dieser sollte es ein Leichtes sein, auch die anderen 4 Versionen zu rekonstruieren
und ähnlich wie jetzt mit dem BCC diese Binaries für DOS zu bauen.
Damit wäre dem historischen Teil des Charaktergenerators meiner Ansicht nach genüge getan.
=> Ab ins Archiv.

Für die perfekte digitale Denkmalpflege fehlt mir in dieser Liste irgendwie noch der Aspekt, den Quellcode möglichst verständlich zu machen.
Also das Herausarbeiten der Programmlogik, so dass der (mitunter etwas krude) originale Code möglichst gut gelesen und verstanden werden kann, beispielsweise:

• Variablen und Funktionen passend benennen nach einem konstistenten Schema.
  
• "magic numbers" durch benannte Konstanten ersetzen (also z.B. g_hero.skills[TA_SCHWERTER] anstelle von g_hero.skills[3]).
  
• Höhere Datenstrukturen (structs) einführen, soweit es die Binär-Äquivalenz zulässt.
  
• Nicht offensichtliche Programmlogik kommentieren.
  
• Insbesondere: Bugs und sonstige Dubiositäten dokmentieren.
  
• Soweit es ohne übermäßigen Aufwand funktioniert: Optional zuschaltbare Bugfixes, so dass idealerweise mit dem BCC eine dem umfassenden Bugfix-Patch ebenbürtige Version der Schicksalsklinge erzeugt werden kann.
  

(Die letzten beiden Punkte sind eher für die SCHICKM.EXE gedacht und für die GEN.EXE hoffentlich irrelevant, aber wer weiß.)

Der Test auf Binär-Äquivalenz ist bei solchen Änderungen (abgesehen von Bugfixes) eine sehr mächtige Absicherung, dabei nicht versehentlich etwas kaputt zu machen. Zumindest ist die Erfahrung aus meinen Versuchen, den Bright-Eyes-Code der Schicksalsklinge dahingehend weiterzubringen.

Noch eine kleine Statusmitteilung: Die Aufspaltung ist erfolgt!
Das Verzeichnis src/gen_dos ist ab heute für reine Rekonstruktionsarbeiten gedacht,
im Verzeichnis src/gen wir der Charaktergenerator weiterentwickelt und auf einen aktuellen Stand gebracht.

Beeindruckend, mit welch großen Schritten es hier vorangeht. Durch die Aufspaltung ist jetzt aber die Situation eingetreten, dass Änderungen vom oben aufgelisteten Typ eigentlich parallel in beiden Versionen gemacht werden müssten.
Beispiel: In diesem Commit wurden einige Dinge im "modernen Teil" mit treffenderen Bezeichnern belegt.
Henne, hast du vor, solche Umbenennungen auch nach gen_dos rückzuportieren? Ich fände das sehr gut.

Zur Einstimmung habe ich die Version auf V1.06 erhöht, ein paar Altlasten entfernt und den Dateien aussagekräftige Namen verpasst.

Wenn man sich nicht ganz genau auskennt, drängt sich bei V1.06 der Eindruck auf, dass dass Attic doch noch eine neuere Version produziert hatte.
Meiner Meinung nach wäre für BrightEyes eine unabhängige Versionsnummerierung besser.
Z.B. BE1.0 (BrightEyes 1.0) oder V1.05BE1 (Die auf V1.05 basierende BrightEyes Version 1) oder so.

[Obi-Wahn]

Ich bin gerade mit Windows unterwegs und da habe ich noch eine Frage. Ist es eigentlich jetzt schon möglich, den Code unter Windows zu kompilieren und wenn ja, was ist dazu nötig? gcc und sdl?

[HenneNWH]

Geile Sache!
Aus technischer Sicht ist das zwar erstmal dasselbe wie auf einem herkömmlichen Linux-PC,
aber ich finde es großartig, dass Valve sich dafür einsetzt,
dass Linux mit diesem Gerät weitere Verbreitung erfährt und die Spiele- und Windowssituation weiter verbessert wird.
Und ich finde es großartig, dass du BrightEyes auf diesem Gerät ausprobiert hast,
erfolgreich warst und mir auch noch etwas Neues zeigen konntest.

Hab mir damals ein Nokia N900 gekauft (Smartphone mit Debian) um Bright-Eyes auf einem echten ARM-Prozessor zu testen.
Leider hat sich das Gerät am Markt nicht durchsetzen können, aber mit dem Raspi2 bin ich zufrieden.

Hab heute noch etwas den Code von der ngen.c umstrukturiert, damit ich weiß wo ich am Besten irgendetwas sinnvolles einbauen kann.
Das Fenster wird jetzt nach dem Zeichnen jedes Buchstaben aktualisiert. Das macht das Ganze erstmal etwas langsamer, dafür können jetzt Infoboxen für Debuggingzwecke benutzt werden. :-D

[HenneNWH]

Glückwunsch! Was ist denn mit den 12 verbleibenden Bytes, warum geht das nicht besser? Ist davon auszugehen, dass auch Attic hier mit Assembler-Code gearbetet hat?

Nope, das ist genau eine Zeile in C. Damit muss ich leben! :-D

Für die perfekte digitale Denkmalpflege fehlt mir in dieser Liste irgendwie noch der Aspekt, den Quellcode möglichst verständlich zu machen.

Also das Herausarbeiten der Programmlogik, so dass der (mitunter etwas krude) originale Code möglichst gut gelesen und verstanden werden kann, beispielsweise:

• Variablen und Funktionen passend benennen nach einem konstistenten Schema.
  
• "magic numbers" durch benannte Konstanten ersetzen (also z.B. g_hero.skills[TA_SCHWERTER] anstelle von g_hero.skills[3]).
  
• Höhere Datenstrukturen (structs) einführen, soweit es die Binär-Äquivalenz zulässt.
  
• Nicht offensichtliche Programmlogik kommentieren.
  
• Insbesondere: Bugs und sonstige Dubiositäten dokmentieren.
  
• Soweit es ohne übermäßigen Aufwand funktioniert: Optional zuschaltbare Bugfixes, so dass idealerweise mit dem BCC eine dem umfassenden Bugfix-Patch ebenbürtige Version der Schicksalsklinge erzeugt werden kann.
  

(Die letzten beiden Punkte sind eher für die SCHICKM.EXE gedacht und für die GEN.EXE hoffentlich irrelevant, aber wer weiß.)



Der Test auf Binär-Äquivalenz ist bei solchen Änderungen (abgesehen von Bugfixes) eine sehr mächtige Absicherung, dabei nicht versehentlich etwas kaputt zu machen. Zumindest ist die Erfahrung aus meinen Versuchen, den Bright-Eyes-Code der Schicksalsklinge dahingehend weiterzubringen.

Vorerst arbeite ich an der neuen Version und hab heute sehr große Umbauarbeiten gemacht und interne Abhängigkeiten minimiert um vorzubereiten wo ich am Besten etwas bewirken kann. Das hat schon viel gebracht.

Beeindruckend, mit welch großen Schritten es hier vorangeht. Durch die Aufspaltung ist jetzt aber die Situation eingetreten, dass Änderungen vom oben aufgelisteten Typ eigentlich parallel in beiden Versionen gemacht werden müssten.

Beispiel: In diesem Commit wurden einige Dinge im "modernen Teil" mit treffenderen Bezeichnern belegt.

Henne, hast du vor, solche Umbenennungen auch nach gen_dos rückzuportieren? Ich fände das sehr gut.

Wenn es am Generator "nichts mehr zu tun gibt" und alles soweit verstanden ist, werden dann auch die alten Versionen entsprechend aktualisiert. Dort muss aber weitestgehend alles so bleiben wie es ist.

Wenn man sich nicht ganz genau auskennt, drängt sich bei V1.06 der Eindruck auf, dass dass Attic doch noch eine neuere Version produziert hatte.

Meiner Meinung nach wäre für BrightEyes eine unabhängige Versionsnummerierung besser.

Z.B. BE1.0 (BrightEyes 1.0) oder V1.05BE1 (Die auf V1.05 basierende BrightEyes Version 1) oder so.

Joa, aber erstmal als Arbeitsversion bin ich zufrieden.

[HenneNWH]

Ich bin gerade mit Windows unterwegs und da habe ich noch eine Frage. Ist es eigentlich jetzt schon möglich, den Code unter Windows  zu kompilieren und wenn ja, was ist dazu nötig? gcc und sdl?

Das hab ich nicht probiert. Da ich kein Windows kann, aber das Projekt in reinem C-Code geschrieben ist nehme ich an, dass es theoretisch möglich ist.
Zeit hab ich da noch nicht rangesetzt. Ich nehme an ein C-Compiler und die SDL2 sollten reichen.

[Obi-Wahn]

Geile Sache!
Aus technischer Sicht ist das zwar erstmal dasselbe wie auf einem herkömmlichen Linux-PC,
aber ich finde es großartig, dass Valve sich dafür einsetzt,
dass Linux mit diesem Gerät weitere Verbreitung erfährt und die Spiele- und Windowssituation weiter verbessert wird.
Und ich finde es großartig, dass du BrightEyes auf diesem Gerät ausprobiert hast,
erfolgreich warst und mir auch noch etwas Neues zeigen konntest.

Hab mir damals ein Nokia N900 gekauft (Smartphone mit Debian) um Bright-Eyes auf einem echten ARM-Prozessor zu testen.
Leider hat sich das Gerät am Markt nicht durchsetzen können, aber mit dem Raspi2 bin ich zufrieden.

Hab heute noch etwas den Code von der ngen.c umstrukturiert, damit ich weiß wo ich am Besten irgendetwas sinnvolles einbauen kann.
Das Fenster wird jetzt nach dem Zeichnen jedes Buchstaben aktualisiert. Das macht das Ganze erstmal etwas langsamer, dafür können jetzt Infoboxen für Debuggingzwecke benutzt werden. :-D

Ich habe das Steam Deck letztlich auch geholt, weil es mit Linux läuft. 

Und noch eine Gerät: Ubuntu 24.04 auf einem Raspberry Pi 5. 
   

Ich bin gerade mit Windows unterwegs und da habe ich noch eine Frage. Ist es eigentlich jetzt schon möglich, den Code unter Windows  zu kompilieren und wenn ja, was ist dazu nötig? gcc und sdl?

Das hab ich nicht probiert. Da ich kein Windows kann, aber das Projekt in reinem C-Code geschrieben ist nehme ich an, dass es theoretisch möglich ist.
Zeit hab ich da noch nicht rangesetzt. Ich nehme an ein C-Compiler und die SDL2 sollten reichen.

Mal gucken, ob und was ich da zusammen bekomme. :-)

[HenneNWH]

Habs gerade meinen Kids vorgeführt. :-D Und Guido Henkel hat das letzte Video von mir auch bekommen. ;-)