Reverse Engineering der NLT

[Hanbastan]

Pascal, C, C++... hehe... in sowas habe ich noch Programmieren gelernt... achja ich habe mir den Vortrag jetzt auch mal angesehen - Henne, du hättest Lehrer werden sollen ... könntest direkt bei uns anfangen

[Luigi]

...
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.
...

Danke für deine Ausführungen
Du hast schon recht mit Modula-2 und Oberon.
Ich glaub ich such mir jetzt noch mein Turbo-Pascal 7.10, Pascal for Windows?, Delphi! und schau, ob sie sich noch installieren lassen.

Aber zum Thread: Super-Ding was ihr hier durchzieht!
Ich war ja bei DOSBOX mit "Schatten über Riva" mit dem Programm DOSIDLE schon hellauf begeistert.
Geschweige denn, was ihr hier für einen radikalen Ansatz habt.

[Sannah]

Oy, hier passiert ja glatt noch mal was...

Was passiert eigentlich mit den Lizenzen, nachdem JoWooD jetzt die Hufe hoch gemacht hat? Wäre doch mal ne Anfrage wert ob man die für nen Appel und nen Ei im Falle der NLT bekommen könnte...

Hab gerade ne Menge mit UFO:Aftershock in Sachen Modding zu tun, ebenfalls noch ein bissi im Wizardry7 und für Biing!1 sollte ich auch noch ein paar wenige Grafiken pixeln, damit das Projekt auch abgeschlossen ist. Freue mich jedenfalls auch hier über Ergebnisse!

[thEClaw]

Gute Frage, das mit den Lizenzen. Haben die Jowood komplett gehört? Wen müsste man fragen, wenn man sie kaufen wollte?

[Rabenaas]

Ich glaub ich such mir jetzt noch mein Turbo-Pascal 7.10, Pascal for Windows?, Delphi! und schau, ob sie sich noch installieren lassen.

Nimm lieber das hier oder das hier.

Gute Frage, das mit den Lizenzen. Haben die Jowood komplett gehört? Wen müsste man fragen, wenn man sie kaufen wollte?

Ich vermute mal, die liegen weiterhin bei Jochen Hamma, und JoWood hatte sie nur lizenziert.

[HenneNWH]

...Henne, du hättest Lehrer werden sollen ... könntest direkt bei uns anfangen

Wo oder wer ist uns Bist Du Lehrer?

Hab gerade ne Menge mit UFO:Aftershock in Sachen Modding zu tun, ebenfalls noch ein bissi im Wizardry7 und für Biing!1 sollte ich auch noch ein paar wenige Grafiken pixeln, damit das Projekt auch abgeschlossen ist.

Was genau machst Du denn beim modden? Gibt es da eine Community oder machst Du das "nur" für dich?


Kennt von euch jemand OpenDune.
Die Entwickler haben einen Decompiler benutzt, der wärend des Spielens Emulator-Quellcode erzeugt.
Dieser ist dann compilierbar und wird mit einer selbstgeschriebenen Emulationsbibliothek (libemu) betrieben.
Jetzt bauen die Devs jede einzelne Funktion von Emu-C in richtiges C um.

Die automatische Codeerzeugung ist schon sehr toll, da sich damit weniger Fehler einschleichen können.
Leider gibts den Decompiler (noch?) nicht zum Download.
Und die Taktfrequenz kann auch nicht gedrosselt werden. 100% CPU-Last für Dune2 ist imho etwas viel, aber wenn der Code ohne Emu läuft werden die Devs sicher auch daran schrauben.
Auf jeden Fall haben die auch schon ca 50 Bugs und Unschönheiten gefixt.

[thEClaw]

Wow. Ich dachte, dass es wenigstens um das erste Dune-Spiel ginge. Aber das zweite? Wo doch danach unzählige Spiele erschienen, die in jeder Hinsicht besser waren? Nicht, dass Dune II schlecht gewesen wäre, aber in Sachen Komfort kann es meiner Meinung nach mit keinem anderen Spiel mithalten - jeder Nachfolger hat das Konzept genommen und deutlich erweitert. Ich habe kaum vier Missionen des Spieles geschafft, bevor mich das viele Geklicke, das nötig war, wahnsinnig gemacht hat.
Aber naja, vermutlich spricht irgendwo auf diesem Planeten auch jemand* so abschätzig über meine Lieblingsspiele.

*=Verkriech dich in irgendeinem Loch, bevor ich dich finde und dir die Fingernägel pink lackiere!

[Rabenaas]

jeder Nachfolger hat das Konzept genommen und deutlich erweitert

Das haben die ersten ihrer Art so an sich.

[thEClaw]

jeder Nachfolger hat das Konzept genommen und deutlich erweitert

Das haben die ersten ihrer Art so an sich.

Natürlich. Aber im Kontext einer aufwändigen "Neuentwicklung" würde ich mich nicht unbedingt an diesem ersten Testlauf orientieren, sondern mir ein ausgereifteres Produkt vorknöpfen.
Doofes Spiel.

[Rabenaas]

No more Pong for you.

[thEClaw]

No more Pong for you.

Da liegst du aber grundfalsch! Habe mir sogar mal ein eigenes programmiert, habe also stets Zugriff! (habe den Netzcode leider nie perfektioniert)
Pong ist auch nicht unbedingt ein Spielprinzip, dass man wieder und wieder aufgreifen, erweitern und verbessern kann. Insbesondere kann man es nicht kopieren und mit 'ner anderen Story versorgen um es als völlig neues Spiel zu verkaufen - mit einem Dune II-Nachfolger ginge das problemlos.
Damit ist also der Beweis erbracht, dass Dune II und Pong nicht vergleichbar sind . Falls du das gar nicht aussagen wolltest und ich dich missverstanden habe...auch egal.

[Hendrik]

Hier ist ja richtig was los! Darum jetzt ein langes Multiquote:

Im Übrigen habe ich letztes WE, inspiriert durch den Vortrag, angefangen, nach dem gleichen Prinzip Sternenschweif aufzurollen.

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.

Ja, das ist die Version von der IDA-Datei, die ich vor längerer Zeit mal erstellt habe. Ich habe aber gar nicht die Diskettenversion. Bist du sicher, dass diese "O1.00" nicht die CD-Version ist? Die Sprungpunkte haben jedenfalls bisher mit meiner CD-Version (vermutlich aus Goldgames 1) funktioniert.

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.

Kann man dieses Paper irgendwo lesen, oder ist das noch nicht veröffentlicht?

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.

Werde ich das? Ich weiß ehrlich gesagt noch gar nicht, wie man am Assemblercode C und C++ auseinanderhalten kann, geschweige denn, wie ich den Assember-Code von IDA in C++ übersetzen soll. Ich glaube, ich übersetze das erst einmal in C und schaue dann, wo ich Objekte verwenden kann.

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?

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

Mein erster Kontakt mit C war "C--", eine obskure Mischung aus C und Assembler. Davor habe ich, wie die meisten in den 90ern, mit Basic und "Turbo-Kalle" angefangen.

Kennt von euch jemand OpenDune.
Die Entwickler haben einen Decompiler benutzt, der wärend des Spielens Emulator-Quellcode erzeugt.
Dieser ist dann compilierbar und wird mit einer selbstgeschriebenen Emulationsbibliothek (libemu) betrieben.
Jetzt bauen die Devs jede einzelne Funktion von Emu-C in richtiges C um.

Die automatische Codeerzeugung ist schon sehr toll, da sich damit weniger Fehler einschleichen können.
Leider gibts den Decompiler (noch?) nicht zum Download.
Und die Taktfrequenz kann auch nicht gedrosselt werden. 100% CPU-Last für Dune2 ist imho etwas viel, aber wenn der Code ohne Emu läuft werden die Devs sicher auch daran schrauben.
Auf jeden Fall haben die auch schon ca 50 Bugs und Unschönheiten gefixt.

Hmm ... das wäre ja so etwas wie erwähntes "C--". C-Code mit eingestreutem Assembler oder sehr kleinen Schritten.

Wow. Ich dachte, dass es wenigstens um das erste Dune-Spiel ginge. Aber das zweite? Wo doch danach unzählige Spiele erschienen, die in jeder Hinsicht besser waren? Nicht, dass Dune II schlecht gewesen wäre, aber in Sachen Komfort kann es meiner Meinung nach mit keinem anderen Spiel mithalten - jeder Nachfolger hat das Konzept genommen und deutlich erweitert. Ich habe kaum vier Missionen des Spieles geschafft, bevor mich das viele Geklicke, das nötig war, wahnsinnig gemacht hat.

Deswegen spielt man das ja auch mit Tastatur + Maus. Aber ich gebe dir recht, Dune2 möchte ich im Original auch nicht mehr spielen. Und Dune2000 sieht zu sehr nach Command&Conquer* aus. Dune 1 hingegen verbreitet immer noch eine großartige Athmosphäre, was zum einen an den wunderschönen Grafiken liegt (diese Farbverläufe beim Sonnenauf- und Untergang!) und zum anderen an der Musik von Stephane Picq.

No more Pong for you.

Dann halt Plasma Pong.

*Zum Thema "Command&Conquer" noch ein Schwank aus den 90ern. Eines Tages meinte ein Mitschüler zu mir, er hätte im Jugendtreff auf einem Rechner ein neues Spiel gefunden, MadTV war es glaub ich. Er hatte im Stammverzeichnis eine Datei namens "mega.exe" gefunden und die gestartet. Danach lag er mir in den Ohren, ich solle doch auf meinem Rechner auch mal danach suchen.
Ich: "Nein, Junge, den Rechner habe ich selber aufgesetzt, wie soll da so'n Spiel draufkommen?"
Er: "Probiers doch einfach mal! Mega.exe!"
Ich: "Nein, wozu denn, ich weiß doch, das da nicht ..."
Er: "Mega Punkt EXE. Einfach unter C:!"
Ich: "Na gut. 'dir c:'. Siehste, keine Mega.exe."
Er: "Eh, was ist das denn? command.com? Das ist bestimmt Command and Comquer!"

[Sannah]

Was genau machst Du denn beim modden? Gibt es da eine Community oder machst Du das "nur" für dich?

Och im Prinzip alles gemischt, UFO:AS mach ich für mich aktuell und ggf. iwann wenn ichs veröffentliche nen bissi für Community (vor allem die fehlerhafte deutsche Übersetzung, die ich aber noch net vollständig durch habe), größtenteils scripten und halt die Files über 10 Instanzen entpacken, damit man sie auch verarbeiten kann. Hab vor auch mal ein paar Polymodelle auszutauschen, brauche aber dazu erstmal nen gescheites Proggy um mir ein paar gescheite Modelle bauen zu können und mitunter halt auch die Kompatiblität beim Exportieren gewahrt zu haben. Sollte ich letzteres in Sachen Poly was weiter bringen werde ich mir denke ich auch mal DukeNukem 3D vornehmen, dazu gibts nen netten Polygon Mod, leider ist er mir noch zu unausführlich und hässlich, da könnte man noch ne Menge dran feilen mit ein paar gescheiten Highpoly-Modellen.

Für Wizardry7 hab ich ne Menge früher mit Madgod zusammengearbeitet, der hat da nen nettes Proggy zur Contentveränderung für 3 Teile von Wizardry gebastelt, netter Kerl, hab ihn auch mal gefragt ob er interesse am "Dark Eye" hätte, hats aber verneint, schade eigentlich, weil echt nen fähiger Kerl... leider ist in W7 ne Menge hardcode dabei, was die Datenbanken verdammt einschränkt. Größtenteils hab ich hier neue Grafiken und Portraits gebaut... aber man könnte im Falle von Wizardry8 noch ne Menge mit Polys machen. Weil die Polymodelle dort echt zum fürchten sind.

Für Biing! arbeite ich mit einem gewissen Dragonling zusammen und mache größtenteils neue Grafiken, wenn ich mal mehr Zeit habe vlt auch mal für Biing2 nen komplettes Makeover, weil der Grafikstil gegenüber dem ersten Teil schon enorme Abstriche hat. Mit Olaf Patzenhauer der das damals mitprogrammeirt habe stehe ich auch noch im Kontakt, nur leider hat er genug eigene Probleme als sich um sowas zu kümmern.

€dit: Mir ist da noch Descent3 eingefallen, nur leider gibts da aktuell keine Intentionen mehr Seitens der Community um das Spiel mal ordentlich und kollektiv zu modden. Wäre dort dann beim Levelbau und Polymodelle für Raumgleiter eingestiegen, ist aber ne ziemlich zerstrittene Chauvinisten-Community. xD Was hier die NLT betrifft würde ich gerne auch mitwirken, hab aber nicht sonderlich viel Erfahrung mit dem Disassembling von DOS, wenn ihr da irgendwann durchgestiegen seid und mir das ganze vlt kurz erklärt bin ich jederzeit für Contenterweiterungen und Veränderungen zu haben... so es die Zeit halt erlaubt.

[Rabenaas]

Kann man dieses Paper irgendwo lesen, oder ist das noch nicht veröffentlicht?

Da wo auch das Video liegt.

Werde ich das? Ich weiß ehrlich gesagt noch gar nicht, wie man am Assemblercode C und C++ auseinanderhalten kann

Naja, virtuelle Funktionen müssen dynamisch gelinkt sein, also wird die Adresse für den Call aus einem Array im Speicher geholt, anstatt eine feste Adresse anzuspringen. Throw/catch müssten auch ziemlich charakteristische Codeabschnitte hinterlassen.

[Hendrik]

Kann man dieses Paper irgendwo lesen, oder ist das noch nicht veröffentlicht?

Da wo auch das Video liegt.

Ah, danke. Das war mir wohl zu einfach, beim Video zu gucken

Werde ich das? Ich weiß ehrlich gesagt noch gar nicht, wie man am Assemblercode C und C++ auseinanderhalten kann

Naja, virtuelle Funktionen müssen dynamisch gelinkt sein, also wird die Adresse für den Call aus einem Array im Speicher geholt, anstatt eine feste Adresse anzuspringen. Throw/catch müssten auch ziemlich charakteristische Codeabschnitte hinterlassen.

Ja, so könnte man das machen. Das Disassemblieren wird dadurch natürlich nicht einfacher. Ich bin jedenfalls schon gespannt, ob ich das direkt in Klassen umsetzen kann oder doch erst mal ohne OOP übersetze.

[Obi-Wahn]

Gibts hier eigentlich was Neues? Im Git-Repo seh ich regelmäßig Änderungen.

[HenneNWH]

Es gibt (für mich) etwas bahnbrechendes: Ich habe herausgefunden wie man den Emulator aus rekonstruiertem Code wieder aufruft.
Das bedeutet, dass ich weniger nachprogrammieren muss und die Entwicklung schneller vor sich geht.

Mittlerweile ist fast der ganze Code von Gen V1.05de rekonstruiert. Sogar die MIDI Musik läuft.
Die Hauptfunktionfunktion main() ist auch schon ersetzt.
Außerdem habe ich schon angefangen ein paar hartcodierte Daten aus dem Datensegment der GEN.EXE
in den neuen Quellcode zu übertragen. Dabei handelt es sich um die DSA3 Tabellen, Farbtabellen und alle möglichen globalen Variablen.
Danach müssen Ein-/Ausgabe, Grafik und Sound aus der DOSBox entfernt werden und fertig ist das eigenständige Programm.

Bevor ich das Programm von der DOSBox trenne, möchte ich es noch in die Lage versetzten mit anderen Versionen der DSAGEN.DAT
umgehen zu können. Damit meine ich die deutsche Diskettenversion und die englische Variante.

Ansonsten komme ich peux-í -peux dem Ziel nahe.

Außerdem habe ich fast den Statusbildschirm fertig, damit der permanente LE-Schaden (Stichwort: "LE 1/1") rot eingefärbt werden kann.

Dank der Nachfrage.

[Hendrik]

Hallo HenneNWH,

da ich ja angefangen habe, Sternenschweif mit deiner Methode ebenfalls Stück für Stück nachzubauen, würde ich gerne mit dir das weitere Vorgehen besprechen.

Wollen wir den Code im gleichen Git-Repository weiterentwickeln (Bright-Eyes), oder hälst du es für sinnvoll, wenn ich dafür ein eigenes Repo aufmache?
Wenn wir im gleichen Repo bleiben (was ich befürworten würde, da man einiges an Verwaltungscode beibehalten könnte, müssen wir den Code so schreiben, dass - je nach laufender .exe - die richtigen Handler aufgerufen werden. Du hattest in der custom.h bereits eine Klasse custom_prog dafür vorgesehen, die aber, soweit ich sehe, nicht benutzt wird. Wenn du nichts dagegen hast, würde ich die custom.h/custom.cpp so umschreiben, dass man mehrere Programme (also Instanzen von custom_prog) überwachen kann. Es würde dann die erste (letzte?) Instanz zum aktuellen Programm gewählt, für die die probe()-Funktion true zurückliefert.
Wie stehst du zu diesem Plan? Ich würde dann, von solchen Änderungen im allgemeinen Code abgesehen, mit Sternenschweif weitermachen, während du dich weiter der Schicksalsklinge widmen könntest.

[Obi-Wahn]

Das hört sich ja beides richtig gut an! Wnn ihr einen Dummen fürs Testen braucht, steh ich bereit.

[HenneNWH]

Wollen wir den Code im gleichen Git-Repository weiterentwickeln (Bright-Eyes), oder hälst du es für sinnvoll, wenn ich dafür ein eigenes Repo aufmache?
Wenn wir im gleichen Repo bleiben (was ich befürworten würde, da man einiges an Verwaltungscode beibehalten könnte, müssen wir den Code so schreiben, dass - je nach laufender .exe - die richtigen Handler aufgerufen werden. Du hattest in der custom.h bereits eine Klasse custom_prog dafür vorgesehen, die aber, soweit ich sehe, nicht benutzt wird. Wenn du nichts dagegen hast, würde ich die custom.h/custom.cpp so umschreiben, dass man mehrere Programme (also Instanzen von custom_prog) überwachen kann. Es würde dann die erste (letzte?) Instanz zum aktuellen Programm gewählt, für die die probe()-Funktion true zurückliefert.
Wie stehst du zu diesem Plan? Ich würde dann, von solchen Änderungen im allgemeinen Code abgesehen, mit Sternenschweif weitermachen, während du dich weiter der Schicksalsklinge widmen könntest.

Es wäre mir eine Freude, wenn du das machen würdest.
Die "DesignIdee" hatte ich mir von den Linux-Kerneltreibern abgeschaut,
aber in C++ mit Objekten funzt das doch etwas anders.

Das selbe Repo zu benutzen ist eine sehr gute Idee,
damit "DOSBox custom" sinnvoll genutzt und weiterentwickelt werden kann.

Es gibt noch ein paar Kleinigkeiten, welche ich dir nicht vorenthalten möchte:

• Verzeichnislayout
  Pro Spiel sollte ein Verzeichnis in src/custom erstellt werden, in deinem Fall "schweif".
  In diesem sollten alle Dateien liegen, die nur in Verbindung mit DOSBox sinnvoll sind und
  nach erfolgter Migration weggeworfen werden. In diesem Verzeichnis solltest Du dann ein
  Verzeichnis mit dem Namen "rewrite_c100de" anlegen, in welches dann der Spielecode deiner
  Version kommen sollte.
  Das ist kein Muss, aber meiner Meinung nach die sinnvollste und ordentlichste Variante.
  
• Dateinamen
  Mit "MS VisualC++ 2008" bin ich auf ein Problem gestoßen.
  Dieser Compiler legt alle Objektdateien in ein Verzeichnis.
  Existiert mehrmals der gleiche Dateiname in verschiedenen Verzeichnissen,
  so werden beim kompilieren nur die Objektdateien immer überschrieben und es gibt einen Linker-Fehler.
  Desswegen sollten die Dateinamen mit einem eindeutigen Prefix versehen werden.
  In dem Fall schlage ich vor: z.B "c100de_seg001.cpp" für den Code für seg001
  
• Namespaces
  Um bei soviel ähnlichem Code nicht in Schwierigkeiten zu kommen ist es sinnvoll soviel es geht in
  Namespaces zu packen, damit wir keine Namenskonflikte bekommen.
  

Ansonsten: Happy H*cking!
Ich bin schon mordsmäßig gespannt.

Das hört sich ja beides richtig gut an! Wnn ihr einen Dummen fürs Testen braucht, steh ich bereit.

Du kannst dir gern jederzeit den Code aus dem Repo kompilieren. So hast du die besten Chancen
etwas fehlerhaftes zu finden. Prinzipiell sollte es immer funktionieren.

Achja, den passenden Thread finde ich jetzt gerade nicht, aber Schweif kann beim Import von Schick abstürzen.
Der Grund ist, dass der Gegenstandszähler der Helden einen falschen Wert hat.
Das wird in "BrightEyes" mittlerweile mit entsprechender Meldung korrigiert.