Leute! Hört auf, eure Texturen zu formatieren!

[Krishty]

Hi,

Ich mache führe gerade ein paar Benchmarks zu Texturkompression durch (die Ergebnisse gibt es später in einem anderen Thread), weil ich mich nach langem Hin und Her der Effizienz meines eigenen Texturformats vergewissern möchte – was eigentlich gar kein Format ist: Ich schreibe die Datenblöcke einfach nur so, wie sie sind, auf die Festplatte und webe die wenigen Informationen, die ich zum Laden brauche, in eine handvoll Buchstaben in der Dateiendung.

Mal drei Gründe, die gegen jedes Texturformat – sei es nun DDS, TGA, BMP, PNG oder sonstwas – sprechen:

• Sie sind zu komplex. Wie viele verschiedene Farbtiefen und Pixelformate benötigt eine durchschnittliche Engine? Fünf, zehn, zwanzig? Ich würde sagen, dass selbst große Projekte selten Bedarf an mehr als zehn haben. Fast alle Bildformate sorgen für einen total Input-Overkill, der dann darin resultiert, dass nur einzelne Variationen des Formats implementiert werden – wie viele Anwendungen unterstützen schon TGA in allen Farbtiefen mit und ohne Lauflängenkodierung, BMP mit Bitmasken oder die >200 Pixelformate, die DDS ermöglicht? Implementiert man sie nicht, hat man jede Menge Müll in seinen Dateien (siehe nächster Punkt) und macht Moddern das Leben zur Hölle; implementiert man sie, explodiert die Code-Basis in unwartbare Dimensionen.
• Ihr Inhalt ist überflüssig oder redundant. In 3D-Engines braucht man fast nie Luxus wie Farbraumverwaltung oder Kommentare der Autoren. Texturen haben immer entweder Gamma 2,2 oder 1 (, was sich zudem aus ihrem Pixelformat ableitet: Unsigned Normalized -> 2,2; Signed Normalized -> 1; Floating-Point -> 1). Da die Seitenlängen fast immer Zweierpotenzen sind, reichen allein die Dateigröße und ein Bruch in der Dateiendung, um die Seitenlänge zu errechnen. Pitch gibt es bei Power-of-Two-Seitenlängen eh nicht. Man könnte sogar so weit gehen und behaupten, dass man alle Formate, die man braucht, durchnummeriert und nur noch die Nummer in die Dateiendung schreibt (was aber selbst mir ein wenig zu radikal (= zu schwer lesbar) wäre) – unter diesem Gesichtspunkt erscheint es fast irrsinnig, hunderte Bytes mit solchen Informationen in den Anfang jeder Textur zu pflanzen.
• Container sind Störer. Was kostet ein 100-Byte-Header tatsächlich?
  • Bei Texturen sind die Seitenlängen fast immer Zweierpotenzen, dementsprechend geht auch die Größe der Pixeldaten fast immer glatt in Sektor- oder Seitengrößen auf. Mit einem 100-Byte-Header am Anfang verbraucht die Datei 4 KiB mehr Festplattenspeicher (bzw. eine zusätzliche Seite beim Einblenden in den Hauptspeicher), wovon 3,9 ungenutzt bleiben (je nach Anzahl der Texturen liegen da viele MiB brach). Ein zusätzlicher Sektor bedeutet wieder ein paar Prozent mehr Fragmentierungsrisiko.
  • Alignment-Verlust, falls der Header kein Vielfaches von 16 B groß ist – blendet man die Datei in den Hauptspeicher, kann man keine High-Performance-Operationen wie SSE mehr auf die Pixeldaten anwenden. Gilt aber für alle Pixelformate über 2 B, da die CPU zum Lesen nicht-ausgerichteter Daten rund doppelt so lang braucht. (Braucht vielleicht auch der Grafiktreiber länger, die Pixel in eine Textur zu kopieren, wenn die Quelle nicht ausgerichtet ist?)
  • Entropie – Header, Line-Markers usw. stehen für Maschinen in keinem erkennbaren Zusammenhang zu den Pixeldaten und brechen ihr Muster. 0,01 % Container-Information in einer Datei sorgen dafür, dass sich die Datei 1 % schlechter komprimieren lässt (lassen zumindest meine Benchmarks vermuten).

Natürlich gibt es auch Gründe, die gegen unformatierte Texturen sprechen – nämlich vor allem, dass sie kein Bildbearbeitungsprogramm unterstützt (allerdings hat ein Tool, das von einer DDS den Header abschneidet und den Dateinamen ändert, eine Laufzeit von unter einer Sekunde) und dass man an einigen, hochspezialisierten Stellen (besonderen Rendering-Algorithmen) eben doch ausgefallene Formate braucht (was aber eher dafür spricht, diese Stellen klar vom Rest abzugrenzen).

Naja, so viel zu meiner Meinung: Alles roh schreiben und ein automatisiertes Tool eine ID in den Dateinamen einweben lassen, die auf das Projekt abgestimmt ist.

Gruß, Ky

[Alexander Kornrumpf]

Wie so oft verstehe ich nicht worauf du hinaus willst (und habe leider 90% deiner Ausführungen über PNG vergessen).

Insbesondere der dritte Punkt erscheint mir widersprüchlich. Die Probleme "verschwendeter Sektor" und "schlechte Komprimierung" können quasi nicht gemeinsam auftreten oder täusche ich mich da? Und vielleicht bin ich naiv aber wieso sollte ich die Datei überhaupt als ganzes in den RAM packen? Würde es nicht reichen, den Header zu lesen, dann wenn ich weiß wieviel noch kommt, die eigentlichen Bilddaten aligned in den Speicher zu schreiben und den Header dann wegzuwerfen?

[Krishty]

Insbesondere der dritte Punkt erscheint mir widersprüchlich. Die Probleme "verschwendeter Sektor" und "schlechte Komprimierung" können quasi nicht gemeinsam auftreten oder täusche ich mich da?

Nein, das ist schon richtig – komprimierst du die Textur, ist die Kompression schlechter. Tust du es nicht, ist ein Sektor zum Großteil verschwendet. Bei unformatierten Texturen tritt keines der Probleme auf, weder mit Kompression noch ohne.

Und vielleicht bin ich naiv aber wieso sollte ich die Datei überhaupt als ganzes in den RAM packen? Würde es nicht reichen, den Header zu lesen, dann wenn ich weiß wieviel noch kommt, die eigentlichen Bilddaten aligned in den Speicher zu schreiben und den Header dann wegzuwerfen?

Ich spreche von Memory-Mapped Files – traditionelles Lesen von Dateien hat den Nachteil, dass du Pufferspeicher allokieren und dann sequenziell füllen musst. Bei Memory-Mapped I/O lässt du die Datei durch das Betriebssystem auf Seiten im Arbeitsspeicher abbilden, womit es für deine Anwendung so aussieht, als läge die Datei im RAM.
Damit lassen sich Texturen im Idealfall ohne Allokation (und ohne weitere Kernel-Mode-Aufrufe) (von Seite der Anwendung) direkt von der Festplatte in den VRAM schieben – und da das eine fundamentale Aufgabe des Betriebssystems ist (wird beim Laden jedes ProgrammModuls benutzt), ist es die am höchsten optimierte Möglichkeit, eine Datei zu lesen.

[Schrompf]

Hm. Im Groben und Ganzen stimme ich Dir zu: man kann leicht ein Übermaß an Funktionalität in Dateiformate reinstecken. Da war doch neulich dieser Thread hier aufm ZFX, wo es darum ging, PNGs so klein wie möglich zu kriegen... wer war denn das nur? :-D Ein anderer fängt an, einzelne Texturkanäle mit Kontext zu versehen und Texturen zur Laufzeit aus Informationskanälen zusammenzusetzen. Kann man auch machen, wenn man die zusätzlichen Shaderpermutationen für diese Bastelei generieren mag, aber ich halte das für unnötige Arbeit.

Andernseits beschlich mich aber bei einigen Deiner Beispiele der Gedanke "Schreib mal ein richtiges Spiel und dann lass Dich überraschen". Wir haben ziemlich bald Unterstützung für NonPOW2-Texturen gebraucht - und sei es nur wegen eines Vertippers des Grafikers, der plötzlich eine 1424x1024-Textur abgeliefert hat. Wir benutzen DDS genau wegen seiner Vielfalt an Formaten und der Tatsache, dass man die praktisch ohne Bearbeitung so auch in den VideoRAM hochladen kann. RGB24, ARGB32, R16, GR32F, ARGB128F, DXT1, DXT5, A8 - alles schon gehabt. Noch dazu als CubeMap oder VolumeMap, was DXT ja auch unterstützt. Kann ich nur empfehlen, das Ding. Und für alles, wo wir schnell mit der Außenwelt kommunizieren wollen, haben wir einen PNG-Loader/Writer für die gängisten Formate geschrieben. Da allerdings nur sehr selektiv, weil da definitiv gilt, was Du schreibst: da steckt neben dem eigentlichen Bild noch ein Haufen unnützer Datenmist in jeder Datei. Trotz allem empfehle ich, unbedingt mindestens ein gängiges Dateiformat neben den eigenen Spezialformaten zu unterstützen. Die Grafiker im Team wissen es sehr zu schätzen, wenn sie schnelle Workcycles haben, ohne zwischendurch ein esoterisches Kommandozeilentool für jede Iteration benutzen zu müssen.

Und spätestens bei 1% besserer Kompression oder einem Block zusätzlichem Festplattenplatz... mal ehrlich: wenn kümmert das denn? Texturen sind 100kb bis 16MB groß - da muss man schon ganz schön argumentieren, um zu erklären, dass der 4kb-Vorteil die Arbeit wert wäre. Und die Arbeit mit "unverschlüsselten" Dateinamen ist für normale Menschen auch angenehmer.

[Alexander Kornrumpf]

Damit lassen sich Texturen im Idealfall ohne Allokation direkt von der Festplatte in den VRAM schieben

Wohl nicht wenn die Datei komprimiert ist (es sei denn Graphiktreiber unterstützen mittlerweile codecs die auf dem device ausgeführt werden?!).

Also meine Meinung ist, da ich nur eine recht kleine Festplatte besitze, möchte ich dass Spiele ihre Bilddateien gefälligst komprimiert vorhalten (ist das nicht mehr Standard?). Deswegen halte ich alle Argumente, die sich auf den nicht komprimierten Fall beziehen erstmal für wenig hilfreich.

Also wenn du einen Vergleich machen willst dann sollten es nachträglich komprimierte raw files gegen beispielsweise den von dir ja bis aufs äußerste erforschten Prozess der PNG Kompression sein. Alles andere halte ich für langweilig. Ich meine, dass raw files eben raw files sind mit allen Implikationen, für die Erkenntnis brauchst du nicht anzufangen zu experimentieren.

[Krishty]

Andernseits beschlich mich aber bei einigen Deiner Beispiele der Gedanke "Schreib mal ein richtiges Spiel und dann lass Dich überraschen".

Fehlende Praxis ist mir nicht abzuerkennen – genau darum lasse ich das hier diskutieren, statt einfach drauf los zu machen :)

Wir benutzen DDS genau wegen seiner Vielfalt an Formaten und der Tatsache, dass man die praktisch ohne Bearbeitung so auch in den VideoRAM hochladen kann.

Ja, das geht natürlich genau so mit Rohtexturen – die kommen ja auch 1:1 in den VRAM. Aber ehrlich – benutzt ihr tatsächlich mehr als zehn, 20 verschiedene Pixelformate und BitTiefen?

Noch dazu als CubeMap oder VolumeMap

Guter Punkt … da hebt sich DDS von allem anderen ab … Aber auch das lässt sich bei Rohtexturen ja mit ein paar Zeichen im Dateinamen erreichen. Ich denke, dass die Mächtigkeit gleich ist (mit genügend Indikatoren im Dateinamen).

Die Grafiker im Team wissen es sehr zu schätzen, wenn sie schnelle Workcycles haben, ohne zwischendurch ein esoterisches Kommandozeilentool für jede Iteration benutzen zu müssen.

Ja, das habe ich mir schon gedacht. Ich bin eigentlich auch für eine möglichst breite Import-Pipeline, aber je weiter ich komme, desto mehr wünsche ich mir, die Standards überall enger gezogen zu haben :/

Und spätestens bei 1% besserer Kompression oder einem Block zusätzlichem Festplattenplatz... mal ehrlich: wenn kümmert das denn?

Darum waren meine Pedantenfaktoren als letzter Punkt aufgeführt ;)

Und die Arbeit mit "unverschlüsselten" Dateinamen ist für normale Menschen auch angenehmer.

Wenn Wall 123 bump.FxhZ9g.raw nun sooo viel schlimmer ist als Wall 123 bump.dds, ist man imo überempfindlich.

Wohl nicht wenn die Datei komprimiert ist (es sei denn Graphiktreiber unterstützen mittlerweile codecs die auf dem device ausgeführt werden?!).

Ja – Block-Compression mit Entpacken in der Textureinheit ist immernoch die leistungsfähigste Kompression … wenn auch leider nicht verlustfrei, darum fliegt sie bei mir vorerst raus.

Also meine Meinung ist, da ich nur eine recht kleine Festplatte besitze, möchte ich dass Spiele ihre Bilddateien gefälligst komprimiert vorhalten (ist das nicht mehr Standard?). Deswegen halte ich alle Argumente, die sich auf den nicht komprimierten Fall beziehen erstmal für wenig hilfreich.

Meine Benchmarks stehen noch aus, aber es scheint im Moment, als seien komprimierte Texturen wesentlich ineffizienter als rohe … meine Festplatte ist auch zu 80 % komprimiert, aber es kann gut sein, dass sich meine Meinung darüber in den nächsten Stunden rapide ändert.

Also wenn du einen Vergleich machen willst dann sollten es nachträglich komprimierte raw files gegen beispielsweise den von dir ja bis aufs äußerste erforschten Prozess der PNG Kompression sein. Alles andere halte ich für langweilig.

Genau das ist im Gange – unkomprimiert vs. transparent komprimiert vs. komprimiert :) (und natürlich noch vs. roh, damit ich auch was davon habe ;) ) Dauert aber noch, weil die Datenmengen hier nicht gerade klein sind, eine eigene (defragmentierte) Partition zur Verfügung stehen muss usw.

[Alexander Kornrumpf]

Ja – Block-Compression mit Entpacken in der Textureinheit ist immernoch die leistungsfähigste Kompression, wenn auch leider nicht verlustfrei … darum fliegt sie bei mir vorerst raus.

Wieder was gelernt.

[Schrompf]

Nuja, mir scheint, wir sind uns da schon recht einig :-)

Wir benutzen DDS genau wegen seiner Vielfalt an Formaten und der Tatsache, dass man die praktisch ohne Bearbeitung so auch in den VideoRAM hochladen kann.

Ja, das geht natürlich genau so mit Rohtexturen – die kommen ja auch 1:1 in den VRAM. Aber ehrlich – benutzt ihr tatsächlich mehr als zehn, 20 verschiedene Pixelformate und BitTiefen?

Nein, eher nicht. Mehr als die genannten werden kaum vorkommen. In vergangenen Zeiten war es noch cool, dass man einfach den Inhalt jedes beliebigen Rendertargets auf Platte schreiben konnte - mit DDS geht das. Inzwischen gibt es aber PIX, daher ist auch das Argument inzwischen mehr oder weniger hinfällig.

[Zudomon]

Ein anderer fängt an, einzelne Texturkanäle mit Kontext zu versehen und Texturen zur Laufzeit aus Informationskanälen zusammenzusetzen.

Hört sich gut an! Wer war das?

[eXile]

Damit lassen sich Texturen im Idealfall ohne Allokation (und ohne weitere Kernel-Mode-Aufrufe) (von Seite der Anwendung) direkt von der Festplatte in den VRAM schieben – und da das eine fundamentale Aufgabe des Betriebssystems ist (wird beim Laden jedes ProgrammModuls benutzt), ist es die am höchsten optimierte Möglichkeit, eine Datei zu lesen.

Bist du dir da sicher? Normalerweise hat doch der Graphiktreiber auf dem VRAM den Deckel drauf. Ich weiß allerdings auch nicht, wie das mit dem neuen WDDM aussieht, darum lehne ich mich hier mal nicht so weit aus dem Fenster. Nur Google hat vorhin nichts dazu ausgespuckt.

Und die Arbeit mit "unverschlüsselten" Dateinamen ist für normale Menschen auch angenehmer.

Wenn Wall 123 bump.FxhZ9g.raw nun sooo viel schlimmer ist als Wall 123 bump.dds, ist man imo überempfindlich.

Man könnte auch eine Datei anlegen, welche für jede Textur die Header-Informationen (oder in diesem Fall nur die ID) abspeichert. Allerdings würde man sich dadurch natürlich eine Wartungsabhängigkeit mehr einhandeln, und ich persönlich mag diese Lösung dann auch nicht wirklich.

Nachtrag: Aber ich stimme natürlich Krishty in dem Punkt zu, dass man „in unseren Breiten“ nicht 42 Fantastillionen Graphikformate braucht. Allerdings ist so etwas wie DDS schon sehr nett, im Sinne von „one thing fits all“.

[Krishty]

Damit lassen sich Texturen im Idealfall ohne Allokation (und ohne weitere Kernel-Mode-Aufrufe) (von Seite der Anwendung) direkt von der Festplatte in den VRAM schieben – und da das eine fundamentale Aufgabe des Betriebssystems ist (wird beim Laden jedes ProgrammModuls benutzt), ist es die am höchsten optimierte Möglichkeit, eine Datei zu lesen.

Bist du dir da sicher? Normalerweise hat doch der Graphiktreiber auf dem VRAM den Deckel drauf. Ich weiß allerdings auch nicht, wie das mit dem neuen WDDM aussieht, darum lehne ich mich hier mal nicht so weit aus dem Fenster. Nur Google hat vorhin nichts dazu ausgespuckt.

Das „direkt von der FestplatteÚ war wohl ein bischl übertrieben … ich meinte eher, dass der Treiber direkt von einer Seite liest, die einer physischen Datei zugeordnet ist, statt aus einer Kopie im RAM.
Was der Treiber dann noch alles machen muss, darauf hat man keinen Einfluss -- aber die Datei liegt vom ersten Zugriff an eh im RAM, weil der DAtie-Manager ab Vista alles cached, was nicht bei drei aufm Baum ist (gemutmaßt) … wenn du dann normal lesen würdest, müsstest du erst einen Puffer allokieren (Kernel-Mode-Call), mit einem (oder mehr) Kernel-Mode-Calls à la ReadFile() eine Kopie der Datei im Speicher anlegen (die zweite) und dem Grafiktreiber dann die übermitteln. Ich spreche einfach weiter, wenn ich unsicher werde, merkst du das? :D

Man könnte auch eine Datei anlegen, welche für jede Textur die Header-Informationen (oder in diesem Fall nur die ID) abspeichert. Allerdings würde man sich dadurch natürlich eine Wartungsabhängigkeit mehr einhandeln, und ich persönlich mag diese Lösung dann auch nicht wirklich.

Wenn man die Header-Informationen in den Dateinamen packt gibt es diese Datei schon ohne Mehraufwand und sie heißt Master-File-Table.

[eXile]

Man könnte auch eine Datei anlegen, welche für jede Textur die Header-Informationen (oder in diesem Fall nur die ID) abspeichert. Allerdings würde man sich dadurch natürlich eine Wartungsabhängigkeit mehr einhandeln, und ich persönlich mag diese Lösung dann auch nicht wirklich.

Wenn man die Header-Informationen in den Dateinamen packt gibt es diese Datei schon ohne Mehraufwand und sie heißt Master-File-Table.

Naja … man kann natürlich den Dateinamen für so etwas „missbrauchen“ – der Dateiname ist nun einmal primär der Name der Datei und kein „Datenfeld“, in dem man beliebige Informationen abspeichert. Aber da fällt mir gerade ein: Unter NTFS gibt es mehrere Dateistreams. In dem ersten Dateistream ist normalerweise der Dateiinhalt (d.h. das, was man sieht, wenn man es mit Notepad öffnet) gespeichert, in den anderen Streams Zusatzinformationen (z.B. dieses „Die Datei wurde aus dem Internet heruntergeladen. Wollen Sie sie immer noch öffnen?“). In diesem Falle belegt die Datei übrigens auch noch mehr Speicherplatz, aber IMHO können die Dateistreams auch an unterschiedlichen Stellen im Dateisystem abgespeichert sein … alles vorausgesetzt, NTFS-spezifische Eigenschaften kommen überhaupt für dich in Frage.

[Aramis]

AFS wuerde ich nicht verwenden. Eben weil es eine NTFS-spezifische Sache ist und von den meisten Installern, Tools (z.B. gaengige Versionskontrollsysteme, Backuptools), usw. nicht unterstuetzt wird. Das gibt nur Probleme …

Der Ansatz mit den Dateierweiterungen ist imho voellig in Ordnung, den die Dateien muessen ja nur noch maschinell gelesen werden -- der Entwickler arbeitet ja mit ganz normalen Texturen in seinem Lieblingsformat die dann von einem Resourcecompiler in das finale Format fuers Deployment umgesetzt werden.

[Krishty]

Naja … man kann natürlich den Dateinamen für so etwas „missbrauchen“ – der Dateiname ist nun einmal primär der Name der Datei und kein „Datenfeld“, in dem man beliebige Informationen abspeichert.

Dann rechtfertige Dateierweiterungen ;) Die sagen, was in der Datei drin ist. Genau das tue ich auch, nur, dass die Dateierweiterung bei mir zwei- oder dreimal pso lang ist.

[eXile]

Dann rechtfertige Dateierweiterungen ;)

Ja, unter Linux-Distributionen hat man ja nicht unbedingt (für alles) Dateierweiterungen. Da muss man halt wissen, wie man die Datei zu lesen hat.

PS: Herzlichen Glückwunsch zum 1000. Post – und sogar gar noch nicht einmal im Jammer-Thread! :lol:

[Krishty]

PS: Herzlichen Glückwunsch zum 1000. Post – und sogar gar noch nicht einmal im Jammer-Thread! :lol:

Wow, das hatte ich ganz vergessen … sonst wären in dem Post viel mehr Auslassungspunkte gelandet, wahrscheinlich auch eine Prise pessimistischer PopulärkulturReferenzen … naja, zumindest habe ich den richtigen Pegel … und die #1024 steht ja auch noch aus. Eigentlich ist deinem Satz nichts hinzuzufügen; danke.

[Krishty]

[Troll]
Microsoft warnt vor Thumbnail-Lücke in Windows
„Ausgelöst wird der Exploit dann durch eine vorgeblich negative Anzahl von Farbeinträgen in der Farbtabelle (biClrUsed).“

Naa, kontrolliert ihr auch brav jedes einzelne Feld des Grafikformats eurer Wahl auf gültigen Wertebereich? Prüft ihr auch brav dreifach, indem ihr das Offset der Farbpalette mit biClrUsed nicht nur gegen die Bittiefe, sondern auch gegen das Offset der Bilddaten in BITMAPFILEHEADER::bfOffBits gegenrechnet? Dafür sind redundante Felder ja schließlich da!

Klar doch.
Ich bin mir sicher, dass ihr das tut.
[/Troll]

[eXile]

Dafür sind redundante Felder ja schließlich da!

Ich glaube, du stellst dir das zu einfach vor. Das Vorhandensein von redundanten Feldern ist immer ein extrem starkes Indiz darauf, dass sich ein Format (bzw. die zugrundeliegende Datenstruktur) über die Zeit evolutionär entwickelt hat. Oder bei irgendwelchen Spezialfällen sind sie doch notwendig.

Mich selber überrascht der Artikel eigentlich weniger, seitdem ich die Evolution des ICO-Formats mir mal reingezogen habe (Teil 1, Teil 2, Teil 3, Teil 4). Da kommen direkt am Anfang so Schoten wie:

The bWidth and bHeight are the dimensions of the image. Originally, the supported range was 1 through 255, but starting in Windows 95 (and Windows NT 4), the value 0 is accepted as representing a width or height of 256.

Natürlich ist das total unsauber, aber wenn man nun einmal in der Situation ist und dann gerade der eine Wert frei ist … Meiner Meinung nach stellt übrigens das Anschalten des Mauszeigers (und das Setzen eines entsprechenden Icons) noch immer den Goldstandard für einen Lag-freien Cursor – auch in Graphikanwendungen! – dar.

[Krishty]

Ich glaube, du stellst dir das zu einfach vor. Das Vorhandensein von redundanten Feldern ist immer ein extrem starkes Indiz darauf, dass sich ein Format (bzw. die zugrundeliegende Datenstruktur) über die Zeit evolutionär entwickelt hat.

Jaja, klar; darum auch die Troll-Tags ;) Imo ist es aber längst nicht so, als hätte Microsoft keine Schuld daran – in MSPaint haben sie geschlagene zehn Jahre gebraucht, um die Speichervoreinstellung nicht auf BMP, sondern auf das in so ziemlich jeder Hinsicht überlege PNG zu setzen … und seit sie das tun, gehen JPG und BMP bei Amateurarbeiten und Screenshots im Web gefühlt stark zurück. Wenn sie mal früher damit angefangen hätten, würde es uns heute genau so wenig kümmern wie eine Sicherheitslücke in PCX-Thumbnails (falls noch einer weiß, das das ist). Wenn es ihnen BMP jetzt um die Ohren fliegt, ist das geradezu ironisch selbstverschuldet.

(PNG ist vor allem überlegen, weil seine Chunk-Struktur im Gegensatz zu BMP einen einigermaßen konsistenten Weg bietet, Wucherungen zu kontrollieren und die Logik der Anwendungen nicht zu verkomplizieren. Wer heute noch BMP benutzt, hat entweder exotische Beweggründe oder ist schlicht dumm.)

Meiner Meinung nach stellt übrigens das Anschalten des Mauszeigers (und das Setzen eines entsprechenden Icons) noch immer den Goldstandard für einen Lag-freien Cursor – auch in Graphikanwendungen! – dar.

Ja, die ICO-Geschichte kenne ich. Arbeitet CUR mittlerweile eigentlich auch schon mit PNG/MNG (wie ICO)?

P.S.:

Da kommen direkt am Anfang so Schoten wie:

The bWidth and bHeight are the dimensions of the image. Originally, the supported range was 1 through 255, but starting in Windows 95 (and Windows NT 4), the value 0 is accepted as representing a width or height of 256.

Genau deshalb speichere ich bei Ressourcen immer Ausmaß minus 1. Spart nicht nur so einen Murks, sondern auch Zombie States.

[BeRsErKeR]

(PNG ist vor allem überlegen, weil seine Chunk-Struktur im Gegensatz zu BMP einen einigermaßen konsistenten Weg bietet, Wucherungen zu kontrollieren und die Logik der Anwendungen nicht zu verkomplizieren. Wer heute noch BMP benutzt, hat entweder exotische Beweggründe oder ist schlicht dumm.)

Ich nutze ausschließlich BMPs als Zwischenformat, aus dem ich meine eigenen Formate (haben sich im Laufe der Zeit gewandelt, aber natürlich nur eins pro Projekt :D ) generiere. Mein Beweggrund ist, dass ein Konverter in 2 Minuten und ohne Lib-Abhängigkeiten geschrieben ist. Beim Zwischenformat kann man ja eh auf Kompression usw verzichten. Was natürlich dabei flöten geht, sind so Sachen wie Halbtransparenz, aber bislang kam ich mit einer geeigneten Colorkey-Farbe für Volltransparenz aus. Ich nutze dabei als Zwischenformat immer unkomprimierte 24-Bit Bitmaps (falls ich wirklich mal nen Alpha-Kanal brauche, missbrauche ich den Zero-Kanal von 32-Bit Bitmaps dafür). Letztlich kommt es ja nur auf das Zielformat an, was man dann auch nutzt. BMPs als Zielformat kann ich natürlich auch nicht empfehlen, aber der einfache Aufbau und die Bandbreite an Bildbearbeitungstools, die BMPs unterstützen, haben mich bislang immer überzeugt, BMPs bei der eigentlichen Erstellung der Grafiken zu verwenden (bzw. als Endformat, auf dem der Konverter aufsetzt). Während der Bildbearbeitung nutzt man ja oft sowieso geeignete Formate wie Photoshops PSD.


Allgemein zum Thema: Ich bin auch kein Freund von etlichen Formaten und redundanten Informationen. Ich schreibe meine Formate meist selbst und dabei bestehen sie so ziemlich aus den Rohdaten und eventuell noch Angaben zur Größe. Ab und an auch mal 1-2 Bits zum Thema Format/Alpha, aber dabei beschränke ich mich in der Regel auf 1-3 Formate. Allerdings kann man meine Erfahrung mit "großen" Spieleprojekten nicht als Maßstab nehmen. Ich halte es gern klein und designe die Formate so, dass sie möglichst wenig redundante Daten enthalten, einfach geladen werden können und meinen spartanischen Ansprüchen genügen.

[Krishty]

Ich nutze dabei als Zwischenformat immer unkomprimierte 24-Bit Bitmaps (falls ich wirklich mal nen Alpha-Kanal brauche, missbrauche ich den Zero-Kanal von 32-Bit Bitmaps dafür).

Das geht genau SO lange gut, bis dir solche Schoten passieren wie mir mit Gimp, das Monochrom-Bitmaps auf jeder Achse um acht Pixel verschiebt. Oder bis du mal ein anderes Programm brauchst, und das keine deiner zweihundert Bitmaps lesen will, weil die DPI-Angabe falsch ist (passierte mir damals unter XP mit Paint). Oder mal ein Programm ein paar Bytes Platz zwischen Info-Header und Pixeln lässt, weil sich die Datei mit SSE besser schreiben lies. Und und und … naja, sowas passiert mit fast jedem Format – aber BMP hat da besonders viel Potential.

PNG ist durch libpngs Allgemeinheit ein wenig umständlicher zu laden, dafür funktionieren dann aber alle Farbtiefen und relevanten Features bis in alle Ewigkeit.

[BeRsErKeR]

Wie gesagt nutze ich fast nur 24 Bit Bitmaps. Nichts Monochromes etc. Das einzig nervige sind dabei die eventuell nötigen ZeroBytes (was man bei den 32 Bit Bitmaps nicht hat). Ich lese da eigentlich nur Breite, Höhe und Pixeldaten aus. Der Rest im Header interessiert mich herzlich wenig. Und eine kleine Fehlererkennung im Konverter tut ja auch nicht weh (Dateigröße == Headergröße + Breite * Höhe * 3; Byte0-1 = "BM"). Bislang hatte ich keine Probleme, dass da Tools die Bitmaps anders gespeichert haben. Die Spec ist bei 24 Bit Bitmaps auch recht eindeutig, aber natürlich hast du recht, dass da immer ein Risiko besteht. Wenn der Konverter aber ein paar einfache Checks drin hat (ist ja bei einem speziellen BMP Format nicht so aufwendig), sollte man ganz gut leben können. Das Spiel/Programm arbeitet dann ja später nur mit dem eigenen Format und der Konverter wird halt so gebaut, dass er keinen Murks generiert. Das spart dann Zeit und Aufwand, an der Stelle wo es wichtig ist: beim Laden der Grafiken im eigentlichen Programm. Die BMPs bekommt ja abgesehen vom Entwickler eh niemand zu Gesicht.


Nochmal zum Thema Kodieren von Zusatzinformationen im Dateinamen: Ich hatte mal eine ähnliche Idee bei der Kodierung/Komprimierung von Dateien. Die Idee dahinter war, dass der Dateiname sowieso da ist und die Möglichkeit bietet zusätzliche Informationen zu speichern, wodurch man den Inhalt der Datei verkleinern bzw. Kodierungsinformationen ohne zusätzlichen Speicherplatz ablegen kann. Allerdings ist das natürlich nicht ganz der Sinn von Dateinamen. Ich persönlich habe aber nichts gegen deinen Ansatz. Er zeugt mMn von Einfallsreichtum, gerade auch in Hinblick auf die Idee, dass man dann komplett auf Headerdaten verzichten kann und die Rohdaten als "einzelnes Stück" vorliegen hat.

[Krishty]

Wenn die BMPs ihren Stammordner nicht verlassen und das Produkt mit dem „spartanischen“ Format arbeitet, ist ja dann alles im Lot :) Was ich anprangere ist, wenn sowas beim Kunden landet. Das ist ganz mies. (Gilt übrigens auch, wenn man auf Modder setzt – die haben es auch schon schwer genug, wenn die mitgelieferte Tool-Chain nicht auf hingehackten BMP-Loadern aufbaut ;) )

[BeRsErKeR]

Wenn die BMPs ihren Stammordner nicht verlassen und das Produkt mit dem „spartanischen“ Format arbeitet, ist ja dann alles im Lot :) Was ich anprangere ist, wenn sowas beim Kunden landet. Das ist ganz mies. (Gilt übrigens auch, wenn man auf Modder setzt – die haben es auch schon schwer genug, wenn die mitgelieferte Tool-Chain nicht auf hingehackten BMP-Loadern aufbaut ;) )

Ja da stimme ich dir vollkommen zu. Für solche Zwecke würde ich BMPs auch nicht verwenden. Schon allein wenn man sich mal die BMP-Doku anguckt und das ganze Wirrwarr zu all den Formaten durchliest. Ich nutze BMPs wirklich nur während der Entwicklungsphase als Zwischenformat, um einen simplen Übergang zwischen Bildbearbeitungsprogramm und Zielformat zu erreichen. Weil ein Export-Plugin für alle möglichen Tools zu schreiben würde ich nicht so lustig finden.

[eXile]

PNG ist durch libpngs Allgemeinheit ein wenig umständlicher zu laden, dafür funktionieren dann aber alle Farbtiefen und relevanten Features bis in alle Ewigkeit.

Wobei das weniger an libpng liegt, als an der festgezurrten PNG-Definition. libpng bzw. die zlib braucht man dafür nicht (unbedingt), wobei das natürlich das Laden noch einmal verkompliziert. ;)

[BeRsErKeR]

PNG ist durch libpngs Allgemeinheit ein wenig umständlicher zu laden, dafür funktionieren dann aber alle Farbtiefen und relevanten Features bis in alle Ewigkeit.

Wobei das weniger an libpng liegt, als an der festgezurrten PNG-Definition. libpng bzw. die zlib braucht man dafür nicht (unbedingt), wobei das natürlich das Laden noch einmal verkompliziert. ;)

Eben aus solchen Gründen verwende ich keine PNGs als Zwischenformat. ;)

[Krishty]

Weil sie so wohldefiniert sind? :P

Wir schweifen ab … im Hinblick auf die Absicht des Threads hat PNG ähnlich viel Ballast wie andere etablierte Formate auch; der Vorteil ist eben, dass alles in Chunks untergebracht ist und dadurch jeder Loader jede ihm unbekannte Erweiterung ohne weiteres überspringen kann. Bei BMP ist das ein wenig anders … siehe die unzähligen Kompressionsmethoden, die nur von den Windows-Interna tatsächlich implementiert werden. Es ist und bleibt aber eine Wahl des kleineren Übels.

[BeRsErKeR]

Ich wollte mit meinen Ausführungen nur sagen, dass das BMP-Format für mich eine Daseinsberechtigung hat, wenn auch nicht als Zielformat. Wenn man sich dabei auf ein ganz spezifisches Format (24 Bit / 32 Bit ohne Kompression usw) festlegt, ist das ganze eigentlich auch recht nah an Rohdaten. Der BMP-Header hat eine feste Größe und man pflückt sich einfach die 3-4 Informationen aus dem Header und verwirft den Rest beim Einlesen/Konvertieren. Eh ich mich da durch die PNG-Chunks gehangelt habe, lese ich lieber den BMP-Header und die Pixeldaten ein und bin fertig.

Um aber nochmal was zum eigentlichen Thema zu sagen: Ich kann dir (Krishty) nur zustimmen. Ich bin auch ein Freund von möglichst einfachen und performanten Formaten ohne viel Blabla drumrum und ohne EierlegendeWollMilchSau-Features, von denen meist nur ein Bruchteil benutzt werden.

Flexibilität finde ich nicht ganz so wichtig, außer vielleicht bei Bildbearbeitungstools selbst. Ein normales Projekt kommt meist mit einem oder einer Hand voll Formaten aus.

Gängige Formate sind meist auch nicht direkt für den Einsatz in Computerspielen konzipiert wurden, sondern sollen meist ein möglichst großes Einsatzsprektrum abdecken. Und in anderen Bereichen machen Meta-Informationen wie Kommentare vielleicht auch Sinn.