(20.02.2013, 19:18)Hendrik schrieb: [ -> ]Zu ACE und BOB kann ich sicher noch etwas beitragen, mal schauen, ob ich jetzt am WE dazu komme.
An den 3D-Dateien habe ich zwar schon ein wenig experimentiert, bin aber noch nicht wirklich weit gekommen.
also zu ACE steht schon was im wiki, das kannst du ja mal mit deinen Informationen abgleichen und eventuell was ergänzen.
Bei den BOB Dateien haben ich noch meine Gesammelten Daten vom ANIS Archiv aus DSA 1, die stehen allerdings noch nicht im wiki. Aber wenn du was hast kannst du ja gerne schonmal anfangen was einzutragen (ist übrigens im wiki als "BOB" verlinkt. Findest du auch unter 10.1 (
http://freedsa.schattenkind.net/index.php/STAR.DAT ))
also ich habe mal einen Blick auf das 3D format geworfen und es ist unglaublich schwer da auch nur irgendwas an Informationen herauszubekommen.
Weiss man eigentlich welches floating Point format in DSA 2 benutzt wurde? (durch Integer(16-Bit / 32-Bit) Simuliert oder nach Floating Point IEEE Standard(16-Bit/32-Bit) )
Vielleicht könnte man die Zugriffe auf die Datei loggen, und so etwas über das Format herausfinden? Wie wäre es mit einem eigenen Thread?
Da zur Zeit von Schweif 486SX noch ziemlich aktuell war, würde ich auf Simulation tippen.
EDIT: Ich würde sogar soweit gehen, und fixed point vermuten. Das war einfach schneller und ziemlich üblich.
Die Bytes in den .3D-Dateien sehen schon eher nach Gleitpunkt-Zahlen aus (ganz sicher bin ich mir da natürlich nicht). Welches Format sie genau haben, habe ich noch nicht herausfinden können, so viel Arbeit habe ich aber auch noch nicht reingesteckt. Momentan versuche ich eher, den 3D-Code von Sternenschweif zu verstehen und praktisch über den Assembler-Code hinter das Dateiformat zu kommen.
also float nach IEEE Standard schließe ich mitlerweile weitesgehend aus, die 16 Bit variante ist noch recht neu und die 32 Bit variante liefert auch nichts anständiges.
Int 16 und Int 32 sehen auch nicht sehr brauchbar aus.
Dann hab ich noch ein simulierten float aus einem Int 32 versucht, der liefert allerdings auch nicht sonderlich brauchbare Werte.
Aber was mich bisher am meisten stört, ist das es keine 0 Bytes in den Dateien gibt.
Edit: am wahrscheinlichsten scheint mir eine Byte codierung
Edit 2: oder kennt wer noch ein paar alte float simualtionen?
Ich habe mal ein bisschen mit git experimentiert:
Siehe
https://github.com/hjr448/ShallowEyes
Nachdem mir doch einiges in git noch nicht klar ist, bin ich froh, erstmal im eigenen Repository zu experimentieren...
finde ich gut, werd ich mir mal bei gelegenheit genauer anschauen
Hab mal mein gesammeltes Wissen zu ACE und BOB ins Wiki einfließen lassen.
Mit den 3D-Dateien hatte ich wie gesagt vor einiger Zeit schon mal experimentiert, hier meine Notizen von damals zu diesem und anderen Formaten, fürs Wiki sind die noch nicht strukturiert genug:
Dem Namen nach sicherlich irgendwelche 3D-Daten. Das Format verstehe ich noch überhaupt nicht. Und vor allem, wieso benötigt man für jede Tür, jedes Haus und so extra Dateien? Vielleicht sind das zum größten Teil Texturmaps.
[2011-01-30 Sun] Und 3D-Daten. Irgendwo ist darin ein Index auf die Textur versteckt, wie genau das funktioniert, weiß ich noch nicht.
Interessant ist jedenfalls, dass die Texturen offenbar kategorisiert sind: Bei Experimenten mit Bodentexturen haben sich bei bestimmten Bytes die Texturen geändert. Bei einer ganz bestimmten Folge war es die "dirt"-Textur, alle anderen ergaben die "rasen"-Textur.
Ebenfalls wissenswert: Ob ein Gebäude begehbar ist oder nicht (und teilweise auch die Funktion), wird durch die .3D-Datei gesteuert: Wenn man tent2.3d durch tent1.3d ersetzt, ist in Kvirasim jeden Tag Markt -- wenn das Zelt begehbar aussieht, ist es auch begehbar! Ersetzt man aber tent2.3d durch temple.3d, kann man auch das Gebäude betreten. Es ist aber kein Marktstand, auch kein Tempel, sondern ein normales Bürgerhaus! Faszinierend.
Die .CYB-Dateien sind identisch zu den .DBG-Dateien mit gleichem "Vornamen". Siehe dort.
Ausnahmen sind: gashok, kvirasim, lowangen, tiefhusen, die sich an einigen Stellen unterscheiden.
Auffällig ist, dass alle DBG-Dateien entweder leer sind (ansvell, blut4, rorkvell) oder genau 767 Bytes groß.
In den nichtleeren Dateien sind oft lange 0er-Sequenzen mittendrin.
CYBER.SIN: Der Erweiterung nach vielleicht eine Sinus-Tabelle? Aber wieso sollte man die hart als Datei speichern? 2048 Bytes lang.
TOPICS.TOP: Liste mit den Themen, nach denen man im Dialog fragen kann.
SAMPLE.AD, SAMPLE.MT: Vermutlich eine Wave-Bank oder so etwas ähnliches (Parameter für den FM-Chip)
(24.02.2013, 15:57)Hendrik schrieb: [ -> ]CYBER.SIN: Der Erweiterung nach vielleicht eine Sinus-Tabelle? Aber wieso sollte man die hart als Datei speichern? 2048 Bytes lang.
Solche Tabellen wurden in 3D-Demos häufig verwendet, um Drehungen im euklidischen Raum mit Fixpunkt-Arithmetik zu beschleunigen. Normalerweise wurden sie im Speicher bei jedem Programmstart generiert.
@Hendrik
das sieht doch schonmal ganz gut aus, da kann ich gut dran ansetzten
(24.02.2013, 19:28)Rabenaas schrieb: [ -> ] (24.02.2013, 15:57)Hendrik schrieb: [ -> ]CYBER.SIN: Der Erweiterung nach vielleicht eine Sinus-Tabelle? Aber wieso sollte man die hart als Datei speichern? 2048 Bytes lang.
Solche Tabellen wurden in 3D-Demos häufig verwendet, um Drehungen im euklidischen Raum mit Fixpunkt-Arithmetik zu beschleunigen. Normalerweise wurden sie im Speicher bei jedem Programmstart generiert.
Und genau letzteres verwirrt mich ja dabei. Der Zweck einer Sinustabelle ist klar, die wird verwendet, um Berechnungen der 3D-Engine zu beschleunigen. Aber normalerweise generiert man so etwas doch zur Laufzeit und schreibt es nicht in eine Datei. Dabei kommt mir ein Gedanke: Wenn die Hypothese stimmt, dass es sich um eine Sinus-Tabelle handelt, könnte man daraus vielleicht das Format für die Kommazahlen in Sternenschweif ermitteln. Das würde wiederum die Entzifferung der .3D-Dateien erleichtern.
(25.02.2013, 13:26)Hendrik schrieb: [ -> ]Und genau letzteres verwirrt mich ja dabei. Der Zweck einer Sinustabelle ist klar, die wird verwendet, um Berechnungen der 3D-Engine zu beschleunigen. Aber normalerweise generiert man so etwas doch zur Laufzeit und schreibt es nicht in eine Datei.
Angenommen CYBER.SIN ist tatsächlich eine Sinustabelle, wäre das gar nicht abwegig: ab einer bestimmten Tabellenlänge ist es schießlich, von der Ladezeit gesehen, schneller eine solche Tabelle von der Festplatte in den Arbeitsspeicher zu laden anstatt diese Werte auf einem
386SX (mindest-Prozessor-Anforderung von Sternenschweif) zu generieren. Die
RAW-Texturen der 3D-Engine scheinen aus ähnlichem Grund auch komplett auf Kompression zu verzichten.
Definitiv eine Sinustabelle. Mein Bildlabor hat mir ein schönes Sinus-Bild ausgegeben, wenn ich die Ziffern als 4-Byte-Fixkommazahlen ansehe (Bild + Ruby-Codeausschnitt folgen).
Code:
while not f.eof
z = f.read(4).unpack("C4") # 4 Bytes lesen und deren Werte in z speichern
sign = (z[3] & 0x80 == 0) ? 1 : -1 # Sign festlegen
mantissa = (z[3] & 0x7F) << 24 | z[2] << 16 | z[1] << 8 | z[0] # Zahl in lower endian festlegen
if sign < 0 then mantissa -= 2**31 end # Sign verarbeiten
fixpt = mantissa / (2**31).to_f # Größe auf Bereich [-1,1] anpassen
points.push(fixpt) # Rein ins Array
end
[
attachment=3252]
Damit sollte die Analyse der 3D-Dateien deutlich einfacher werden.
Warte mal, die Zahlen sind unsigned Integer-Words (kein Zweierkomplement) mit einem Bit für das Vorzeichen, die alle durch 2^31 geteilt werden? Ist das nicht ziemlich merkwürdig?
ja so ganz verstehen tue ich das format auch nicht, scheint aber irgendwie ans floating Point format angelegt zu sein.
Edit: interessant ist auch, dass die Zahlen 0, -1 und 1 nicht exakt dargestellt werden können.
Edit2: vielleicht hat ja jetzt noch jemand lust sich dem 3D format anzunehemen. Ich habe nämlich insgesammt nicht sehr viel Zeit und es sind noch einige Dinge zutun bis der DSA 2 Support meines Tools fertig ist.
Und je mehr ich bis zu den Schicksalsklinge Beta Test fertig habe umso besser ist die Ausgangssituation für die Neuaflage von Sternenschweif
Edit 3: bevor ichs vergesse, ich hatte mir mal schnell ein kleines Programm geschrieben welches die Daten einer Datei in verschieden Zahlenformaten anzeigt.
erst beim zweiten hinsehen habe ich bemerkt, das Hendrik nur einen gewöhnlichen Int32 Wert eingelesen hat und ihn auf den Wertebereich [-1,1] abgebildet hat.
@Hendirk, um aber ganz genau zu sein, müsstest du bei positiven Werten durch (2^31 - 1) teilen.
(26.02.2013, 09:20)tommy schrieb: [ -> ]erst beim zweiten hinsehen habe ich bemerkt, das Hendrik nur einen gewöhnlichen Int32 Wert eingelesen hat und ihn auf den Wertebereich [-1,1] abgebildet hat.
@Hendirk, um aber ganz genau zu sein, müsstest du bei positiven Werten durch (2^31 - 1) teilen.
Es ist ein unsigned Int32. Das Vorzeichen wird durch ein Flag gesetzt. Das ist afaik eher ziemlich ungewöhnlich.
Nein, da hat Tommy schon ganz recht, das ist ein ganz normaler signed int. Das kommt davon, wenn man bei Experimentieren von der falschen Annahme ausgeht und dann so lange herumfrickelt, bis es klappt. Jedenfalls weiß ich jetzt besser über die String::unpack-Funktion von Ruby bescheid.
Einfacher geht es so:
Code:
z = f.read(4).unpack("l")[0] # lese ein 32-bit signed integer
fixpt = z / (2**31).to_f # Wertebereich anpassen auf [-1,1]
points.push(fixpt) # Und ins Array schreiben.
Hey Leute, hab ich das nur übersehen oder lässt sich wirklich nicht feststellen, welcher Tempel auf der Dorfkarte zu welcher Gottheit gehört (DSA1 natürlich
)? Ich kanns mir irgendwie nicht vorstellen, dass das nirgendwo zum Rauslesen ist, evtl. hab ichs einfach vor Betriebsblindheit überlesen oder übersehen - danke für die Hilfe schon mal im Voraus