Eigentlich könnten wir jede Menge Daten Platz in den Imagebildern ausfüllen.
Statt 512x64 alles auf 128x64 zusammenschieben. Damit werden dann die angebotenen PAK-Daten viel kleiner und lassen sich schneller runterladen. Besonders die Modembenutzer werden viele Ladezeiten einsparen. Auch die Dateien auf meinem PC werden somit viel kleiner und ich könnte dann wieder mehr Bilder pixeln.
Ich werde am Sonntag schon mit meiner Sparmaßnahme beginnen und bei mir schon mal aufräumen.
Hier ein Musterbild, wie ich in Zukunft die Bilder platzsparend editiere.
Auf die Größe der pak-Dateien hat das keine Auswirkungen. Im Gegenteil, Makeogjekt wird dann mit einer Fehlermeldung (ungültige Dateigröße) abbrechen.
Die transparente Hintergrundfarbe wird von Makeobjekt eh ignoriert. Kannst Du ganz leicht ausprobieren
- pak-Datei mit Transparenzfarbe als Hintergrund
- pak-Datei mit farbigen Hintergrund
Da das png-Grafikformat ein komprimiertes Dateiformat ist, dürfte die Dateigröße gar nicht so viel kleiner werden, wenn nur die einfarbige Fläche reduziert wird.
Aber wenns hilft, ich hab da eine Grafik-Vorlage für 64er Fahrzeuge. Die Grafik ist 137x137 Pixel.
Zitat:Aber wenns hilft, ich hab da eine Grafik-Vorlage für 64er Fahrzeuge. Die Grafik ist 137x137 Pixel.
Klar, aber die Einsparung ist doch bei 128x64 größer im gegensatz zur 137x137 Version.
Ich hab die ganze Nacht an dem Thema gearbeitet und es ist mir sogar gelungenk, die ganze Sache auf 1x64 abzuspecken. Nun werden die Dateien noch Kompakter.
Ich bin zwar kein Grafiker, könnte mir aber vorstellen, wenn man die Grafiken mit einem Programm erzeugt, das verschiedene Ebenen beherrscht und dann alle Bilder übereinander legt, ist noch mehr Ersparnis drin. Optimal ist es dann, wenn man die unterschiedlichen Bilder durch Drehung passig darstellt!
Vlt. kannst Du das ja mal visuell umsetzen MHz?
Zitat:Optimal ist es dann, wenn man die unterschiedlichen Bilder durch Drehung passig darstellt!
Da stellt sich dann aber auch die Frage:
"Geht das sogar schon in Richtung 3D" ??
öhm... im Moment ist es doch eigendlich ziemlich einfach geregelt, dass man die Bilder im entsprechenden Quadrat (Fliese, Startposition Fahrzeug, glaube ich) malt und mit makeobj die Transparenzfarbe irgendwie markiert/ausgeschnitten etc wird und mit einer .dat verknüpft, sodass eine einzige Datei dabei rauskommt, die Simutrans lesen kann. Soweit so gut.
Warum versuchst du die Grafiken so eng wie irgend möglich aneinander zu quetschen? Dadurch wird doch eigendlich nur das einpa©ken erschwert. (ich gehe mal davon aus, dass makeobj aus jedem Bildausschnitt ein eigenes Bild macht, das dann in Simutrans abgebildet wird.) Wenn diese Vermutung stimmt, dann ist die einsparung genau 0, weil intern immer noch alle Bilder existieren.
Wenn dem nicht so ist, weiss ich nciht, ob der Mehraufwand durch Neuausrichten gerechtfertigt ist im Vergleich zur Einsparung...
martin
PS: 3D wäre nett, aber höchstens was für simu 3.0^^
Zitat:Wenn diese Vermutung stimmt, dann ist die einsparung genau 0, weil intern immer noch alle Bilder existieren.
Da bin ich nicht Deiner Menung, hab mit meiner Aktion heute Nacht, ca. 1GB auf meinem PC eingespart.
Also, mit verlustfrei gepacktem PNG (was nicht alle Programme können) ist die Einsparung durch zusammenschieben nahezu Null (genauer gesagt im mittel ca. 64 Byte/Bild).
Makeobj speichert den Hintergrund gar nicht. Das Format ist folgendes für eine Zeile:
16Bit Zahl: Anzahl transparenter Pixel
Schleife:
16Bit Zahl: Anzahl 5:5:5 Pixel (die dann natürlich dahinter folgen)
16Bit Zahl: Anzahl Tranparenter Pixel (0=Ende)
Gehe zum Schleifenstart
Daher sind die Anzahl der transparenten Pixel völlig irrelevant.
Makeobj nimmt jedes Bild einzeln, und wenn in einer pak-Datei zweimal dasselbe Bild auftaucht, dann taucht dieses auch zweimal in der Pak-Datei auf.
Dann hör ich jetzt mal auf mit dem Thema
irgendwie hing es wohl mit dem heutigen Datum zusammen.
Ups, danke. Das war zu nahe an der Realität. Die c't Entspiegelngsoftware habe ich ja noch erkannt, aber ...