Reverse Engineering der NLT

[HenneNWH]

Das schreit nach einem Kommandozeilenargument.

Wohl eher nach einer kryptisch-esoterischen Konfigurationsdatei, über die der Nutzer gänzlich im unklaren gelassen wird. Im Ernst:

Meine Idee ist, in der dosbox.conf eine neue Section für "Bright Eyes" anzulegen.

Dort könnten die z.B. Abfrage und einige LOG-Meldungen ein- und ausgeschaltet werden.
Auch die Namen von einigen OGG/FLAC-Dateien, welche man direkt abspielt,
anstatt mit dem BIN/CUE Image rumzuwurschteln.

Wenn DOSBox, und damit auch die dosbox.conf, nicht mehr benötigt wird ,
kann diese Section in eine eigene Datei (brighteyes.conf) welche mit einer tollen GUI bearbeitet werden kann.
Oder dem Texteditor der Wahl.

Ich habe übrigens Schick mit BrightEyes durchgespielt.

Sehr gut! Baust Du auch immer brav dein "Bright Eyes" aus dem aktuellen Repo?

[Rabenaas]

Baust Du auch immer brav dein "Bright Eyes" aus dem aktuellen Repo?

Äh, nein. Seit dem Questfehler nicht mehr. Wie oft pushst Du eigentlich?

[HenneNWH]

Wie oft pushst Du eigentlich?

Sooft es geht. Wenn ich zu Hause bin pushe ich fast täglich.
Ein git pull lohnt sich also vor jedem Zocken.

Die Bugs die ich gemacht hab werden schnellstmöglich behoben (Bugfix),
Bugs aus dem Original (Original-Bugfix) werden behoben sobald ich eine gute Lösung gefunden habe.
Bis jetzt sind 2 Original-Bugs gefixt: Die Reaktivierung von Umbrik Siebenstein durch den Dialog mit den Reitern
und (neu) die tägliche Artefaktanalyse in der Schule der Hellsicht.

[d.rhotert]

Hallo..

Ist es mit diesem Patch/Programm endlich möglich alle in der NLT verwendeten Talente zu identifizieren?

Und wenn ja, gibt es irgendwo schon eine Liste mit der man eine Übersicht hätte, welche Talente WIRKLICH steigerungswürdig sind?

Das wäre ja mal ein Hammer..

MfG, D.R.


*edit: Ich würde das Spiel gerne weiterhin ohne diesen Patch spielen und trotzdem endlich Gewissheit haben (nach 20 Jahren ), was tatsächlich zur Anwendung kommt und was nicht.
Das wäre eine fantastische Erleichterung beim Talente-optimieren..

[HenneNWH]

Hi D.R.

die Proben werden nur in dem Moment angezeigt, in dem sie geprobt werden. Wenn du wirklich alle Proben von Schick wissen willst, dann musst du noch warten bis alle Quests, Dungeons und Dialoge rekonstruiert sind. Wie gesagt, von Schick.

[Obi-Wahn]

Ich habe da mal eine Verständnisfrage. Was ist BrightEyes jetzt genau? Ein Nachbau von Schick-Bestandteilen, die fest mit einer modifizierten DosBox verbunden sind? Bleibt BrightEyes also immer noch "nur" ein Dos-Programm, dass in irgendeiner Form einen Dos-Emulator benötigt?

Edit: Hier gibt's einen sehr interessanten Vortrag von Henne. Besonders um die Minute 6:00!
Edit2: Im Video wird meine Frage beantwortet: Im Idealfall keine Dosbox mehr

[Gaddezwerch]

Hey, tolle Sache das! Wieso gibt's den Link erst von dir und nicht schon von Henne? :-)

Schön präsentiert und als Zusammenfassung sehr interessant und es waren echt ein paar coole Sprüche dabei

[Obi-Wahn]

Der Verweis steht schon im DevBlog...

[HenneNWH]

Der Verweis steht schon im DevBlog...

Super!
Als ich das letzte Mal auf die Vortragsseite geschaut habe war das Video noch nicht online.

Als kleine Zwischeninfo: Gen.exe ist jetzt bei 58%

[thEClaw]

Habe mir gerade deinen Vortrag angeschaut, von mir aus hättest du noch ordentlich in die Tiefe gehen können . Ich frage mich schon seit einiger Zeit, wie genau du eigentlich vorgehst. Hast du das schonmal irgendwo erläutert oder könntest du das nachholen? Mich würde interessieren, wie genau die eine Funktion ersetzt: Verfolgst du da den disassemblierten Code und schreibst ihn später in C (oder was auch immer) um? Schaust du, was eine Funktion "bewerkstelligt" und ersetzt das dann, ohne Zeile für Zeile des ASM-Codes zu verstehen?
Bist du bei dieser Art des Reverse-Engineerings stark an die Programmstruktur des ursprünglichen Programms gebunden? Mir scheint, dass du dich quasi auf Schienen bewegen musst und dir somit bestimmte Möglichkeiten zur Verbesserung des Programmes versagt sind.
Könntest du irgendwo sinnvoll Hilfe beim Disassemblieren gebrauchen?

58% - das heißt, du hast 58% (in Anzahl) der Funktionen ersetzt, richtig? Klingt schon sehr beeindruckend, auch wenn vermutlich noch ein paar Koloss-Funktionen bevorstehen .

[Kunar]

Den Zwölfen zum Gruße!

Hier gibt's einen sehr interessanten Vortrag von Henne. Besonders um die Minute 6:00!

Es ist doch immer wieder interessant, wer sich hinter einem Pseudonym verbirgt. Wenn man die Leute in natura erlebt, stellt man fest, dass sie sehr sympathisch sind.

Großartig, wie das Forum und die Spiele kommentiert wurden! Und herrlich, im Rahmen eines Informatik-Vortrags zu sehen, wie "Die Schicksalsklinge" aufgerufen und ein wenig gespielt wird.

Was ich besonders faszinierend finde: Dass die Entwicklung Schritt für Schritt vollzogen werden kann, so dass man auch mit dem jetzigen Stand von "58% aller Funktionen ersetzt" einfach spielen kann.

[Hendrik]

Im Übrigen habe ich letztes WE, inspiriert durch den Vortrag, angefangen, nach dem gleichen Prinzip Sternenschweif aufzurollen. Ich war damals ja bei den Overlays steckengeblieben. Da HenneNWH dafür aber eine Lösung gefunden hat, konnte ich relativ schnell ein paar Funktionen ersetzen. Jetzt räume ich nur noch den Code etwas auf und dann kommt es ins Repository. Fortschritt: geschätzte 0.5%, aber das wird sich bald ändern ...

[Obi-Wahn]

Da bin ich ja mal gespannt.

[Crystal]

Kompliment an HenneNWH für den Vortrag. Ich habe mir eben mal Zeit genommen, das Video zu sehen und bin beeindruckt von der Präsentation - und dem bisschen Schleichwerbung für uns.

Alles in allem sehr gut gelungen, bravo! Und für meine Begriffe auch sehr verständlich erklärt. Bezüglich der letzten Frage, ob Bright Eyes denn auch auf künftigen DOSBox-Versionen laufen wird, hoffe ich ebenfalls, dass die DOSBox-Entwickler deinem Eingriff offen gegenüber stehen werden.

Der Unterschied zwischen 3000 Cycles auf Original-Speed und den 400 Cycles auf Bright Eyes ist ja wirklich enorm.

[HenneNWH]

Im Übrigen habe ich letztes WE, inspiriert durch den Vortrag, angefangen, nach dem gleichen Prinzip Sternenschweif aufzurollen. Ich war damals ja bei den Overlays steckengeblieben. Da HenneNWH dafür aber eine Lösung gefunden hat, konnte ich relativ schnell ein paar Funktionen ersetzen. Jetzt räume ich nur noch den Code etwas auf und dann kommt es ins Repository. Fortschritt: geschätzte 0.5%, aber das wird sich bald ändern ...

Super! Das freut mich.
Nimmst Du die Diskettenversion "V1.00" von der Du die IDA Datei erstellt hast?
Wäre es nicht besser, wenn Du eine aktuelle Version von Schweif nimmst, die die Spieler aus dem Forum haben und nebenbei beim spielen auch testen können?
Da finde ich die aktuellste CD-Variante am angebrachtesten, da sie, glaub ich, am weitesten verbreitet ist.

Frag mal lieber bei potentiellen Nutzern nach.

BTW, ich habe jetzt herausgefunden, wie man aus eigenem C-Code wieder den Emulator aufrufen kann,
z.B. wenn man das calloc() aus der Borland-C Lib aufrufen möchte.
Somit ist ist man auch nicht mehr gezwungen bei den Low-Level Funktionen anzufangen.

Das Zauberwort ist CALLBACK_RunRealFar().
Hier sind zwei Beispiele.

Kompliment an HenneNWH für den Vortrag. Ich habe mir eben mal Zeit genommen, das Video zu sehen und bin beeindruckt von der Präsentation - und dem bisschen Schleichwerbung für uns.

Ohne dieses Forum als Anlaufpunkt und Motivationsquelle wäre wir ja auch gar nicht soweit gekommen.

Alles in allem sehr gut gelungen, bravo! Und für meine Begriffe auch sehr verständlich erklärt. Bezüglich der letzten Frage, ob Bright Eyes denn auch auf künftigen DOSBox-Versionen laufen wird, hoffe ich ebenfalls, dass die DOSBox-Entwickler deinem Eingriff offen gegenüber stehen werden.

Dankesehr, da ich dazu schon ein fachlich korrektes Paper geschrieben hatte, wollte ich beim Vortrag,
der mit 30 min relativ kurz eingeplant war, möglichst einfach und verständlich das Prinzip erläutern.
Schön, dass es geklappt hat.

Du meinst sicher, ob "DOSBox custom" von den DOSBox Devs angenommen wird?
BrightEyes (ehem. FreeDSA) soll ja später ohne DOSBox laufen.
Das ist ja u.A. Sinn und Zweck der ganze Aktion.

[thEClaw]

Ich würde die CD-Version von DSA2 auch bevorzugen, allerdings sollten die Unterschiede ja auch recht klein ausfallen. Und vielleicht hat die Diskettenversion andere Vorzüge... (zumindest wird es doch irgendwo eine Versionsgeschichte geben, mit der die Patches nachgeahmt werden können, sodass dann nur noch die CD-Musik fehlt)

Übrigens: Geschrieben wurden die Spiele doch in C++, oder? Allerdings vermute ich mal, dass der von euch rekonstruierte Code reines C ist bzw. komplett ohne Klassen auskommt? Das stelle ich mir in etwa so vor:

[Rabenaas]

Nein, Schick ist noch in C geschrieben. Siehe hier

[HenneNWH]

Der Compiler der ersten beiden Teile ist Borland C++ 3.1, welcher C und C++ übersetzen kann.
Schick wurde in C (und etwas Assembler) geschrieben.
Laut dem Interview mit Guido sollte in Schweif C++ genutzt worden sein, aber das kann vieles bedeuten.
Streams, Objekte,...?
Hendrik wirds raus finden.

[Luigi]

Nein, Schick ist noch in C geschrieben. Siehe hier

Damals hat Commodore auch noch stolz berichtet, dass AmigaOS 2.xx jetzt praktisch keinen BCPL-Code mehr enthält, sondern umgeschrieben wurde mithilfe von C. Nix C++
Schreib das nur, weil ich damals jung war und mich für Programmiersprachen interessierte. So Modula-2, vorher natürlich das ultra-schnelle Amiga-Basic aber ohne Zeilennummern

Nach meiner verklärten Jugenderinnerung würde ich sagen, dass Guy Henkel und seine Mannen in punkto Programmiersprachen dem normalem Trend entsprachen.
Ich glaub, dass lag einfach auch an der Hardware.

Erzähl doch mal Raabenaas! So vor 20 Jahren...

PS: Sorry für meinen Spam-Post, aber eine starke Nostalghia hat mich dazu übermannt

[Rabenaas]

Erzähl doch mal Raabenaas! So vor 20 Jahren...

Ähm, einen Schwank aus meiner Jugend? Damals war alles - anders. Und ich war - kleiner. Ach ja, die Mauer war gerade gefallen und im Fernsehen gab's Alles Nichts Oder?! und im Radio spielten Roxette.

Oder beziehst Du das auf Programmiersprachen?

Da Schick auch auf dem Amiga lief, kann es eigentlich nur in C programmiert sein. C war damals fest etabliert, und galt als schnell und vor allem portabel. Der C++ Hype kam gerade ins Rollen, allerdings vornehmlich nur auf PCs und Workstations.

Es stimmt, dass damals Pascal-Abkömmlinge wie Modula-2 und Oberon beliebt waren. Allerdings habe ich den Eindruck, dass das eher bei Hobby- und PD-Programmierern der Fall war. Eine Zwischenstellung nahm Basic ein, das mit eingestreuten Assembler-Routinen seit langem professionell eingesetzt wurde. Actionspiele wurden vielfach noch in reinem Assembler programmiert.

EDIT: Übrigens war C meine erste Programmiersprache. Und ich mag sie noch immer...