PureBoard

Verfasst: **15.04.2005 18:58**

Versteh den nutzen nicht so ganz? Wenn ich meine Datei in Deiner VRAMDisk speichere und diese lade, kann ich sie davon schneller laden. Lade ich sie normal und lasse sie im hintergrund geladen, habe ich dasselbe, aber weniger Speicherverbrauch (z.Zeit die Hälfte).

Vielleicht kannste das nochmal etwas erläutern
Gruß
Thomas

Verfasst: **15.04.2005 19:37**

MVXA hat geschrieben:SourceCode wäre mir irgendwie lieber. Ich möchte meine Userlib eher weniger von anderen Userlibs abhängig machen. Außerdem wer sagt den, dass die VRamDisk nur für binär Dateien eingesetzt wird ? Man kann mit ihr genau so gut Textdateien bearbeiten.

V steht nu für Virtual, damit Rings nu auch zu frieden ist ~_~...

Der Source von BriefLZ ist frei erhältlich, also keine Hexerei.Ist in Ansi-c gemacht, also auch nach Linux übertragbar.
Davon ab, das Thema Kompressionsalgos ist nicht ganz ohne, ich selber finde das toal interresant aber auch schwer.
Der BriefLZ algo geht einen guten Kompromiss zwischen Geschw. und Kompressionsrate ein.

Verfasst: **15.04.2005 20:44**

> Lade ich sie normal und lasse sie im hintergrund geladen, habe ich dasselbe, aber weniger Speicherverbrauch (z.Zeit die Hälfte).
Ach son Shit -_-. Geht die Lib bischen daneben

. Ihr Sinn ist es eigentlich Lese und Scrheiboperationen zu optimieren damit nicht gewartet werden muss, bis die HDD alles zusammen hat.

Aber Ihr anwendugsgebiet ist hauptsächliche die Spieleplatform. Man könnte so z.b. die Engine immer um Dateien erweitern. Ein anderes Beispiel: man könnte so auch neue Maps in die Engine einbinden. Das wäre dann auch felxibler, da alles in einer Datei ist und die Engine kann sich dann die TileSets aus dem Archiv selbst zusammen suchen.

Den BriefLZ Code habe ich schon gefunden. Ich freu mich -_-. Kann ja so gut C. Naja. Mal sehenw as sich da machen lässt. Vielleicht schaffe ich das ja.

Verfasst: **16.04.2005 09:59**

MVXA hat geschrieben:> Lade ich sie normal und lasse sie im hintergrund geladen, habe ich dasselbe, aber weniger Speicherverbrauch (z.Zeit die Hälfte).
Ach son Shit -_-. Geht die Lib bischen daneben . Ihr Sinn ist es eigentlich Lese und Scrheiboperationen zu optimieren damit nicht gewartet werden muss, bis die HDD alles zusammen hat.

Aber Ihr anwendugsgebiet ist hauptsächliche die Spieleplatform. Man könnte so z.b. die Engine immer um Dateien erweitern. Ein anderes Beispiel: man könnte so auch neue Maps in die Engine einbinden. Das wäre dann auch felxibler, da alles in einer Datei ist und die Engine kann sich dann die TileSets aus dem Archiv selbst zusammen suchen.

Den BriefLZ Code habe ich schon gefunden. Ich freu mich -_-. Kann ja so gut C. Naja. Mal sehenw as sich da machen lässt. Vielleicht schaffe ich das ja.

BriefLZ gibts ja als fertige PB-Lib von mir, wenn du willst natürlich mit dem entsprechenden Source(dann brauchste nimmer selber 'C' zu machen ) den ich ein wenig modifiziert hab für PB (CallBacks für Fortschrittsanzeige, eliminieren des Work-Buffers).

Verfasst: **16.04.2005 10:40**

mh, das wäre prima

. Ich lerne C noch und bin eher ein Anfänger

.

Verfasst: **19.04.2005 21:29**

So wie ich das jetzt sehe funktioniert die Userlib ja besstens. Freut mich. Wenn ihr keine Fehler berichtet kann ich das nicht testen. Mir wäre auch lieber, wenn ihr mal Feedback in die Richtung wie "funktioniert alles" geben würdet, weil ich dann die sicherheit habe, dass die Userlib einwandfrei funktioniert. Ich mache das hier nicht nur für mich. Ich mache das auch für euch. Wenn ich wollt, hät ich das ganze auch unter verschluss lassen können.

Sowas wie Wünsche wäre auch nicht verkehrt. Ich habe natürlich die Absicht die Userlib nur besser werden zu lassen. Nach meinen Idee hat sie aber schon alles. Jetzt seid ihr gefragt, was ihr noch in der Userlib haben wollt. Ich kann auch keine Gedanken lesen

. Noch so sehr ich es wollte.

Und Rings, ich warte immer noch auf den Sourcecode der BriefLZ komprimierung. Wenn du den Code nicht preis gibst, muss ich selber mal versuchen mit prof. C++ nach PB zu portieren und das kann dann etwas dauern, was die Entwicklungszeit für die Userlib anhöhen würde.

Nur so meine Senf ~_~...

Verfasst: **21.04.2005 16:36**

Habe nun selbst einen kleinen Bug gefixt und etwas an der Lib gearbeitet. Leider hat mir bis jetzt noch niemand was über bugs berichtet also nehme ich mal so an, dass die Lib schon fertig ist. Hier ein kleiner Auszug der History.txt:

Code: Alles auswählen

- Version: 0.2
	- Datei: modFile.pbi
		- RMD_AddArchiv()
			Einen kleinen Pointerbug behoben.			

	- Datei: modRamFile.pbi
		- RMD_FileCompresion()

			Mit dieser Funktion kann nun auch die Kompression 
			ermittelt und bestimmt werden. 

	- Datei: midMisc.pbi
		- RMD_FreeRAM()
			Diese Funktion gibt an wieviel RAM noch insgesamt 
			frei ist. Rückgabewert in Kilobyte.

Und hier der Downloadlink:
-> Download (Größe: 20,3 Kbyte)

bei [c]RMD_FileCompresion()[/c], wenn -1 als Parameter angegeben wird, dann gibt die Funktion die Kompression methode zurück. Im Augenblick gibt es nur 0 für Raw und 1 für die PB pack routine.

Verfasst: **21.04.2005 17:06**

MVXA hat geschrieben:bei [c]RMD_FileCompresion()[/c], wenn -1 als Parameter angegeben wird, dann gibt die Funktion die Kompression methode zurück. Im Augenblick gibt es nur 0 für Raw und 1 für die PB pack routine.

Bau doch noch den LZBrief-Packer ein von www.PureArea.net. (Hab ich den hier nicht schonmal erwähnt?

)

Verfasst: **21.04.2005 17:14**

MVXA hat geschrieben:Und Rings, ich warte immer noch auf den Sourcecode der BriefLZ komprimierung.

Verfasst: **21.04.2005 17:54**

mvxa sollte den source längst haben.
Und nochmals,
das ist C-Source, kein C++ .
Kann jeder der PellesC installiert hat auch selbst
bearbeiten,compilieren und zu einer PB-Lib machen.
Der Source gibts übrigens auch von Jörg Ibzen
auf dem seiner site.
Ich habe die offizielle Freigabe zur Nutzung in
PureBasic von Ibzen persönlich bekommen .
Also steht einer Nutzung nun nix mehr im Weg.
Meine version ist nur für PB angepasst.
Wird demnächst auch offiziell .
Einfach mal abwarten

und feierabend...