Asset-Management mit Archiven

Ok, dann werde ich anfangs mal probieren das zusammenzuhalten. Das mit dem xoren von Dateien nutze ich aktuell um das Archiv wenigstens bisschen zu "verschlüsseln" um einen direkten Zugriff zu vermeiden - wie funktioniert das denn beim Patchen? Ich kann mir vorstellen, dass es etwas komplizierter werden kann, wenn die Dateigrößen unterschiedlich sind vor/nach dem Patchen. Hast du ein kurzes Beispiel oder einen Link im Netz?

rapso

Christian Ivicevic schrieb:

Beim Update beziehe ich mich drauf, dass ich beispielsweise neuen Content anbieten will, der automatisch runtergeladen wird. Hierbei ist es viel einfacher diesen neuen Content in bspws. einer Game.003 anzubieten und eine neue Indexdatei mitzuliefern anstelle eine riesige Game.dat jedes Mal herunterladen zu müssen. Sozusagen ein "inkrementelles Update". Alternativ könnte man sagen: wenn beispielsweise eine neue Map zum Spiel dazukommt, dann wird nur das Archiv mit alles Maps geupdated und das Archive mit anderen Dateien kann ignoriert werden.

tjo, hat es irgendwelche vorteile wenn du archive updatest? ansonsten klingt ein neues archive doch ausreichend. wobei ich mir nicht sicher bin was du mit index datei mitliefern meinst, es hat doch eh immer jedes archive eine index datei, sonst kann man mit den daten darin wohl nichts anfangen, wuerde ich annehmen.

Das Erzeugen dieser Archive ist für den Moment noch sehr einfach gestrickt und sequentiell implementiert - könnte aber durchaus parallelisiert werden, wie du meinst. Mir geht es in erster Linie darum herauszufinden, ob etwas dafür spricht, nicht nur bei neuen Releases/neuem Content zu Splitten, sondern auch so mit dem Hintergedanken, ob es denn effizienter ist große Datei als Stream zu öffnen und sie bis zum Ende offen zu lassen oder ständig kleine Dateien zu öffnen, den Inhalt zu laden und dann wieder zu schließen.

eine grosse datei die du per memory mapped file aufmachst ist wohl das effizienteste falls genug addressraum vorhanden ist, aber ob du 5x 100MB aufmachst oder 1x500MB wird nicht merkbar sein, eher wenn du 500000x100kb aufmachen wuerdest.
das OS kuemmert sich dann z.b. drum dass daten read-only sind und schreibt sie nicht zurueck, sondern invalidiert nur den eintrag in der eigenen tabelle. wenn du per hand speicher allokierst und dann freigibst um mit den dateien zu arbeiten, hast du schlechtere speichernutzung und musst es explizit machen, waerend das OS einfach den speicher nutzt den das host system zur verfuegung hat.

dot

Es hängt auch davon ab, was genau du mit den Dateien machen wirst. Wenn du einfach beim Start einmal jede öffnest und in einem Stück von vorn bis hinten durchliest und das wars, dann wird Memoy Mapped I/O z.B. auch kaum einen Unterschied machen...

rapso

cooky451 schrieb:

... wesentlich intelligenter patchen: Man speichert Stellen + Werte mit denen man die Original-Datei xoren muss. Damit wird der Patch klein, und wenn man ihn zwei mal anwendet wird er wieder rückgängig gemacht.

sobald sich eine dateigroesse aendert ist das ganze system auf die nase gefallen. aenlichkeiten zwischen zwei GB grossen archiven zu finden ist nicht sonderlich trivial, gibt firmen die nichts anderes als solche "backup" systeme entwickeln (und die meisten sind wohl von Sun,IBM,HP,DELL,etc. aufgekauft worden).

gibt auch ein paar kostenfreie patcher, aber ich weiss nicht wie effizient die solche deltas finden, problematisch bei sowas ist aber oft dass sie wirklich nur zwischen zwei versionen funktionieren, wenn du ein spiel hast wo sich die leute den content selbst aussuchen, hast du viel mehr permutationen als du vermutlich patches erstellen koenntest.

rapso

dot schrieb:

Es hängt auch davon ab, was genau du mit den Dateien machen wirst. Wenn du einfach beim Start einmal jede öffnest und in einem Stück von vorn bis hinten durchliest und das wars, dann wird Memoy Mapped I/O z.B. auch kaum einen Unterschied machen...

im worst case also nicht schlecht? klingt doch gut

tjo, hat es irgendwelche vorteile wenn du archive updatest? ansonsten klingt ein neues archive doch ausreichend. wobei ich mir nicht sicher bin was du mit index datei mitliefern meinst, es hat doch eh immer jedes archive eine index datei, sonst kann man mit den daten darin wohl nichts anfangen, wuerde ich annehmen.

Also im Moment ist es so, dass ich die Game.index einlese und bspws. beim Zugriff auf die Datei /Foo/Bar/Baz.bla zurückbekomme, dass diese Datei in Archiv Nummer 2, also der Datei Game.002 , ab Byte x mit Länge y zu finden ist. Dieser Index erstreckt sich also über ALLE Archive.

Soviel wie ich mitbekommen habe, scheint aber Memory-Mapping für mich insofern praktisch, dass ich den Index eh nur einmal einlese und dementsprechend direkt den gesuchten Teil on-thy-fly rausextrahieren und verarbeiten kann. Hierbei müsste ich noch herausfinden, wie ich am Geschickstesten mit Memory-Streams (?) arbeiten kann um nicht ständig die extrahierten Dateien auf Platte zu schreiben, was inperfomant wäre.

rapso

Christian Ivicevic schrieb:

tjo, hat es irgendwelche vorteile wenn du archive updatest? ansonsten klingt ein neues archive doch ausreichend. wobei ich mir nicht sicher bin was du mit index datei mitliefern meinst, es hat doch eh immer jedes archive eine index datei, sonst kann man mit den daten darin wohl nichts anfangen, wuerde ich annehmen.

Also im Moment ist es so, dass ich die Game.index einlese und bspws. beim Zugriff auf die Datei /Foo/Bar/Baz.bla zurückbekomme, dass diese Datei in Archiv Nummer 2, also der Datei Game.002 , ab Byte x mit Länge y zu finden ist. Dieser Index erstreckt sich also über ALLE Archive.

ob du jetzt eine game.index hast, oder dir die informationen aus allen archiven rausholst die du oeffnest, duerfte egal sein. zweiteres ist aber flexibler.

Soviel wie ich mitbekommen habe, scheint aber Memory-Mapping für mich insofern praktisch, dass ich den Index eh nur einmal einlese und dementsprechend direkt den gesuchten Teil on-thy-fly rausextrahieren und verarbeiten kann. Hierbei müsste ich noch herausfinden, wie ich am Geschickstesten mit Memory-Streams (?) arbeiten kann um nicht ständig die extrahierten Dateien auf Platte zu schreiben, was inperfomant wäre.

memory streams? auf platte extrahieren? wieso nutzt du nicht einfach pointer? dafuer sind memory mapped files da, ist doch nicht java hier

Ich habe bisher noch nie mit MMF gearbeitet und werde sicher viel Spaß haben, meine Methoden um meine Daten zu (de)serialisieren (ich habe hier Boost::Serialization als "Light"-Variante nachgebaut für mich) an MMF anzupassen, aber dies wird definitiv viel effizienter werden, soviel wie ich bisher gelesen habe. Danke auf jeden Fall schon mal für den Hinweis auf MMF - wahrscheinlich unter Windows eine tolle Angelegenheit

rapso

Christian Ivicevic schrieb:

Ich habe bisher noch nie mit MMF gearbeitet und werde sicher viel Spaß haben, meine Methoden um meine Daten zu (de)serialisieren (ich habe hier Boost::Serialization als "Light"-Variante nachgebaut für mich) an MMF anzupassen, aber dies wird definitiv viel effizienter werden, soviel wie ich bisher gelesen habe. Danke auf jeden Fall schon mal für den Hinweis auf MMF - wahrscheinlich unter Windows eine tolle Angelegenheit

so als tipp, so 'deserialisiere' ich eine textur

CTexture* pTexture = reinterpret_cast<CTexture*>(&Archive[TextureOffset]);

so ein mesh

CMesh* pMesh = reinterpret_cast<CMesh*>(&Archive[MeshOffset]);

so als meine 'light' variante

Es ging mir darum, dass ich das in einer eigenen Bibliothek habe und auch mit dem ganzen Kram mit überladenen Operatoren wie & definiere wie ein struct oder eine Klasse deserialisiert wird.

template<typename TArchive>
TArchive& Serialize(TArchive& ar, GCFFILE::Ptr& pFile) {
	ar & pFile->strFilename;
	if(pFile->strFilename != String::empty) {
		ar & pFile->dwCrc32;
		ar & pFile->qwReserved1;
		ar & pFile->wArchiveIndex;
		ar & pFile->dwOffset;
		ar & pFile->qwReserved2;
		ar & pFile->dwSize;
		ar & pFile->qwReserved3;
		ar & pFile->wTerminator;
	}
	return ar;
}

Und aktuell habe ich für die erste Variante mit regulären fstreams Ausdrücke wie z.B.

this->pImpl->m_Stream.read(reinterpret_cast<GCFLib_RawPtr>(&object), sizeof(GCFLib_DWord));

und respektive write, je nachdem in welche Richtung das geht. Aber die MMF-Variante wie du sie da beschreibst sieht definitiv viel komfortabler aus!