Hi,

für einen Mapeditor an dem ich zur Zeit klebe/schreibe, brauche ich extrem große Heightmaps usw.. Darum schreibe ich grade an einem eigenen Dateiformat dafür. Da die Daten recht imense Größe annehmen können, habe ich mich dafür entschieden eine Klasse zu schreiben, die quasi alle Änderungen in die Datei schreibt, ohne viel im Arbeitsspeicher zu haben.
Nun häng ich allerdings an dem ganz simplen Problem, einfach mal die Auflösung zu ändern.
Ich arbeite jetzt zum ersten mal mit einem FileStream gibt es eine Möglichkeit die Dateilänge zu ändern und dann erst zu beschreiben? Bzw, wenn die Größe kleiner wird, nur der Rest "abgeschnitten" wird? Wenn die Datei größer wird, sollen die bisherigen Daten noch bestehen.
Die einzige Möglichkeit zu Vergrößern, die mir bisher eingefallen ist, einfach solange 0 zu schreiben bis ich genug Platz in der Datei hab um die Daten der neuen Auflösung entsprechend anzupassen. Sehe ich aber als eine äußerst "schreiblastige" Variante an, da zu dem Zeitpunkt noch nicht mal die eigentlichen Daten geschrieben werden.
Zeck des Dateiformats ist quasi ein "Bild" mit beliebig-vielen Kanälen und einer riesiegen Auflösung (gut und gerne mal 250.000x250.000 "Pixel")
Durch die extreme Größe kommt naturlich ein Anlegen einer temporären Datei eigentlich überhaupt nicht in Frage.
In viele kleine Dateien möchte ich es auch nicht aufsplitten.

Ich befrage Google jetzt schon seit mehreren Tagen, aber habe irgendwie nichts brauchbares gefunden

mfg,
bubble

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Hey,

einfach TFileStream.Size auf die gewünschte Größe setzen. Dann erstellt der Filestream eine "leere" Datei mit der angegebenen Größe. Aber ich glaube du solltest vlt dein Konzept nochmal überdenken. Schreib doch die wichtigen Daten an den Streamanfang. Sodass die Nutzdaten beliebig nach hinten erweitert werden können. Dann kann die Datei wachsen, wenn es nötig ist...

€: Die Dateigröße ändert sich bei einem Write automatisch, wenn Position + SizeOf(Data) < Size. Normalerweiße muss man die Dateigröße also vorher nicht festlegen.

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

du solltest schon eine Aufteilung in mehere kleine Dateien in betracht ziehen sonst hast du wie du schon bemerkt hast nichts als Probleme bei Erweiterungen des Formats usw.

_________________
Meine Homepage

Hmmm, dann werd ich am besten das ganze Konzept nochmal überdenken =/
Danke für die Hilfe

mfg
bubble

_________________
Wenn Worte nichts als Worte sind,
dann müssen's Steine sein!
Solange - bis sie pleite sind - schmeißt Fensterscheiben ein!
- Fidl Kunterbunt -

Wenn du das Bild in Einzelbilder von sagen wir 4096x4096 aufteilst kannst du diese komprimieren, etwa verlustfrei mit GZIP (=> nach zlib suchen). Das sollte die Ladegeschwindigkeit massiv erhöhen, weil die Festplatte dein Flaschenhals sein wird, nicht der Arbeitspeicher/CPU. Beim bearbeiten oder lesen des Bildes dekomprimierst du immer nur den Teil den du gerade benötigst in den Arbeitspeicher. Für jedes Sub-Image verwendest du entweder eine eigene Datei (einfache, nicht unbedingt schlechte Lösung) oder du implementierst eine eigene Speicherverwaltung innerhalb der großen Datei. Das Problem ist ja das die Dateigröße eines Subimages schwanken kann wenn du etwas im Bild änderst.

Natürlich musst du die Größe und Form dieser Sub-Bilder deinen Algorithmen anpassen. Wenn du etwa das Bild zeilenweise durchläufst solltest du besser auch zeilenweise komprimieren. Beim rendern wäre wahrscheinlich die quadratische Variante besser, weil du ja auch am ehesten einen quadratischen Bereich siehst.

_________________
Yeah!