Reverse Engineering der NLT II - 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 II (/showthread.php?tid=5383) |
Reverse Engineering der NLT II - Crystal - 28.06.2017 Fortführung des bestehenden Threads Reverse Engineering der NLT. Aus technischen Gründen geschlossen. Shihan schloss mit dem Beitrag: (20.06.2017, 11:25)Shihan schrieb: Habe mal ein paar Infos zu den Zwischensequenzen von Riva ins Wiki eingetragen. Das Format ist recht einfach gehalten und baut die Sequenz aus einer Reihe von Smacker-Videos zusammen, während RAW-PCM-Audiostreams zu vorgegebenen Zeitpunkten gespielt werden. Und hier der Link dazu -> http://bright-eyes.obiwahn.de/index.php?title=AAF RE: Reverse Engineering der NLT II - Shihan - 28.06.2017 In der technischen Werkstatt werden aus technischen Gründen Themen getrennt? Zu groß geworden? RE: Reverse Engineering der NLT II - Crystal - 28.06.2017 Ja, das Phänomen der Größe hatte ich vor Jahren auch in anderen Foren negativ beobachten können. In meinem eigenen möchte ich es nicht unbedingt darauf ankommen lassen. RE: Reverse Engineering der NLT II - Lippens die Ente - 28.06.2017 Die Rateecke ist wesentlich jünger und hat schon mehr als doppelt so viele Beiträge. RE: Reverse Engineering der NLT II - aeyol - 29.06.2017 Was war denn das Problem bei zu großen Threads, also was kann da schlimmstenfalls passieren? Ich seh das in anderen Foren auch, dass Themen entsprechend geteilt/neu gestartet werden und habe kein Problem damit, bin nur neugierig. @Lippens Na wenn die Rateecke mal irgendwie kaputtgehen würde (? Problem in der DB?), wäre das zumindest nicht so schlimm wie bei diesem Technik-Thread. Da ginge mehr verloren. RE: Reverse Engineering der NLT II - Crystal - 29.06.2017 (28.06.2017, 22:57)Lippens die Ente schrieb: Die Rateecke ist wesentlich jünger und hat schon mehr als doppelt so viele Beiträge. Die Threads in den Fachbereichen genießen nicht nur bei mir einen höheren Stellenwert, glaube ich. Was nicht heißt, dass der OT-Bereich unwichtig ist, aber im Fall der Fälle leichter verschmerzbar. Natürlich habe ich Backups, aber unnötige Arbeitsgänge wegen Zurückspielen kann man auch vermeiden. Mal sehen, was sich im OT noch optimieren lässt. Doch lasst uns hier wieder zum eigentlichen Thema zurückfinden. (29.06.2017, 10:01)aeyol schrieb: Was war denn das Problem bei zu großen Threads, also was kann da schlimmstenfalls passieren? Threads können Probleme beim Teilen/Zusammenfügen verursachen und die Defragmentierung im Hintergrund kann ins Stocken geraten oder durch Timeouts abgebrochen werden, sodass die DB mit der Zeit immer langsamer wird. Und dass ich nicht den schnellsten Server habe, dürfte allgemein schon aufgefallen sein. Mir geht es nur darum, das Forum auf einem hohen Geschwindigkeits-Level zu halten, so gut und so günstig es eben geht. RE: Reverse Engineering der NLT II - Shihan - 19.07.2017 So, mal wieder zum Thema. Habe mich mal ein bisschen mit den BOB-Dateien von Riva auseinandergesetzt. Im Wiki schrieb jemand, dass die Palette, die hinten dran hängt, zwar in die richtige Richtung ginge, aber viel zu kontrastreich sei. Das stimmt nur zum Teil. Es gibt ein paar Bilder, bei denen das so ist. So z.B. die gute Lea (ELEANA.BOB). Vielleicht ist die Palette noch gepackt? Ich werde das mal untersuchen. Andere Bilder (z.B. ein Lagerbild CAMP01.BOB) sind grundsätzlich richtig, nur in 6-Bit kodiert. Jedes Byte mit 4 zu multiplizieren hilft aber und bringt eine fast richtige Ansicht (im Original scheinen die Farben noch um je 1 stärker zu sein). Nachtrag um 15:15: Die Palette ist wirklich etwas konfus. Es handelt sich hierbei wirklich in jedem Bild um eine 6-Bit-Palette. Das Problem ist, dass bei einigen Bildern die Palette keine "sauberen" 6-Bit hat, sondern die obersten Bits auch noch auf 1 gesetzt sind. In jedem Fall bekommt man mit Code: (c & 0x3f) * 4 Das Problem der Animationen bleibt bestehen... /Nachtrag Auch die Animationen sind noch nicht ganz sicher. any2any kann z.B. bei o.g. Bilder nicht richtig extrahieren, hier sind die Animationen immer gleich (wenn sich ein Mund bewegen sollte, gibt es eine Reihe Bilder, bei denen der Mund geschlossen bleibt; die Camping-Szene hat eine Fakel, die sich nicht verändert, etc...). Hatte sich nochmal jemand damit beschäftigt? RE: Reverse Engineering der NLT II - HenneNWH - 19.07.2017 Hallo, ich wollte nur mal ein kleines Lebenszeichen von mir geben. Im Moment hab ich mit dem Studium und dem RL sehr viel zu tun, denke aber, dass ich ab September wieder etwas Zeit für Bright-Eyes abknapsen kann. Bis denne, Henne RE: Reverse Engineering der NLT II - Obi-Wahn - 19.07.2017 Schön, dass du dich meldest! Alles Gute und bis zum September! 😀 RE: Reverse Engineering der NLT II - Tiefhusen - 20.07.2017 Super!!! Dann erstmal weiterhin viel Erfolg im Studium und bis September! RE: Reverse Engineering der NLT II - Shihan - 20.07.2017 Schön zu hören! Viel Erfolg bei Deinen Plänen! Habe Dir übrigens einen Pull-Request per Github geschickt RE: Reverse Engineering der NLT II - Rabenaas - 20.07.2017 Good news. RE: Reverse Engineering der NLT II - Wetzer - 02.08.2017 Auch von mir alles Gute und Erfolg! RE: Reverse Engineering der NLT II - Mirko - 02.10.2017 Hallo, ich habe vor kurzem diesen Thread (bzw. Teil 1 davon) gefunden und mit wachsender Begeisterung gelesen. Es war schön zu sehen, wie es mit Bright Eyes immer weiter ging. Vielen Dank, dass ihr Euch die ganze Arbeit macht, um dieses schöne Spiel am Leben zu erhalten. Und ich bin sehr gespannt, wie sich das ganze weiter entwickeln wird. Ich habe mir gestern mal den Quellcode heruntergeladen und konnte ihn sogar in der Visual Studio 2017 Community Edition erstellen (ausgehend vom 2008er Projekt, mit kleineren Anpassungen und selbstkompilierter SDL). Außerdem habe ich ein neues Spiel angefangen, um zu sehen, wie es läuft. Soll ich gefundene Bugs (aktuell 2, davon einer im Generator) hier melden, oder lieber in einem anderen Thread? Gibt es eigentlich eine Liste mit bekannten Problemen? Ach ja, hat jemand eine Idee, woran es liegen kann, dass sich beim Debuggen nach dem Erreichen eines Breakpoints die Maus in Windows komisch verhält? Der Mauszeiger reagiert nur noch langsam, und scheint unbegrenzt weiter in die letzte Richtung zu wandern, selbst wenn die Maus nicht mehr bewegt wird. Die Maus verhält sich erst dann wieder richtig, wenn die Ausführung fortgesetzt oder das Programm beendet wird. Auch das Wechseln zum Task-Manager hilft, aber nur solange er auch das aktive Fenster ist. Viele Grüße, Mirko RE: Reverse Engineering der NLT II - Shihan - 03.10.2017 Herzlich Willkommen hier im Forum! Bug-Reports zu Bright Eyes passen hier gut rein, zumindest in der Vergangenheit. Gibt es bekannte Probleme? Da bin ich überfragt, aber einer der anderen hat bestimmt 'ne Antwort. Dein Debugger-Problem habe ich noch nie gehört. Welches Windows? Wie sieht denn die Hardware aus? RE: Reverse Engineering der NLT II - Obi-Wahn - 03.10.2017 Willkommen im Forum! Wenn du dich mit GitHub auskennst, gerne dorthin: https://github.com/Henne/Bright-Eyes Ansonsten genauso gerne hier in das Thema. Wir haben bisher (fast) immer nur mit der alten 2008er Version kompiliert, die 2017er Version kann noch unbekannte Bugs hervorrufen. RE: Reverse Engineering der NLT II - Mirko - 03.10.2017 (03.10.2017, 10:57)Shihan schrieb: Herzlich Willkommen hier im Forum! (03.10.2017, 11:53)Obi-Wahn schrieb: Willkommen im Forum! Vielen Dank für eure Willkommensgrüße! Bei GitHub werde ich gleich mal nachschauen, ich kenne mich dort aber bisher nicht aus. Zum Debug-Problem: Es ist Windows 10, 64 Bit. Der Rechner hat einen i5-2500K und 8GB RAM. Die Grafikkarte ist eine Geforce 1060. Eigentlich sollte das fürs Debuggen ausreichen. Ich habe aber inzwischen festgestellt, dass das Problem (oder ein ähnliches) auch auftritt, wenn das Programm ohne Debugger abstürzt, bis die Fehlermeldung geschlossen wird. Vielleicht hat mein Rechner also irgendwo ein Problem mit der Dosbox. Die 2017er Version habe ich hauptsächlich deswegen genommen, weil ich die Version am schnellsten gefunden habe. Mir ist durchaus bewusst, dass es dort Unterschiede geben kann, und ich teste Sachen die mir auffallen auch immer gleich noch in der 2008er Version aus dem Download-Thread und einer unmodifizierten Dosbox. Unterschiede sind mir bisher aber nur zwischen Bright Eyes und einer normalen Dosbox aufgefallen, nicht jedoch zwischen der 2008er und der 2017er Version. Allerdings liegen die Exe-Dateien momentan alle im selben Verzeichnis und greifen dadurch auch auf dieselbe SDL.dll zu. Das sollte ich vielleicht auch noch einmal sauberer trennen. Bis später! ---------------------------------------------------------------------------------------- Edit: Ok, ich bin mir bei Github nicht 100%ig sicher, wie das funktioniert. Ich vermute ich benötige eine Anmeldung und könnte dann Bugs unter "Issues" melden. Ist das richtig? Vielleicht ist es aber erst einmal besser, wenn ich meine Funde hier aufliste. Probleme in Bright Eyes treten dabei, sofern nichts anderes dabei steht, immer in beiden Versionen auf (also selbstkompiliert mit VC 2017 und mit der Downloadvariante): 1. Im Characktergenerator von Bright Eyes führt ein Rechtsklick (oder Esc) bei der Zuweisung von neuen Werten zu positiven Eigenschaften zu einem Absturz. In einer normalen Dosbox scheint das Fenster mit demselben Wert noch einmal geöffnet zu werden. Bei den negativen Eigenschaften verhalten sich alle Versionen soweit man es sehen kann identisch (Fenster wird mit demselben Wert neu geöffnet). 2. Der Wechsel vom Characktergenerator zurück zum Hauptspiel klappt in Bright Eyes nicht. Es erscheint erneut die Abfrage nach der Musik und bei einer Auswahl erscheint oben links ein "Ü" und das Programm bleibt hängen. In der normalen Dosbox erscheint hier die Frage nach dem Spielstand und es geht nach der Auswahl normal weiter. 3. Bei der Anwendung von "Odem Arcanum" konnte ich in allen Versionen Probleme provozieren (in Bright Eyes fallen sie jedoch heftiger aus). Ich habe es in der Stadt (nicht im Lager oder in der Herberge) versucht. Die Probleme treten dann auf, wenn man die Gegenstandsauswahl mit der rechten Maustaste oder Esc abbricht. Die auftretenden Probleme waren dabei Charackterabhängig. Ich habe 3 Magiekundige in der Gruppe. Eine Magierin (Platz 4), ein Waldelf (Platz 5) und eine Firnelfe (Platz 6). Bei der Magierin kommt nach dem Abbruch der Auswahl eine Textbox, bei der in Bright Eyes Textmüll gefolgt von " ist nicht magisch" angezeigt wird. Unter Dosbox erhalte ich die Meldung "Der ist nicht magisch." Beim Waldelf bekomme ich immer (Dosbox und Bright Eyes) die Nachricht "Der Säbel ist magisch behandelt worden." Interessant dabei ist, dass ich keinen Säbel im Inventar habe (gibt es überhaupt einen magischen Säbel im Spiel?). Bei der Firnelfe bekomme ich unter Dosbox die Nachricht "Der ist nicht magisch.", also wie bei der Magierin aber mit mehr Leerzeichen. Unter Bright Eyes ist es hier etwas variabler. Entweder kommt ähnlicher Textmüll wie bei der Magierin, oder aber ich bekomme starke Grafikfehler, wobei es so aussieht, als würde eine sehr große Textbox zerhackt und mehrfach auf den Bildschirm gebracht. Bewege ich mich dann weiter, wird ein Teil des Bildes mit bunten Pixeln gefüllt und ein Teil der Stadtansicht wird erneuert. Ich vermute, dass das Spiel hier nicht überprüft, ob der Nutzer wirklich etwas gewählt hat und die Variablen, die im Anschluss verwendet wurden nicht initialisiert werden. Beim Waldelfen steht dort halt "Säbel" und "magisch", während die anderen Beiden einen leeren String im Original bzw. Textmüll in Bright Eyes und "nicht magisch" bekommen. 4. Als nächstes kommen zwei Probleme in der Zwergenmine von Oberorken. Leider habe ich meinen Spielstand nicht aufgehoben, so dass ich das jetzt nicht wirklich genauer überprüfen kann, wie es in verschiedenen Versionen aussieht. Es kann sich hierbei also um Probleme mit VS2017 handeln. Am Anfang der Mine sollten eigentlich ein paar Gangabschnitte eingestürzt sein, die man erst freiräumen muss. Beim ersten Versuch konnte ich einfach durchlaufen, ohne dass hier etwas passiert ist. Beim zweiten Versuch musste ich beim reinlaufen die hinteren beiden Abschnitte freiräumen, und beim rausgehen die vorderen. Dieser Dungeon ist jedoch einer den ich nicht so gut kenne (früher oft ausgelassen), deswegen bin ich mir bei diesem Problem nicht sicher, ob es evtl. normal ist. 5. Auf der unteren Ebene der oberorkischen Mine, gibt es eine Speergrube über die man zunächst nicht drüber springen kann, weil dort ein unsichtbares Hindernis ist. Bei einem Fehlschlag hatte ich hier unpassende Textteile (der Text wirkte einmal z.B. eher so, als hätte man bei der Wasserfalle versagt und wäre ertrunken, allerdings fehlte der Anfang). Wenn das Überspringen klappt ist der Text aber normal. Auch hier habe ich dummerweise den Spielstand nicht aufgehoben. 6. Ich habe bisher versucht mit zwei Informanten zu sprechen. Isleif Olgardson in Felsteyn und Ragna Firunjasdotter in Vidsand. Bei beiden wollte ich vorher in den Tavernen nach dem Wohnort fragen und das Ergebnis war in beiden Fällen entweder ein Absturz oder die Aussage, dass der Wirt die gesuchte Person nicht kennt. Unter Dosbox geht es aber. Da es sich hier um verschiedene Tavernen in verschiedenen Städten und verschiedene Informanten handelt, bin ich mir nicht sicher, ob es in beiden Fällen derselbe Fehler ist oder ob es sich um zwei Fehler mit dem selben Effekt handelt. Ich melde mich nochmal, wenn ich nach dem nächsten Informaten gefragt habe. Falls ich mein Debug-Problem in den Griff bekomme, kann ich vielleicht auch aktiver nach den Gründen für diese Probleme suchen. ---------------------------------------------------------------------------------------- Edit2: Ich habe eine Lösung für mein Debug-Problem gefunden: https://www.vogons.org/viewtopic.php?f=32&t=43698 Es liegt also an der verwendeten SDL Version und man kann es beheben, indem man vor dem Debuggen die Umgebungsvariable SDL_VIDEODRIVER auf den Wert "windib" setzt. In einem ersten Versuch lief es auch deutlich besser. Allerdings hatte ich jetzt zwischendurch noch einen Absturz bei der Rätselkiste auf dem Totenschiff (nach Eingabe der Antwort). Leider hatte ich auf dem Schiff nicht gespeichert, so dass ich das jetzt noch nicht weiter testen konnte, und auch beim Fragen nach Jurge Torfinsson in Skjal gab es einen Absturz. RE: Reverse Engineering der NLT II - Crystal - 03.10.2017 (03.10.2017, 13:58)Mirko schrieb: Beim Waldelf bekomme ich immer (Dosbox und Bright Eyes) die Nachricht "Der Säbel ist magisch behandelt worden." Interessant dabei ist, dass ich keinen Säbel im Inventar habe (gibt es überhaupt einen magischen Säbel im Spiel?). In allen drei Teilen gibt es keinen magischen Säbel. RE: Reverse Engineering der NLT II - Obi-Wahn - 04.10.2017 Vielen Dank, Mirko! Vielleicht lockt dein Fehlerbericht HenneNWH mal wieder hier ins Forum. Ich muss ja auch zugeben, dass ich die Build-Umgebung momentan nicht bereit stehen habe und auch erst mal alles wieder einstellen müsste. Ich habe BrightEyes bisher immer mit der Version 1.2.13 von SDL kompiliert. Neuere Versionen ergaben früher immer Bugs und Fehler. Welche Version benutzt du? RE: Reverse Engineering der NLT II - Mirko - 04.10.2017 (04.10.2017, 11:29)Obi-Wahn schrieb: Vielen Dank, Mirko! Vielleicht lockt dein Fehlerbericht HenneNWH mal wieder hier ins Forum. Gerne doch! Ich konnte ein paar der Fehler (jetzt, wo ich debuggen kann) auch schon analysieren und habe mir teilweise schon mögliche Lösungen überlegt. Die Punkte 1 und 3 sind grundsätzlich ähnlich. Die Auswahlbox gibt -1 zurück, wenn man abbricht und das wird in beiden Fällen nicht sauber ausgewertet. Bei den positiven Eigenschaften im Generator müsste man den Rückgabewert aufgrund des Datentyps mit 0xffff statt mit -1 vergleichen, wie es bei den negativen Eigenschaften auch schon gemacht wird. Beim Odem Arcanum ist die Sache komplizierter. Bisher (und vermutlich auch im Originalcode) wird der Rückgabewert ungeprüft verwendet um einen Index in das Inventar des zaubernden Heldens zu berechnen. Wenn dort aber -1(bzw. 0xffff) verwendet wird, schaut das Programm natürlich daneben. Eine mögliche Lösung hier wäre, die Auswahlbox solange wieder zu öffnen, bis wirklich etwas ausgewählt wurde (die Astralenergie ist beim öffnen der Box sowieso schon verbraucht). Das klappt aber nur, wenn der Held auch Gegenstände hat, also müsste man das noch prüfen und notfalls die Entsprechende Nachricht ausgeben. Lokal habe ich das so schon bei mir eingebaut. Den Code kann ich entsprechend hier reinstellen, wenn diese Vorgehensweise sinnvoll erscheint. Die Inventarprüfung und Fehlermeldung habe ich dabei aus der Inventarauswahlbox herauskopiert und angepasst. Es kann natürlich sein, dass es dafür bessere Varianten gibt oder ich allgemein einen falschen Lösungsweg gewählt habe. Mir fehlt da definitv noch der Überblick, wie einige Dinge zusammenhängen oder gedacht sind . Der Absturz bei der Frage nach den Informanten liegt daran, dass die entsprechende Funktion zum auslesen der Wohnortbeschreibung einen Zeiger zurückgibt, der dann bei der Formatierung der Ausgabe zu einem Zugriffsfehler führt. Vielleicht haben die falschen Strings in Oberorken und der Absturz auf dem Schiff ähnliche Gründe. Bei SDL habe ich die 1.2.15 genommen. Aber die Probleme treten auch mit den von Dir mitgelieferten Dlls und der entsprechenden Exe auf. |