Also ich traue der PB-Hilfe und baue auf die hohe Geschwindigkeit beim Entpacken. Ich bin sehr zufrieden mit dem PB-Packer.
Wie siehts denn allgemein mit den Geschwindigkeiten von Zip/Rar/jCalG1 aus? Das wäre für mich eigentlich das entscheidende Kriterium und nicht ein paar kb mehr oder weniger...
Am besten wäre wohl, wenn man seine Packmethode frei wählen könnte, mit einer Art Subsystem oder so. Dann wäre wohl allen geholfen. Leider gab es diese Variante nicht in der Umfrage.
Ist die PB Komprimierung noch akzeptabel?
-
ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
Fred hat wohl was geplant, auf Plugin-Basic, also ähnlich Grafik und Sound.Lebostein hat geschrieben: Am besten wäre wohl, wenn man seine Packmethode frei wählen könnte, mit einer Art Subsystem oder so. Dann wäre wohl allen geholfen. Leider gab es diese Variante nicht in der Umfrage.
Das wird wohl aber noch etwas dauern.
Wenn Geschwindigkeit für Dich am wichtigsten ist, ist BriefLZ am besten
geeignet.
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Könnte man nicht, sollte man RAR in PB einfließen lassen, die gebühren auf die PB-Käufer abwälzen? Das ist nur eine vage Überlegung, PB soll natürlich nach wie vor möglichst billig bleiben!
Außerdem: Man könnte ja, sollte ZIP/7z in PB einfießen, Ts-Soft's Vorschlag so kombinieren:
Man Baut Zip/7z und BriefLZip (oder wie das heißt) in PB ein, der, der mehr Speed will, nimmt BriefLZip und der, der mehr Komprimierung will, der kann dann ja Zip/7z nehmen.
Außerdem: Man könnte ja, sollte ZIP/7z in PB einfießen, Ts-Soft's Vorschlag so kombinieren:
Man Baut Zip/7z und BriefLZip (oder wie das heißt) in PB ein, der, der mehr Speed will, nimmt BriefLZip und der, der mehr Komprimierung will, der kann dann ja Zip/7z nehmen.
Hast du meinen Post nicht gelesen, indem ich versucht habe, eine 23,6 MB große HLP-Datei zu komprimieren? Bereits da traten Differenzen von über 1 MB zwischen JGCal1 und ZIP bzw. RAR auf. Geschwindigkeit in allen Ehren, aber hier sollte man sich so langsam Gedanken mahen, finde ich... Und dann frage ich mich noch, was passiert wäre, wenn ich wie vorgeschlagen, eine 50 oder 100 MB datei gepackt hätte...Lebostein hat geschrieben:Wie siehts denn allgemein mit den Geschwindigkeiten von Zip/Rar/jCalG1 aus? Das wäre für mich eigentlich das entscheidende Kriterium und nicht ein paar kb mehr oder weniger...
PB 4.30
Code: Alles auswählen
Macro Happy
;-)
EndMacro
Happy End
Sei mir nicht böse, aber ich finde das Thema hier lächerlich und überflüssig.
Und das aus folgenden Gründen:
Greetz Laurin
Und das aus folgenden Gründen:
- Wir leben im Zeitalter großer Festplatten.
PB: 5,46 MB, RAR: 4,41 MB
Ich habe insgesamt 400 GB bei mir eingebaut. Du kannst dir sicher sein, der eine MB ist mir völlig egal. Gut, andere Computer haben nicht soviel Speicher, sagen wir mal 60 GB. Aber selbst da ist 1 MB eine verschwindend geringe Datenmenge.
Wer weniger als 60 GB hat, hängt dem Fortschritt, hm..., 5 Jahre oder so hinterher. Das ist als ob man Windows 2000 auf Windows-95-Hardware laufen lassen will. Was ich damit sagen will, dürfte klar sein. - Geschwindigkeit
Hier kann man fast dasselbe schreiben wie bei den Festplatten. Bei heutigen Computern fällt der Geschwindigkeitsunterschied kaum auf. In Zukunft wird der Unterschied immer kleiner werden, da die Hardware immer schneller wird. - Andererseits kann ich dich aber verstehen, wenn du einen möglichst effizienten Komprimierungsalgorithmus verwenden willst. Du willst halt keine Computerleistung verschwenden.
Greetz Laurin
Now these points of data make a beautiful line.
And we're out of beta. We're releasing on time.
And we're out of beta. We're releasing on time.
Beim runterladen ist es dir als DSL1000 benutzter aber nicht egal, ob du 1
GB runter laden musst, oder 0,9 GB ... und bei solcher größe brauchen
auch heutige PCs ihre zeit zum packen und entpacken ...
Also ist das ganze überhaupt nicht überflüssig ...
Zumal dann die Möglichkeit des Komprimierens inzwischen am aussterben
sein müsste
... wenns überflüssig wäre ....
MFG PMV
GB runter laden musst, oder 0,9 GB ... und bei solcher größe brauchen
auch heutige PCs ihre zeit zum packen und entpacken ...
Also ist das ganze überhaupt nicht überflüssig ...
Zumal dann die Möglichkeit des Komprimierens inzwischen am aussterben
sein müsste
... wenns überflüssig wäre ....MFG PMV
-
ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
>> Wir leben im Zeitalter großer Festplatten.
Trotzdem bremmst gerade diese den PC aus. Mit UPX-gepackte Datei von
Festplatte laden und im Speicher entpacken, ist wesentlich schneller als die
ungepackte Datei zu laden.
Desweiteren habe ich auch keine Lust beim Download, trotz schnellem DSL,
unnützer Weise ewig zu warten.
Je größer die Festplatte, um so größer auch die Sicherungsdatei, so länger
dauert die Defragmentierung usw.
Es Leben die kleinen Dateien
Trotzdem bremmst gerade diese den PC aus. Mit UPX-gepackte Datei von
Festplatte laden und im Speicher entpacken, ist wesentlich schneller als die
ungepackte Datei zu laden.
Desweiteren habe ich auch keine Lust beim Download, trotz schnellem DSL,
unnützer Weise ewig zu warten.
Je größer die Festplatte, um so größer auch die Sicherungsdatei, so länger
dauert die Defragmentierung usw.
Es Leben die kleinen Dateien
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Also wenn ich meine Anwendung/Spiel zum Herunterladen anbieten will, dann nutze ich sowieso einen externen Packer wie ZIP, der zum Schluss auf das ganze Datenpaket angewendet wird. Wozu sollte man hierfür PB verwenden wollen? Das wird wohl niemand machen.
Den in PB-eingebauten Packer sehe ich deshalb nur für das platzsparende Ablegen meiner Programmdaten auf der Festplatte, die dann zur Laufzeit möglichst schnell entpackt werden müssen. Das ist für mich der Knackpunkt "zur Laufzeit". Zum Beispiel bei meiner in Entwicklung befindlichen Grafik-Adventure-Engine liegen die ganzen Spieledaten (Grafiken, Sounds, Musiken, Skripte usw.) in einer einzigen großen Datei vor, in der alle Einzeldateien gepackt und aneinandergehängt wurden. Während des Spieles lade und entpacke ich dann nur die Dateien, die in dem jeweiligen Raum benötigt werden (an die entsprechende Stelle der Datei springen - die Offsets wurden in einem eigenen Header hinterlegt -, Datenblock einlesen, entpacken und zum Beispiel mit CatchSprite() ein Sprite generieren), und das muss bei einem Raumwechsel möglichst schnell gehen. Und das funktioniert auch tadellos.
Und dabei kommt es wirklich nicht auf das ein oder andere MB an. Hauptsache schnell und dem User nicht all zu viel Plattenplatz nehmen. Wenn ich sehe, dass in vielen Spielen die Bitmaps einfach so auf der Platte rumliegen, wird mir schlecht. Da könnte man locker noch 30-40% rausholen.
Ich denke das war auch Freds Gedanke bei dem Packer. Nicht um Daten möglichst klein zu kriegen, sondern einen schnellen Algo zu bieten, mit dem man auch zur Laufzeit des Programms seine Daten entpacken kann.
Den in PB-eingebauten Packer sehe ich deshalb nur für das platzsparende Ablegen meiner Programmdaten auf der Festplatte, die dann zur Laufzeit möglichst schnell entpackt werden müssen. Das ist für mich der Knackpunkt "zur Laufzeit". Zum Beispiel bei meiner in Entwicklung befindlichen Grafik-Adventure-Engine liegen die ganzen Spieledaten (Grafiken, Sounds, Musiken, Skripte usw.) in einer einzigen großen Datei vor, in der alle Einzeldateien gepackt und aneinandergehängt wurden. Während des Spieles lade und entpacke ich dann nur die Dateien, die in dem jeweiligen Raum benötigt werden (an die entsprechende Stelle der Datei springen - die Offsets wurden in einem eigenen Header hinterlegt -, Datenblock einlesen, entpacken und zum Beispiel mit CatchSprite() ein Sprite generieren), und das muss bei einem Raumwechsel möglichst schnell gehen. Und das funktioniert auch tadellos.
Und dabei kommt es wirklich nicht auf das ein oder andere MB an. Hauptsache schnell und dem User nicht all zu viel Plattenplatz nehmen. Wenn ich sehe, dass in vielen Spielen die Bitmaps einfach so auf der Platte rumliegen, wird mir schlecht. Da könnte man locker noch 30-40% rausholen.
Ich denke das war auch Freds Gedanke bei dem Packer. Nicht um Daten möglichst klein zu kriegen, sondern einen schnellen Algo zu bieten, mit dem man auch zur Laufzeit des Programms seine Daten entpacken kann.