PureBoard

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.

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.

Fred hat wohl was geplant, auf Plugin-Basic, also ähnlich Grafik und Sound.
Das wird wohl aber noch etwas dauern.

Wenn Geschwindigkeit für Dich am wichtigsten ist, ist BriefLZ am besten
geeignet.

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.

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...

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...

Sei mir nicht böse, aber ich finde das Thema hier lächerlich und überflüssig.
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.

Hm.. ich muss PB unter Linux unbedingt zum Laufen bekommen. Ich würde da gerne auch mal ein paar Tests machen.


Greetz Laurin

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

Ausserdem werden 40GB Festplatten in Preisgünstigen Notebooks immer noch verbaut. Es gibt auch Leute, die keinen Geldscheisser haben aber ein Notebook brauchen (mein Freundin z.B. abe da hat's trotz Radeon 9700 noch für eine 60GB HDD gereicht)

>> 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

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.