Virtuelles Dateisystem

[Codewalker]

Außerdem ist es sehr viel Arbeit, Animationen und Grafiken mit Alphakanal spielgerecht aufzubereiten. Die will man auch ungerne als einzelne Dateien dazupacken. Ein klein wenig Verschachtelung in nicht ganz gängige aber zweckmäße Archive ist ganz nett. Allerdings will man ja dafür nicht alle Lade-/Speicherroutinen neu schreiben müssen. Daher also das virtuelle Dateisystem - da läuft alles über Streams und man kann die altbekannten LoadFromStream etc. nutzen

[mimi]

hast du mal ein Beispiel wie das Funktioniert mit dieser Klasse ?

[Olli]

Sucht doch mal nach Win32-Funktionen die mit "Stg" anfangen. Nennt sich Structured Storage und kommt schon mit dem System (OLE-Bestandteil).

[mimi]

naja ich dachte in allgemeines wie das ding Funktioniert ich habe hier keine Win32 Funktionen zu Verfügung unter Linux...

[Codewalker]

@Mimi: Im Prinzip ganz einfach. Gehen wir mal davon aus, du hättest eine DAtei mit folgender Dateistruktur

Code:

\
     \Ordner1
           \Test.txt
           \Bild.bmp
     \Ordner2
          \SubOrdner1
               \Test.txt

Wenn du jetzt die Dateien lesen willst, geht das als Beispiel wie folgt:

Delphi-Quellcode:

var
     Storage: IGpStructuredStorage;
begin
 Storage := CreateStructuredStorage; // Interface instanziieren, daher auch kein Free am Ende
 Storage.Initialize('Test.dat',fmOpenRead); // Die eigentliche Datei öffnen (mit fmCreate wird einen neue erzeugt)
 Memo1.Lines.LoadFromStream(Storage.OpenFile('\Ordner1\Test.txt', fmOpenRead);
 Memo2.Lines.LoadFromStream(Storage.OpenFile('\Ordner2\SubOrnder1\Test.txt', fmOpenRead);
 Image1.Picture.LoadFromStream(Storage.OpenFile('\Ordner1\Bild.bmp',fmOpenRead);
end;

Das ist jetzt aber die absolute Quick & Dirty Methode. Die Funktion OpenFile gibt einen Stream zurück, den ich hier natürlich nicht wieder freigebe. Aber ich wollte es mal so kurz wie möglich halten. Ansonsten verlängert sich der Aufruf um 2 Zeilen (erst Stream holen, dann LoadFromStream aufrufen, dann Stream wieder freigeben).

Ich finde das ganze angenehm einfach und flexibel

@Olli: Stimmt, bin ich auch schon drüber gestolpert. Leider aber auf COM aufbauend und so keinesfalls portierbar (korrigier mich, wenn ich mich irre)

[mimi]

das sieht gut aus, werde ich bei Gelegenheit mal ausprobieren

[Codewalker]

GPStructuredStorage wurde überarbeitet und ist jetzt auch kompatibel mit Delphi 2009 (http://17slon.com/gp/gp/gpstructuredstorage.htm). Alte Archive werden automatisch "geupdated" beim Öffnen. Neue Archive können von alter Version nicht geladen werden.

Die alte Version kompiliert zwar ohne Meckern in Delphi 2009, die entstehenden Archive sind aber nicht verwendbar und nach einmaligem Schreiben ist meist nur noch Datenmüll übrig.

[jbaertle]

Kannst Du noch einen Kommentar zur Lese- und Schreib-Performance insbes. bei vielen kleineren Dateien abgeben?
MfG Jani.

[Codewalker]

Zitat:

Zitat von jbaertle

Kannst Du noch einen Kommentar zur Lese- und Schreib-Performance insbes. bei vielen kleineren Dateien abgeben?
MfG Jani.

Die Komponente ist nicht von mir, daher ... ähm... nein, kann ich nicht :mrgreen: .
Ich nutze Sie aber zum Laden von Texturepaketen in meinem Spiel und kann über die Performance nicht meckern. Ist kaum merklich bisher

[shadowman]

Hallo,

lange her, als hier das letzte Mal gepostet wurde, aber dieser Thread passt zu meinem Anliegen:

wir haben SingleFileDataStorage 1.4.1 im Einsatz, doch dummerweise scheint die Komponente probleme mit Nicht-ANSI-Zeichen zu haben, obwohl bei Torry in der Beschreibung steht, dass Unicode-Dateinamen möglich sind.

Intern in den Sourcen wird mit AnsiString gearbeitet und sobald im Dateinamen z.B. ein "Ş" vorkommt, tritt beim Schreiben dieser Datei ins Archiv ein Fehler auf, dass die Datei XYZ nicht geöffnet werden kann. Im in der Meldung angezeigten Dateinamen sieht man dann ein normales "S" und so heißt die Datei ja nicht.

Die Komponente wird wohl nicht mehr weiterentwickelt, der Author nicht erreichbar...

Da die letzten Posts hier vier Jahre zurückliegen, wollte ich nachfragen, wie es inzwischen aussieht, ob es die weiter oben gennanten Alternativen noch gibt (AidAim und Eldos gibt es wohl), ob es neue gibt und welche der Alternativen der SingleFileDataStorage-Komponente am nächsten kommt (falls man die überhaupt vergleichen kann), damit möglichst wenig geändert werden muss...

Würde mich über Hinweise sehr freuen!