Wie kriegst du das Zeug eigentlich reverse engineered HiPhish? Einfach nur durch ausprobieren? :-?
Meine Güte, nein, das wäre Wahnsinn. Der Quellcode für Wolfenstein 3D wurde noch in den 90ern von Id offengelegt und ist heutzutage auf GitHub zu finden, ebenso wie der Quellcode für Doom, Quake und viele andere id Spiele:
https://github.com/id-Software/wolf3d
Die PCs damals waren nicht wirklich für Spiele gedacht (das trifft nur auf IBM PCs und Klone zu, nicht auf andere Heimcomputer) und John Carmack und John Romero mussten wirklich alle möglichen Tricks anwenden um das Spiel flüssig zum Laufen zu bringen. Das Ergebnis ist dass der Code voller Implementations-abhängiger Teile ist und manches wurde sogar in Assembly geschrieben. Assembly ist quasi das Gleiche wie Maschinencode, bloß mit kurzen Schlüsselwörtern anstelle von Einsen und Nullen.
Eine bessere Alternative ist der Chocolate Wolfenstein 3D Port, wo alle nicht-portablem Teile durch portable Teile ersetzt wurden, aber ansonten ist es das gleiche Spiel:
https://github.com/fabiensanglard/Chocolate-Wolfenstein-3D/
Und zuletzt schummle ich ein wenig und suche mir auch Wissen aus dem internet zusammen. Es gibt nicht viel, aber diese beiden links waren recht hilfreich:
http://www.shikadi.net/moddingwiki/Wolfenstein_3-D
http://devinsmith.net/backups/bruce/wolf3d.html
Ich muss mir trotzdem die Hände dreckig machen und selbst nachforschen, aber es hilft wenn ich jemanden habe der mich zumindest in die richtige Richtung schickt.
Ich beherrsche C, also kann ich mich durch den Quellcode lesen und dadurch herausfinden wie das Spiel die nackten Bytes aus den Dateien verarbeitet. Levels zum Beispiel sind mit zwei verschiedenen Algorithmen komprimiert, aber das weiß ich anfangs nicht. Ich muss die Funktion finden die dafür zuständig ist ein Level zu laden und sie dann zurückverfolgen bis dort wo die erste Datei von der Festplatte geladen wird. Dann folge ich der Funktion und schaue was sie mit der Datei macht, welche Funktionen sie aufruft und was dann weiter mit den Daten passiert bis das fertige level im Speicher ist.
Ich dokumentiere dann diesen Vorgang, ich beschreibe also in Worten was getan werden muss. Die Dokumentation ist unabhängig von der Sprache, es geht nur um das
was, nicht das
wie. Anhand dieser Dokumentation bilde ich dann den Prozess in meinem Programm nach, auf meine Weise. Das ist wichtig, denn das Ziel meiner Dokumentation ist dass man das original Verhalten nachbilden kann, ohne den ursprünglichen Code kennen zu müssen. Das Problem mit vielen Ports ist dass sie einfach Teile aus dem originalen Code mit minimalen Änderungen übernehmen, was in einem Frankenstein Monster Programm endet.
Dann ist es Zeit mein Programm zu testen, das Programm ist so simpel wie möglich geschrieben. Es kan nichteinmal von alleine in einer Datei speichern, man muss die Ausgabe selbst umleiten:
Code:
wolf3dextract -lm 1 1 0 >level_map
Das Programm druckt des Ergebnis in den Standard Output, der normalerweise der Bildschirm ist, und mit dem "Trichter" da oben kann ich statt dessen den Output in eine Datei umleiten. Die Datei kann ich denn zum Beispiel in einem Hex Editor öffnen und dann einen Screenshot davon machen und auf CW posten:
Das ist das tolle an Befehlszeilenprogrammen, man kann nach Belieben umleiten oder sie sogar aneinander ketten. Für Die Bilder benötige ich eine Möglichkeit aus den rohen Bytes ein Bild zu machen das man auch betrachten kann. Ich habe ein kleines (23 Zeilen inkl. Kommentare und Leerzeilen) Program geschrieben das ein
PPM Bild erzeugt (PPM ist das einfachste standardisierte Format das ich gefunden habe). Ich würde dann so etwas in mein Terminal schreiben:
Code:
wolf3dextract -pic 15 | rgb2ppm >pic_15.ppm
Der senkrechte Strich leitet den Standard Output des Extractors in den Standard Input des Konverters und der leitet seinen Standard Output ich eine Datei. Ich hätte auch statt dessen das Ergebnis an einen anderen Konverter (etwa
ImageMagick) schicken können, der dann daraus ein PNG oder was auch immer erzeugt.
Das ist ein typisches Beispiel für die Unix Philosophie: viele kleine Programme erledigen sehr spezifische Aufgaben, und diese Programme kann man dann zu größeren Einheiten kombinieren. Ich hätte etwa ein
Shell Skript schreiben können oder eine GUI Applikation die das genzen dann benutzerfreundlich verpackt. Ich benutze zum Beispiel ein Shell Skript wenn ich mein Paket in Unity an den Asset Store schicken will: über das
Befehlszeileninterface kann ich die Dokumentation generieren, Projekte erstellen und Pakete importieren und Dateien löschen, also packe ich alle diese Befehle zusammen und ein einziger Aufruf erledigt für mich etwas das ich sonst mühselig über unzählige Klicks per Hand machen müsste.
Sobald ich dann mit den Assets fertig bin kann ich die Spielmechaniken dokumentieren. Dafür werde ich dann wohl den iOS Port verwenden, der ist übersichtlicher geschrieben:
https://github.com/id-Software/Wolf3D-iOS
Und dann wenn das alles fertig ist kann ich anfangen darüber nachzudenken wie ich das in der Doomsday Engine umsetzen will. Die Doomsday Engine ist unabhängig von den eigentlichen Spielen, also muss ich bloß die "Kabel" richtig verlegen und dann sollte es fertig sein.
Funktioniert hier auf OS X mit Safari, wobei Safari zunächst das Plugin blockt, ich muss erst darauf klicken, dann lädt der Player. Das ist aber normal so bei Plugins mit Safari, passiert auch zum Beispiel bei Flash wenn man keinen Flash Blocker installiert hat.
