Devblog
Aus FreedsaWiki
Hendrik 11:17, 27. Jul 2009 (CEST)
Ich habe mich in letzter Zeit mal wieder mit dem Dosbox-Logger beschäftigt und versucht, nun auch in Sternenschweif zuverlässig Proben zu loggen.
Grundsätzlich funktioniert das genauso wie in der Schicksalsklinge: Nachdem ich im Assembler-Code des Spiels die random()-Funktion gefunden habe, überprüfe ich alle Funktionen, die diese aufrufen, bis ich alle geeigneten Kandidaten für Proben gefunden habe. Es müssen wirklich alle sein, sonst werden hinterher nicht auch nicht alle Proben geloggt. Für diesen Schritt benutze ich den IDA-Disassembler/Debugger in der kostenlosen 4.x-Version.
Genauso verfahre ich mit Eigenschaftsproben. Anschließend kann ich von der Probenfunktion aus die Funktionen für Talent- und Zauberproben identifizieren, so dass ich nicht nur nackte Zahlen, sondern auch die Namen der geprobten Talente und Zauber ausgeben kann.
Nun hat jeder Befehl im Assemblercode ein Offset und ein Segment, an dem er liegt. Findet nun ein Sprung auf eine der interessanten Funktionen statt, kann ich dies in der Dosbox anhand von Segment und Offset feststellen und dann den Inhalt des Stacks untersuchen, um Variablenwerte auszugeben.
Die Offsets sind klar und finden sich später auch so im Speicher, die Segmente allerdings werden an freie Stellen im Speicher verteilt, und die sind nicht so einfach zu finden. In der Regel reicht es aber, die Segmente zunächst einfach zu ignorieren und später anhand der Ergebnisse des Loggers zu ergänzen.
Mein Problem ist derzeit, dass die Segmente sich an Stellen ändern, an denen sie das nicht sollten, nämlich bei NEAR-CALLs. "NEAR" bedeutet eigentlich, dass der Sprung das Segment nicht wechselt, dennoch kommen meine NEAR-CALLs aus verschiedenen Segmenten - ein Widerspruch. Solange ich diesen Fehler nicht behoben habe (wozu ich erst einmal die Ursache kennen müsste), wird es wohl keine neue Version des Loggers geben.
Hendrik 22:48, 14. Dez 2008 (CET)
Archivformate
Ich habe mich mittlerweile eingehender mit den Archivformaten beschäftigt und versucht, ein gemeinsames Tool für alle drei Teile zu schaffen, das die Archive sowohl entpacken als auch wieder einpacken kann. Die Formate haben alle so ihre Eigenheiten, die beachtet sein wollen.
Bei DSA1 gibt es genau zwei Hauptarchive: Die SCHICK.DAT (bzw. BLADE.DAT in der englischen Version) und die DSAGEN.DAT . Ärgerlicherweise funktionieren beide Archive unterschiedlich. Während die SCHICK.DAT keine Dateinamen enthält und mit einer (in der SCHICKM.EXE definierten!) Liste den Offsets im Archivheader die Dateinamen zuordnet, hat die DSAGEN.DAT einen ordentlichen kleinen Header, der Dateinamen und Offset gemeinsam speichert. Warum man das nicht auch für die SCHICK.DAT benutzt hat und stattdessen diese seltsame Auslagerung in die .EXE vorgenommen hat, ist mir unklar, zumal die winzige Platzersparnis im Archiv durch die Strings am Ende der SCHICKM.EXE wieder wettgemacht wird.
Das DSA2-Archivformat ist schon etwas fortgeschrittener. Die Datei beginnt mit der Anzahl der archivierten Dateien, direkt gefolgt von der Dateitabelle. Die enthält neben Dateiname und Fundstelle im Archiv auch zwei Bytes, die auf den ersten Blick recht seltsam wirken: Stehen sie auf 1, ist die Datei im Archiv, ansonsten nur ein leerer Dummy. Bedenkt man aber, dass die Daten teilweise auf der CD zu finden sind, bekommt diese Einteilung plötzlich Sinn. Steht eine Datei nicht im Archiv, weiß das Programm, dass es auf der CD weitersuchen muss.
Um herauszufinden, in welchem Archiv die gesuchte Datei nun steckt (und als Hilfe beim Packen), gibt es zu jeder .DAT-Datei noch eine gleichnamige .FN-Datei, die eine Liste der potentiell im Archiv steckenden Dateien enthält. Diese Information steht zwar auch im Archiv, aber so kann man sie gleich nutzen, um beim Packen die Dummy-Dateien auch im Archiv zu listen.
DSA3 schließlich hat ein deutlich komplexeres Archivformat, und einige der Headerdaten habe ich nach wie vor nicht identifizieren können. Die Archive enthalten Module, die ihrerseits wieder Dateien enthalten. Man kann sogar eine Datei in mehrere Module einordnen, um Platz zu sparen. Auch die .ALF-Dateien werden wieder von einer Zusatzdatei mit der Endung .MOD begleitet, die eine Liste der Module enthält.
Seltsam ist jedoch die Art und Weise, wie "Schatten über Riva" auf die Archive zugreift. Während die Module direkt mit Namen angesprochen werden, scheinen die Dateinamen gar keine Rolle zu spielen. Riva sucht sich offenbar das richtige Modul und kennt dann die Nummern der einzelnen Dateien. Ein Grund für diese Vorgehensweise will mir nicht so recht einfallen. Wieso über komplizierte Nummern auf Dateien zugreifen? Dadurch wird das Packen des Archives komplizierter. Man muss die Reihenfolge der Dateien beim Packen genauestens befolgen, darf keine Dateien aus einem Modul entfernen oder hinzufügen (höchstens am Ende) und kann nicht z.B. zu Testzwecken während der Entwicklung auf ungepackte Dateien statt des Archives zurückgreifen. Zumal auf die Module ja offenbar nach Namen zugegriffen wird, wieso dann nicht auch auf die Dateien?
Im Endeffekt ist das natürlich sowohl für eventuelle Modifikationen als auch für das Packprogramm unschön. Beim Modifizieren hat man Schwierigkeiten, weitere Dateien einzufügen (was z.B. für eine erweiterte Version der Online-Hilfe nützlich wäre), und für das Packprogramm brauche ich eine sortierte Dateiliste je Archivdatei, die eigentlich nicht nötig wäre. Um aus der Not eine Tugend zu machen, werde ich die Listen wohl im .FN-Format von DSA2 anlegen und dem Packprogramm einfach alle benötigten Archiv-Zusatzdateien beilegen. Dann könnten auch gleich die Dateien aus der SCHICK.DAT aufgenommen werden.
HenneNWH 21:02, 1. März 2008 (CET)
Zwischenbillanz
Innerhalb des letzten Monats hat sich einiges getan:
Die SCHICK.DAT/BLADE.DAT DSAGEN.DAT werden per MD5-Summe geprüft, d.h. es werden nur uns bekannte Datenfiles unterstützt.
Unser Lua wurde von Version 5.0.3 auf 5.1.3 aktualisiert, welche viel schneller, besser und neuer ist. :)
Es gibt Loader für die Animationen aus ANIS und die Menuelemente aus POPUP.DAT. Alle Bilddaten werden mittlerweile korrekt angezeigt. Bei TFLOOR2.NVF, den Stein- und Grasstexturen der Städte, haben wir noch nicht die korrekte Farbpalette. Die Funktion zum speichern von BMP-Bildern wurde entfern, da sie buggy war. Dafür gibt es eine Ausgabe im TGA-Format, welches kleiner, einfacher und schneller als BMP ist. Am liebsten wäre uns PNG, wegen der Größe und der Transparenz. ;)
Ein paar Tweaks wurden an der RLE-Dekomprimierung durchgeführt, was sie um ein vielfaches schneller macht. Die PPunpack-Dekomprimierung hat ähnliche Tweaks nötig, da sie für ein 320x200 Bild (64KByte) mehrere Sekunden benötigt. Grund dafür ist die Art und Weise wie Lua Zeichenketten behandelt. Messungen, die ich bei RLE durchgeführt habe, haben ergeben, dass bei der Dekomprimierung eines 320x200 Bildes über 700MB im Speicher bewegt wurden. Der jetzige PPunpack-Entpacker bewegt sich noch in solchen Größenordnungen.
HenneNWH 21:02, 16. Jan 2008 (CET)
Bekanntmachung
Der nächste Termin für den 2. Developer-Chat ist am Montag, den 21.1.2008 um 21.00 Uhr.
Die Themen unter anderem sein:
- Auswertung der Namensgebung
- Fortschritte (Hendrik wird ein Orden verliehen)
- Die Themen die Ihr noch ansprecht
Zwischenbericht 1/2008
Es hat sich seit dem letzten Zwischenbericht schon einiges getan.
Die größte Änderung ist die Anbindung an Lugre, welche von SiENcE am 12. Jan getätigt wurde (Siehe http://freedsa.schattenkind.net/index.php/Devblog#SiENcE_11:59.2C_13._Jan_2008_.28CET.29).
Die Datei Extract.lua existiert nicht mehr. Ihr Inhalt ist jetzt in lua/main.lua .
Ausserdem müssen die schick.dat/blade.dat/dsagen.dat jetzt in data/ abgelegt werden (der Ordnung wegen).
Achtung: Das in Lugre ist Lua5.0 eingebaut, wesswegen einige Dinge umgebaut werden mussten
Eine kleine, aber sehr wichtige, Änderung kam von Hendrik, welcher einen PowerPack2.0 Entpacker beisteuerte(r30). Ein sehr großer Teil der Daten (Bilder, Animationen) in DSA1 sind mit ihm gepackt. Das bringt uns meilenweit nach vorn, sodass wir bald mit dem Generator anfangen können :)
Ich selbst habe einen Entpacker für die DSAGEN.DAT eingebaut (r28), einen Dosbox-patch geschrieben (r25), der ein ausgeführtes DSA1 in der Dosbox überwachen kann. Ausserdem habe ich einen Fehler im Entpacker der Schick.dat behoben, welcher für eine zusätzliche Datei gesorgt hat(r49). Ihr könnt im work-Ordner die Datei 141 löschen, wenn ihr nicht schick.dat V1.00 habt oder die schick.dat nochmal neu entpacken.
Ein kleines Gimmick zum Schluss:
In der deutschen CD-Version ist das US-Logo von "Realms of Arkania", welches aber garnicht angezeigt wird:
In der englischen Version ist neben dem US-Logo noch ein Logo welches auch nicht angezeigt wird:
SiENcE 11:59, 13. Jan 2008 (CET)
Ich habe gestern ein Lugre Example im SVN geaddet. Das ist nur ein Beispiel zur Nutzung des Lugre sourcecodes.
Lugre ist ein Binding für verschiedene Game-Libraries:
- Ogre3D, Fmod, OpenAL, MD5, CandunTree, Caleum-Skysystem and Pagedgeometry.
Die Entwicklung von Lugre kann man hier verfolgen: http://zwischenwelt.org/trac/lugre/timeline
Um das Beispiel zu starten, einfach den Trunk auschecken und unter Windows im /bin/ Ordner die example.exe starten.
Linux Benutzer benutzen SCons oder Premake.
Edit(HenneNWH):
Installiert die Pakete aus dieser Liste: http://sfz.schattenkind.net/wiki/index.php/Building_from_source#building_under_linux
und startet dann
./premakelinux.sh
wechselt ins Verzeichnis bin
cd bin
uns startet "freedsa"
./freedsa
Edit-End
Wenn man das example startet, sieht man ein erstes 3D-Model. Das ist mehr oder weniger ein farbige Axen.
Das Axen Model ist ein Ogre-Mesh und liegt in der Archiv Datei OgreCore.zip im /data/base Ordner.
Um jetzt mit dem Programmieren zu beginnen, ist es nicht nötig etwas am Cpp-Code oder am example.exe zu verändern! Man geht einfach in den Ordner /lua und öffnet die Datei main.lua mit einem gescheiten Editor der auch Unix Line Breaks erkennt (bitte nicht Notepad verwenden. Danke!).
Dort steht schon viel drinn. Interessant für uns ist aber nur folgender Bereich.
1. ----- your init code here ----
2. Bind("v", function (state) Client_TakeScreenshot(gMainWorkingDir.."screenshots/") end )
3.
4. -- example: displays the axes.mesh from data\base\OgreCore.zip
5. local gfx = CreateRootGfx3D()
6. gfx:SetMesh("axes.mesh")
7. gfx:SetPosition(0,0,0)
In Zeile 1 sehen wir ein Zeilen Kommentar ( initiiiert mit "--" in lua).
In Zeile 2 sehen wir ein Tastenbinding auf die "v" Taste. Wenn man die Taste "v" Drück, wird ein screenshot im /screenshot Verzeichnis erzeugt.
In Zeile 3 steht nix. :)
In Zeile 4 is wieder ein Kommentar
In Zeile 5 wird ein Graphikobjekt mit dem Namen "gfx" erzeugt.
In Zeile 6 weisen wir dem Grafikobjekt ein 3D-Model zu. "axes.mesh" aus dem oben erwähnten ZIP-Archiv.
In Zeile 7 setzen wir das Grafikobjekt an eine Position im Raum. Hier x=0,y=0,z=0.
Das wars. Easy oder? Achja.
Beim Start von example, durchsucht es die Ordner und ZIP-Archive (die in der Datei /bin/resources.cfg gelistet sind) nach Ogre Dateien (*.material, *.mesh, etc...) und indiziert diese. Deshalb braucht man auch keinen Verzeichnisnamen in Zeile 6 angeben.
Wenn jemand mehr mit Lugre ausprobieren möchte, sollte er dieses Tutorial durchgehen: http://lugre.schattenkind.net/index.php/Tutorial_Pong
Ne Dokumentation der Lugre Bindings findet man hier: http://zwischenwelt.org/~hagish/irisdocs/trunk/doc/api_lua/html/
Das war es ersteinmal.
Vg
SiENcE^Florian Fischer
HenneNWH 20:40, 13. Dec 2007 (CEST)
Developer-Chat 12.12.2007 Zusammenfassung
Nachdem so kurzfristig, am 10.12.2007, die Bekanntmachung des 1. freeDSA Developer-Chat ausgerufen wurde,
trafen sich acht Leute im Channel.
Das erste Thema war das Ziel dieses Projektes. Die Entwickler einigten sich,
den Focus auf "Die Schicksalsklinge", den ersten Teil der Nordlantrillogie, zu lenken.
Das grosse Ziel ist ein kompletter "NLT-Client" und die NLT fängt mit Teil 1 an.
Genau wie die Entwickler.
Das zweite Thema war die Namensgebung.
Es wurde schnell klar, dass FreeDSA kein guter Name für das Projekt ist,
da "Das Schwarze Auge" ein eingetragenes Warenzeichen ist.
Zitat: ... Borbaradwurm: Das Schwarze Auge ist ein Warenzeichen und kann nicht einfach so von dritten (also freeDSA) benutzt werden ... Obi-Wahn: Wenn ihr die Erlaubniss bekommt NLT zu benutzen, wäre ich für OpenNT ;) Obi-Wahn: OpenNLT SiENcE: Ich möchte eigentlich garkeine Erlaubnis haben. ... SiENcE: Denn wenn wir diese bekommen, kann sie uns auch wieder entzogen werden ! ...
Es wurde sich darauf geeinigt einen Rundruf unter [1] zu starten und gemeinsam mit den zukünftigen Usern einen Namen zu finden.
Das letzte Thema war der nächste Schritt.
Zitat: Borbaradwurm: es sollte an diesem Punkt darum gehen die original daten so gut wie möglich zu dokumentieren
Daraufhin bildete sich eine Reverse-Engineering-Task-Force, bestehend aus Borbaradwurm, Hendrik und HenneNWH, um die notwendigen Dokumentationen zu erstellen.
Ziel soll es sein die Datei DSAGEN.DAT komplett zu dokumentieren, welche vom Helden-Generator benutzt wird.
Der nächste Chat soll nach Weihnachten statt finden.
Interessierte können den komplette Developer-Chat-Nr001 nachlesen.
HenneNWH 8:40, 6. Dec 2007 (CEST)
Seit dem Fix von Daniel (Revision 14) hat sich einiges getan.
Im Moment haben wir Revision 22, welche uns einen mit Dialogen (TLK) umgehen kann.
Desweiteren werden beim Entpacken von Schick.dat/Blade.dat automatisch die Animationen
in separate Unterverzeichnisse entpackt.
Dabei handelt es sich um die Archive ANIS MFIGS MONSTER WFIGS.
Die Animationen aus ANIS sind schon zugeordnet, allerdings haben wir zwei Animationen bekommen,
welche noch nie im Spiel gesehen wurden.
Shazu 14:04, 27. Sep 2007 (CEST)
Daniel hat es geschaft und den NVF Loader soweit korrigiert, dass nun alle Bilder des Typs 05 (alle Texturen aus Städten und Dungeons!) korrekt entpackt werden! Damit wären also nun das Layout sowie die Texturen von Städten und Dungeons fertig :).
Shazu 13:04, 23. Sep 2007 (CEST)
Das NVF-Format sollte nun fast komplett dokumentiert sein, der NVF-Loader kann auch schon Archive des Typs "05" entpacken. Teilweise sind die entpackten Bilder aber schief und benötigen Korrekturpixel. Hier einige Beispiele:
 |
 |
 |
Ich hab das Bild mal eingefügt, damit die Leute auch nen Fortschritt sehen (SiENcE):
 |
- Klingt gut mit dem Bild. Das wäre ein Anfang. --SiENcE 22:00, 18 September 2007 (CEST)
Shazu 16:05, 18. Sep 2007 (CEST)
Ich habe leider zur Zeit ebenfalls mit einem anderen Projekt relativ viel zu tun, deshalb sieht das ganze hier vllt. etwas inaktiv aus. Trotzdem habe in den letzten Tagen die Dokumentation für die DDT Daten hinzugefügt und den entsprechenden Loader vervollständigt. Auch am Grafikformat habe ich mich mal wieder versucht, ich konnte die Daten zumindest teilweise sinnvoll auslesen und ein daraus ein Bild erzeugen, das dem im Spiel angezeigt Bild zumindest grob ähnlich sieht.
SiENcE 13:15, 2 September 2007 (CEST)
Wie ich gesehn habe, hat Shazu den Städteloader eingebaut und auch die Doku dahingehend angepasst. Ich widme mich gerade meinem zweiten Projekt Iris-Online und baue dort grad den Server auf. Vielleicht hat ja einer der DSA leute mal lust in Iris2 und Ultima Online reinzuschaun :-) ? Mit FreeDSA wirds bei mir weitergehen sobald, der Server online ist (vermutlich Anfang Oktober). Bis dahin bitte bei Fragen an Shazu wenden.
Shazu 23:57, 5. Sep 2007 (CEST)
Ich bin nun aus meinem Urlaub zurück und werde hier auch aktiv dabei sein, zum Beginn hab ich schon mal die Layout-Daten der Städte dokumentiert.
SiENcE 13:15, 2 September 2007 (CEST)
Seit einigen Tagen bin ich dabei alle Informationen über die Dateiformate von DSA:NTL1 zusammenzutragen.
