Streetfighter Alpha II S-DD1 Dekomprimierung

[snoer]

Ganz vorweg:
Ich habe beim schreiben dieses Threads gemerkt, dass es mir kräftig an knowlege fehlt um das was ich hier beschreibe in die Tat umzusetzen.
..weil ich frei von Schahm bin erstelle ich den Thread nun trotzdem.
Vielleicht inspiriert das ganze ja irgend jemanden dazu das ganze selbst in die Tat umzusetzen, oder erklärt mir, was ich alles tun müsste um es selber zu tun.
--

Moin,
vorweg weise ich weise ich darauf hin, dass ich mich der Phantasie hingegeben habe, es sei mir möglich so wie es für Star Ocean geschehen ist, das Streetfighter Alpha II ROM zu dekomprimieren und zu extenden um ein ROM zu erhalten, das ohne S-DD1 auskommt.
(Ich könnte mit vorstellen, dass das größenwahnsinnig ist)

Aber wie sagt man so schön "Es gibt keine Dummen Fragen.."

ich habe mir die Dokumentation zum S-DD1 Algorytmus runtergeladen.

The folder "decomp" contains the two main files for the S-DD1 emulation
(only some typedef's are needed to make them work)

Ich habe mir den Code angesehen und soweit ich das verstehe ist das ganze die implementierung des decompressors.

ich habe (ohne ernsthaft zu wissen was ich tue) folgende typedefs hinzugefügt.

Code: Alles auswählen

typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned char bool8;

daraus kann ich schonmal eine objectfile kompilieren.
eine "executable" kann ich daraus ohne main Funktion nicht kompilieren.

So.. jetzt habe ich weiter Phantasiert, ich könnte mit hilfe dieses decompressors die gesamten Grafiken dekomprimieren indem ich eine Datei byteweise durch den decompressor schiebe, und aus den dekomprimierten Daten eine output datei erzeuge.

Das ist dumm oder?
Wie müsste ich vorgehen?

--
ein bisschen schähme ich mich jetzt doch..

[ChronoMoogle]

Ich glaube genau so wurde lange Zeit Far East of Eden Zero emuliert. Man musste sich Pakete mit den dekomprimierten Tiles runterladen und die wurden in den Emulationsprozess eingebunden. Als ich das Spiel das erste mal Probeweise spielen wollte, war das glaube ich noch so.

Wie das bei Star Ocean laeuft, weiss ich nicht so wirklich. Ich hoffe dir kann da jemand weiterhelfen...

[Christian]

Wie das bei Star Ocean laeuft, weiss ich nicht so wirklich. Ich hoffe dir kann da jemand weiterhelfen...

Er hat sich Street Fighter Alpha 2 vorgenommen.

[ChronoMoogle]

Ja, sein Projektziel ist aber wortwoertlich so:

Moin,
vorweg weise ich weise ich darauf hin, dass ich mich der Phantasie hingegeben habe, es sei mir möglich so wie es für Star Ocean geschehen ist, das Streetfighter Alpha ROM zu dekomprimieren und zu extenden um ein ROM zu erhalten, das ohne S-DD1 auskommt.

[Christian]

Ich möchte nur anmerken, dass ich es absolut befürworte und für genial erachte, ein "entpacktes" ROM von SFA2 zu erstellen!

[snoer]

Ja richtig, ich würde mich gerne an SFA2 versuchen.
Theoretisch sollte das ja auf ähnlichem Wege umsetzbar sein,
den der Autor des "Star Ocean no-S-DD1/96Mbit hacks" gegangen ist.
Vielleicht hat ja irgendjemand hier die Möglichkeit ihn zu fragen, wie er vorgegangen ist.
Ich meine neulich irgendwo gelesen zu haben wer der Autor ist (Nevitski hat nur den patch erstellt) aber ich weiss nichtmehr wo ich das gelesen habe.

[lytron]

First of all: Das ist ein großes Projekt, und damit wünsch ich dir viel Erfolg! Leider kann ich dir da nicht beistehen, da ich vom Hacking keine Ahnung habe und gerade erst selbst die ersten Schritte mache (wie ich hier ja auch lang und breit dokumentiere); außerdem gehe ich bestimmt nicht den galantesten und zeiteffizientesten Weg dabei, deswegen wäre ich da wohl ein blinder Führer, würde ich dir Ratschläge geben.

Wenn ich dich richtig verstanden habe, scheinst du die Möglichkeit zu haben, die Grafiken zumindest einzeln dekomprimieren zu können. Würdest du es einzeln machen, wäre das zeitaufwändiger, aber du könntest zumindest bei jeder Grafik als Zwischenschritt checken, ob die Implementierung der dekomprimierten Grafik geklappt hat.

[snoer]

Also ehrlich gesagt glaube ich, dass ich den Mund an dieser Stelle zu voll nehmen würde, würde ich behaupten auch nur im Ansatz zu wissen wie ich das ganze angehen will.
Wie gesagt. Es fehlt mir auf jeden Fall an Wissen um auch nur ansatzweise irgendentwas konkretes umsetzen zu können.

An dieser Stelle mache ich einen Rückzieher und melde mich zurück, wenn ich mit Fakten oder konkreten Fragen auftrumpfen kann. Ich glaube ich war etwas übermütig und naiv, als ich den thread gestartet habe.

[Ramsis]

Die Herausforderung des ganzen Projekts -- das ich übrigens durchaus für sinnvoll halte (würde es doch neues Futter für mein PowerPak bedeuten ) -- besteht hauptsächlich darin, das ROM dahingehend umzuhacken, dass es die unkomprimierten Grafiken auch benutzt. Hierzu muss jeder einzelne S-DD1-Aufruf im ROM gefunden und durch eine entsprechende Routine ("Lade Grafik/Tilemap/Palette von Offset $XXXXXX") ersetzt werden. Und das können locker Tausende Aufrufe sein.

Die Dekomprimierung der Grafiken selbst ist im Prinzip unnötig, denn es gibt ja die Graphics-Packs aus den Zeiten der Mainstream-Emulatoren ohne native Unterstützung für den S-DD1. Sofern man die parat hat, kann's im Prinzip direkt losgehen.

Die dekomprimierte Version von Star Ocean stammt meines Wissens übrigens tatsächlich direkt von Neviksti.

[snoer]

"I am not the author of this hack but I was given permission to upload a patch for it."
..steht in der readme

Hierzu muss jeder einzelne S-DD1-Aufruf im ROM gefunden und durch eine entsprechende Routine ("Lade Grafik/Tilemap/Palette von Offset $XXXXXX") ersetzt werden. Und das können locker Tausende Aufrufe sein.

aber ist es nicht so, dass diese Aufrufe, da sie mutmaßlich die selbe Funktion benutzen, ein konstantes "bit pattern" haben? sodaß man sie relativ zuverlässig identifizieren kann?
ich hätte jetzt gedacht, dass man nach diesem bitpattern suchen kann..
das einzige was sich ja unterscheiden würde wäre das "argument" also quasi das data offset der komprimierten datei.

dieses offset könnte man quasi als seed nutzen um das neue offset der dekomprimierten datei zu errechnen.
wenn man nun das "neuen rom" erstellt würden man die offsets der grafiken also nicht willkürlich verteilen, sondern aus diesem seed errechnen.
im letzten schritt würde man die s-dd1 funktion ersetzen durch eine funktion welche die neue grafikposition aus dem seed errechnet und an die grafik-lade-funktion weitergibt.
hab hier mal ne grafik gemacht um zu illustrieren wie ich es mir vorstelle..

sofa2-hack_maybelikethis.png (115.25 KiB) 4850 mal betrachtet

das ganze ist aber nur daher phantasiert und ist eventuell unrealistisch (ich kann das garnicht genug betonen ":))

[ChronoMoogle]

Ich hab den Thread mal zu Romhacking verschoben

[Ramsis]

"I am not the author of this hack but I was given permission to upload a patch for it."
..steht in der readme

Ja, die Readme ist leider höchst missverständlich. Das Ganze war meines Wissens so: Neviksti hat vor vielen Jahren die dekomprimierten Versionen der ROMs erstellt. Irgendwann kam jemand auf die Idee, dass man die doch am besten als Patches verbreiten sollte, nicht als ROMs. Dieser Jemand hat die Patches erstellt und die Readme geschrieben -- und Neviksti darin als einzigen Urheber genannt.

"Ich" in der Readme != Neviksti.

aber ist es nicht so, dass diese Aufrufe, da sie mutmaßlich die selbe Funktion benutzen, ein konstantes "bit pattern" haben? sodaß man sie relativ zuverlässig identifizieren kann?

Ja, Deine Überlegungen gehen absolut in die richtige Richtung, denke ich.

Übrigens fällt mir gerade ein, dass man sich womöglich viel Arbeit sparen könnte, wenn man einen Blick in die Sourcen einer alten ZSNES-Version o. ä. werfen würde, welche die Graphics Packs unterstützt. Da müsste ja schließlich ein vergleichbarer Algorithmus implementiert sein, der mindestens auf die ganzen Grafik-Offsets schließen lässt!

[lytron]

Ich misch mich nochmal kurz ein:
Ich hatte mich vor einem halben Jahr mal mit der Funktionsweise des SDD1 auseinandergesetzt, hatte dabei Unterstützung erhalten, ansonsten hätte ich nichts davon verstanden. Ich hatte da einige grafische Darstellungen gemacht, um das Ganze leichter verständlich zu machen, wie das Ding funktioniert. Leider kann ich bei vielem nicht mehr hundertprozentig wiedergeben, was ich mit den Darstellungen meinte... aber vielleicht hilft es.

Bild eins Die Daten haben einen 4-Byte-Header, wobei die ersten beiden Bytes anzeigen, wie die einzelnen Bitplanes ineinander verwoben sind.
Bild zwei Die letzten beiden Bytes geben an, inwieweit auf vorherige Bits bezug genommen wird. Hier setzt mein Wissen schon wieder aus.

Bild drei Es gibt eine Dokumentation der SDD1-Dekomprimierung von Andreas Naive, auf deren Grundlage ich diese Zeichnungen gemacht habe. Die Dokumentation ist leider an einigen Stellen ungenau und gelegentlich missverständlich, meine ich.

Bild vier Noch ein Flussdiagramm, an einigen Stellen von Andreas Naives Fassung abweichend, um es genauer darzustellen.

Darüberhinaus habe ich einige allzu bildliche Darstellungen gemacht:
1 2 3
4

Abschließend hatte mein "Unterweiser" mir gesagt, dass der SDD1 quasi über eine Art DMA-Register angerufen wird. Es sieht aus wie ein DMA-Register und wird, meine ich, auch eins zu eins so bedient, nur werden vor der Übertragung die Daten dekomprimiert. Wenn man die Adresse dieses Registers herausbekommt, kann man sicherlich "recht einfach" die Grafikdaten bestimmen.