Reverse Engineering der NLT - Druckversion +- Crystals-DSA-Foren (https://www.crystals-dsa-foren.de) +-- Forum: Allgemeines zur Nordlandtrilogie DOS (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=20) +--- Forum: Technische Werkstatt (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=34) +--- Thema: Reverse Engineering der NLT (/showthread.php?tid=700) |
RE: Reverse Engineering der NLT - HenneNWH - 17.10.2014 Hier noch ein paar Patches: Behobene Fehler (Bright-Eyes)
Sonstiges
Der behobene Fehler war übrigens der besagte Fehler, welcher mir auf ARM aufgefallen ist. Auf allen anderen Prozessoren (x86, x86_64, PPC) ist dieser Fehler auch aufgetreten. Viel Vergnügen! (10.10.2014, 16:25)Obi-Wahn schrieb: Auf die ARM-Version bin ich gespannt! Dann muss ich doch mal glatt den Raspberry Pi meines Vaters klauen! Wie weit wäre der Schritt dann noch zu einer Android-Version? Gute Frage! Gibt es denn hier im Forum potentielle NLT-Androidnutzer? Eine Androidversion könnte man vermutlich relativ einfach bauen, indem man den DOSBox-Quellcode in einem funktionierenden und quelloffenen DOSBox-Port (z.B. aDOSBox) durch den Bright-Eyes Quellcode ersetzt und das ganze dann baut. Ich habe gerade versucht aDOSBox mit dem aktuellen Andriod NDK zu bauen, aber das Bauen bricht leider ab. Mir fehlt dafür allerdings die Zeit um eine Androidversion zu pflegen. Interessenten bitte vortreten. (10.10.2014, 16:25)Obi-Wahn schrieb: Was meinst du mit einem "eigenen" Compiler? Aus Lizenzgründen darf ich doch keine Kopien verteilen. Desshalb muss jeder Entwickler seine eigene Version vom "Borland C++ 3.1" Compiler besitzen, wenn er diese Vergleichstests durchführen möchte. RE: Reverse Engineering der NLT - Obi-Wahn - 17.10.2014 Neue Version vom 17.10.2014! Ich hätte da diverse Android-Geräte mit denen ich das ausprobieren könnte. Es wäre allerdings eher ne Spielerei als eine echte Anwendung. RE: Reverse Engineering der NLT - NewProggie - 18.10.2014 Guten Abend, ihr meint nicht zufällig sowas wie das hier, oder? http://www.crystals-dsa-foren.de/showthread.php?tid=3079 RE: Reverse Engineering der NLT - Obi-Wahn - 18.10.2014 Nein, nicht ganz. Es soll ähnlich laufen wie auf dem PC. Die aDosBox soll nur noch die Teile von Schick übernehmen, die von BrightEyes noch nicht ersetzt worden sind. Gerade auf den Android-Geräten, die noch nicht so viel Rechenleistung "über" haben, sollte sich da eine Geschwindigkeits- oder besser "Geschmeidigkeits-"Verbesserung zeigen. (17.10.2014, 16:54)HenneNWH schrieb: Ich habe gerade versucht aDOSBox mit dem aktuellen Andriod NDK zu bauen, aber das Bauen bricht leider ab. Vermutlich braucht man da noch die Android/ARM-Variante von SDL, oder? (Vielleicht das hier?) RE: Reverse Engineering der NLT - HenneNWH - 18.10.2014 (18.10.2014, 11:53)Obi-Wahn schrieb: Nein, nicht ganz. Es soll ähnlich laufen wie auf dem PC. Die aDosBox soll nur noch die Teile von Schick übernehmen, die von BrightEyes noch nicht ersetzt worden sind. Gerade auf den Android-Geräten, die noch nicht so viel Rechenleistung "über" haben, sollte sich da eine Geschwindigkeits- oder besser "Geschmeidigkeits-"Verbesserung zeigen. Genau so ist es. (18.10.2014, 11:53)Obi-Wahn schrieb: Vermutlich braucht man da noch die Android/ARM-Variante von SDL, oder? (Vielleicht das hier?) Das ist nicht nötig. Bei aDOSBox sind alle benötigten Bibliotheken im Quellcode dabei, also auch SDL. Das Android NDK baut den ganzen C++ Code in eine neue Bibliothek. (Habe jetzt Version 5b probiert, damit ging es.) Diese Bibliothek wird dann von der JAVA-App, welche mit dem SDK gebaut wird aufgerufen. An dieser Stelle hänge ich gerade fest. RE: Reverse Engineering der NLT - Obi-Wahn - 18.10.2014 Viel Erfolg! RE: Reverse Engineering der NLT - Wetzer - 17.11.2014 Hi NLT-Freunde, was machen denn die verschiedenen SW-Projekte? Sommer ist vorbei und Wetter wird ideal zum programmieren. RE: Reverse Engineering der NLT - HenneNWH - 17.11.2014 Bright-Eyes macht große Fortschritte: Der Kampfmodus ist jetzt vollständig nachgebaut. Gerade bastle ich an ein paar Gebäuden von Phexcaer. Ich teste Morgen meine Version nochmal und werde morgen wieder mal releasen. Dann mit genaueren Infos. RE: Reverse Engineering der NLT - HenneNWH - 18.11.2014 Einige Neuigkeiten: Wie schon im letzten Beitrag erwähnt: das Kampfsystem läuft jetzt komplett auf dem Hostrechner. Ersetzte Funktionen (Segmente sind komplett identisch)
Ersetzte Funktionen
Behobene Fehler (Bright-Eyes)
Fehler aus dem Original
Dokumentation:
Was kommt als Nächstes?
Statistik:
Die Fortschrittsmessung anhand der Anzahl der Funktionen ist manchmal ein wenig irreführend. Es gibt Funktionen, die in der SCHICKM.EXE sehr viel Platz wegnehmen. Der Maschinencode für das Menu im Kampfsystem ist z.B. über 6KB groß (mehr als 1% der SCHICKM.EXE). Andere Funktionen sind dagegen winzig. Das macht sich auch in der Bearbeitungszeit bemerkbar. Desshalb habe ich noch eine alternative Metrik zu Messen des Bright-Eyes Fortschritts, welche die Größe des fertigen Maschienencodes ins Verhältnis zum Maschinencode in der SCHICKM.EXE setzt. Der folgende Wert ist noch etwas kleiner als der Tatsächliche, da ich im Moment nur komplett fertige Segmente zähle: Nach der Byte-Metrik ist der Code von SCHICK schon zu 71,91% fertig. Das klingt doch schon viel besser. Viel Spaß! RE: Reverse Engineering der NLT - Shihan - 20.11.2014 Henne, großartig! Wieviel Cycles brauchst Du mittlerweile? Oder anders: Wie wenige sind es noch? @Wetzer: 3DM schläft z.Z. Habe zwar einen kleinen OpenGL-Viewer geschrieben. Dabei sind mir aber noch ein paar Unstimmigkeiten aufgefallen. Die Face-Zuordnung stimmt nicht ganz. Was falsch ist, weiß ich aber noch nicht. Habe gerade auch -- trotz Winter -- wenig Zeit dafür. Schaue aber immer mal wieder rein. Hoffentlich kommt da bald der Heureka-Moment. RE: Reverse Engineering der NLT - Wetzer - 20.11.2014 (20.11.2014, 11:27)Shihan schrieb: @Wetzer: Sehr Schade. Wäre es möglich, dass du deine bisherigen Arbeiten veröffentlichst, damit man darauf aufbauen kann? RE: Reverse Engineering der NLT - Obi-Wahn - 20.11.2014 Neue Version vom 20.11.2014! Der Kampf funktioniert grundlegend. Angreifen, Magie usw... Mehr habe ich noch nicht getestet. RE: Reverse Engineering der NLT - Rabenaas - 20.11.2014 Das lesbar machen ist ja eigentlich klassisches Refactoring. Hat sich schon mal jemand Gedanken darum gemacht, mit welchen Tools sich das unterstützen ließe? (z.B. Eclipse) Damit könnte man ja eigentlich jetzt schon anfangen, oder? (20.11.2014, 18:39)Obi-Wahn schrieb: Der Kampf funktioniert grundlegend. Angreifen, Magie usw... Mehr habe ich noch nicht getestet.War never changes ... :d RE: Reverse Engineering der NLT - Shihan - 24.11.2014 (20.11.2014, 18:22)Wetzer schrieb: Sehr Schade.Naja, außer dem Text in der Wiki und dem Viewer gibt es nichts, was ich da veröffentlichen könnte. Und der Viewer ist bisher so geschrieben, dass ich den nicht veröffentlichen möchte. Zu dreckig, um es mal anders zu sagen Aber wie gesagt, ich denke, die Zeit kommt wieder. RE: Reverse Engineering der NLT - HenneNWH - 25.11.2014 (20.11.2014, 11:27)Shihan schrieb: Henne, großartig! Wieviel Cycles brauchst Du mittlerweile? Oder anders: Wie wenige sind es noch? Also wenn man eine leicht verzögerte Startphase in Kauf nimmt, in der DOSBox das CD-Image mountet und die SCHICKM.EXE startet, kann man Schick mit 100 Cycles flüssig spielen. (20.11.2014, 20:20)Rabenaas schrieb: Das lesbar machen ist ja eigentlich klassisches Refactoring. Hat sich schon mal jemand Gedanken darum gemacht, mit welchen Tools sich das unterstützen ließe? (z.B. Eclipse) Ich lese parallel die Wikipedia Seite zu Refactoring. Einige Änderungen können gemacht werden, andere noch nicht. Was ist im Moment möglich:
Die Borland-C-Version des Quelltextes darf nicht in ihrer Funktionalität geändert werden, da ich bei jedem Commit automatisch den Quellcode mit dem BCC kompiliere und prüfe ob dergleiche Binärcode rauskommt. Ist das nicht der Fall wird der Commit nicht zugelassen. Unit-Tests wären schön, aber ich hab noch keine Idee wie und womit diese umgesetzt werden können. RE: Reverse Engineering der NLT - HenneNWH - 06.12.2014 Einige Neuigkeiten zun Nikolaus : Der Code von der Spezialgebäude von Phexcaer ist komplett nachgebaut. Ersetzte Funktionen (Segmente sind komplett identisch)
Ersetzte Funktionen
Behobene Fehler (Bright-Eyes)
Dokumentation:
Was kommt als Nächstes?
Statistik:
Anmerkungen zu Phexcaer: Die vollständige Umsetzung dieser Stadt scheint dem frühen Releaseterm in zum Opfer gefallen zu sein. Fragt man im Fuhrhaus oder im Spielhaus nach Alrik Derondan, so trifft man ihn in der nächsten Taverne in Phexcaer. Im Gespräch mit Ihm führen die Antwortfolgen 1->3->1 oder 3->1 dazu, dass eine Variable im Spielstand gesetzt wird, welche allerdings nirgendwoanders abgefragt wird. Hier tritt somit das gleiche Problem auf, wie bei der Verabredung mit der Prostituierten. Viel Spaß! RE: Reverse Engineering der NLT - Obi-Wahn - 07.12.2014 Neue Version vom 07.12.2014! RE: Reverse Engineering der NLT - Rabenaas - 18.12.2014 Bin gerade über eine interessante Bibliothek gestolpert. Was haltet ihr von der Idee, ein Backend für die DATs in physicsfs zu schreiben? RE: Reverse Engineering der NLT - Hendrik - 18.12.2014 Ja, Physicsfs... Wenn ich dich recht verstehe, möchtest du (langfristig) die Lade-Routinen der 3 NLT-Teile durch Aufrufe von PhysicsFS ersetzen, so dass ich die Archivdateien auch ungepackt verwenden könnte? Geht durchaus, aber das ist eher etwas für den "dritten Schritt", nachdem die Spiele vollständig rückübersetzt und lesbar gemacht worden sind. Was mich beim Schreiben von nltpack an den NLT-Archiven am meisten gestört hat ist, dass es durchgehend keine "echten" Archivformate sind - man kann jeweils nur bestimmte Dateien speichern. Für die SCHICK.DAT sind das genau die Dateien, die in der SCHICK.EXE am Ende stehen, für Schweif die Dateien aus der jeweiligen .FN, und Riva hat zwar theoretisch sogar Unterverzeichnisse, praktisch hingegen sind die Archive (bzw. der Code in der RIVA.EXE) recht empfindlich gegen eine solche "universelle" Nutzung. Daher hatte ich mich auch für das - zugegeben nicht besonders nutzerfreundliche - Bedienkonzept mit den .FN-Dateien entschieden. EDIT: Ein PhysicsFS-Backend hätte, als Bibliothek verstanden, natürlich auch andere Einsatzmöglichkeiten: nutzerfreundliche Reimplementationen von nltpack, Nutzung in Editoren, Nachbau der NLT (statt RevEng), ... RE: Reverse Engineering der NLT - Rabenaas - 18.12.2014 (18.12.2014, 13:50)Hendrik schrieb: Wenn ich dich recht verstehe, möchtest du (langfristig) die Lade-Routinen der 3 NLT-Teile durch Aufrufe von PhysicsFS ersetzen,Ja (18.12.2014, 13:50)Hendrik schrieb: so dass ich die Archivdateien auch ungepackt verwenden könnte?Jein, über PhysicsFS kann man ja (soweit ich das verstehe) z.B. auch auf Zips zugreifen. Insofern würde die Bibliothek u.a. den Zugriff auf die Ressourcen als Middleware vereinheitlichen und transparent machen. (Ent-)Packer, Editoren und Spiele könnten über den selben Code auf die Archive wie auf normale Verzeichnisse (und umgekehrt) zugreifen und bräuchten sich nicht mehr mit den Details auseinandersetzen. (18.12.2014, 13:50)Hendrik schrieb: Geht durchaus, aber das ist eher etwas für den "dritten Schritt", nachdem die Spiele vollständig rückübersetzt und lesbar gemacht worden sind.Stimmt. |