Bilddateiformate und andere technische Daten

  • Ich wusste nicht in welchen Teil des Forums ich das Thema stecken sollte, doch hier ist es wohl gut aufgehoben.


    Ich weiß nicht, inwieweit darüber etwas bekannt ist, doch kann mir jemand Auskunft darüber geben, welche Bilddateiformate z.B. in N64-Spielen verwendet wird? Also sprich welches Dateiformat für Hintergründe, den Himmel, die Texturen auf den 3D-Sprites? Auch für das NES oder für die Wii würde mich das interessieren. Beim NES wird wohl alles mit dem gleichen Formt gemacht wurden sein. Da sieht ja immerhin alles gleich aus.


    Außerdem würde mich noch interessieren, wie man in Spielen, explizite von den drei Konsolen, oder halt allgemein, Speicherplatz sparen kann. Also beim Programmieren. Ich habe schon das halbe i-Net durchforstet, doch ich habe nur sehr wenig gefunden.


    Ich hoffe ihr könnt mir helfen.

  • Also welche Formate jetzt Explizit verwende werden weis ich jetzt nicht, kann sogar sein das Nintendo da ein eigenes Format hat, das die textuen speichert da man für texturen oftmals gern noch etwas mehr speichert als nur den Farbinhalt. Normalmaps, Specular, Alpha, Emission usw...
    Aber auf jeden Fall wird denke ich schon mit sehr guter Komprimierung gearbeitet, da auf Konsolen meist wenig Speicher zur verfügung steht. Oft wird Targa.tga verwendet weil man dort schon so sachen wie Alphawerte mit ablegen kann und es lässt sich auch gleichzitig komprimieren, sowohl verlustfrei als auch verlustbehaftet. Obwohl ich selber lieber .png verwende weil das auch verlustfrei ist und alphawerte unterstützt, diese aber leider nicht so schön in einem seperaten Alpha Kanal abspeichert. Png kann auch verlustfrei und verlustbehaftet sein.


    Was speicherspaaren angeht. Ich bin ja selber auch programmierer und habe auch schon an Spielen gearbeitet. Von dem her was wichtig ist:


    1. Gute Komprimierung der Bilddateien, wie schon erwähnt.


    2. Wo es geht wiederverwendung der Dateien, Beispiel: Grüne und Blaue Rüstung von Link. Die textur ist sehr ähnlich hat nur an manchen stellen ne andere Farbe. Dann braucht man icht zwei Komplette Texturen machen sondern macht eine Gemeinsame und kleine extratexturen für die Unterschiede.


    3. Farbbereich einschränken. In Spielen brauchtm an seltenst mal ne höhere Farbtiefe als 8 Bit pro Farbkanal, den unterschied sieht eh keiner. 16 bit oder gar 32 bit float pro farbkanal Sprengen alle dimensionen in Spielen. Wenn kein Alphakanal gebraucht wird sollteder auch nicht gespeichert sein. (Ist eigendlich bei allen guten Bildbearbeitungsprogrammen einstellbar, MS Paint zählt dazu natürlich nicht :P )


    4. Sinnvolle Texturgrößen, 1024x1024 für eine Spielerfigur ist ok. Nicht aber für eine Poplige Bombe. Obwohl 1024x1024 schon gut ist und in Konsolen der älteren generation garantiert nicht vor kommt. Zumal das ja für 3D modelle ist und im 2D bereich siehtts eh wieder ganz anders aus.


    5. Gute Texturenfilter verwenden, man kann auch aus einer niedrig auflösenden Textur noch viel rausholen wenn man gute Filter darüberlegt um pixel zu interpolieren und Kanten zu glätten(Antialiasing), macht ja auch jedes Spiel heutzutage.


    Nochmal was zu 1.: Man kann auch bei der Erstellung der Textur darauf achten das sie später gut komprimiert werden kann. Man sollte zum Beispiel die Bereiche die später nicht benötigt werden in einer Farbe, am besten Schwarz, einfärben und Farbverläufe vermeiden denn eine gleichfarbige Fläche lässt sich besser verlustfrei komprimieren.


    Im Allgeminen, nicht auf Grafik bezogen, ist es vor allem bei Konsolenspielen wichtig die Datentypen richtig zu wählen in denen man seine Variablen speichert.


    Wenn man beispielsweise nur 200 Rubine maximal sammeln kann, dann ist es sinnlos das in einer integer variable zu speichern welche werte bis ca. 4Milliarden aufnehmen kann. Da nehm ich lieber "unsigned char" das ist eine Vorzeichenloser datentyp der von 0-255 geht und der braucht nur ein viertel des Speichers von "int".
    Das kann man eigendlich auf alles anwenden.


    Außerdem sollte man Redundanz vermeiden. Wenn also ein Wert aus einem anderen Abgeleitet werden kann, dann speichert man nicht Beide, sondern nur den einen. Beispiel: Einen Geldwert kan man im Spiel in € und $ Sehen, jetzt speichert man aber nicht beide, sondern nur einen denn der andere lässt sich ja daraus berechnen.


    Eigendlich ist das Thema Speichermanagement bei Spielen und auch anderen Programmen ein derart riesiges Thema das man es garnicht ausfühlich genug behandel kann, aber ich mach mal schluss jetzt weil ich beim durchlesen doch festgestellt hab das es schon sehr fachtheoretisch wird.

  • Oja, das ist genau das, was ich gesucht habe. Vor allem die Aspekte der Speichernutzung sind für mich extrem brauchbar.


    Der Hyrule Marktplatz in OoT z.B. hat ja als Grundlade eine Art einfaches Bild, und nicht vollständig animierte 3D-Modelle, oder? In der 3D-Version sind diese dann aber animiert, jedoch auch nur zum Teil. Also das was man sehen kann, ist animiert, der Rest nicht. Das ist auch ein wichtiger Aspekt zur Schonung des Speicherplatzes, oder?


    Und auch die Figuren in OoT... Man findet ja eigentlich nur eine Hand voll Figuren vor, und die ziehen dann nach der Machtübernahme von Ganondorf nach Kakariko: Man verbraucht nicht so viel Speicherplatz, und verpackt diese Sache auch noch glaubhaft, dass es fast gar nicht auffällt, dass man die gleichen Figuren noch einmal verwendet hat. Genauso verhält es sich ja auch mit den Gegnern, und dem Großteil der Gerudos, Goronen und Zoras. Alle sind eigentlich andere Charaktere, doch sie sehen alle gleich aus. Das ist doch auch ein Trick um Speicher zu sparen, nicht?


    Auf jeden Fall schon mal danke für deine Ausführungen =)

  • Zitat

    Original von ZeldaVeteran
    Der Hyrule Marktplatz in OoT z.B. hat ja als Grundlade eine Art einfaches Bild, und nicht vollständig animierte 3D-Modelle, oder? In der 3D-Version sind diese dann aber animiert, jedoch auch nur zum Teil. Also das was man sehen kann, ist animiert, der Rest nicht. Das ist auch ein wichtiger Aspekt zur Schonung des Speicherplatzes, oder?


    Ja das denek ich auch, der Marktplatz ist ja nur aus einem sehr begrenzten winkel zu sehen, ich denek das dies bewusst gemacht wurde um Speicher zu spaaren da ein komplett ausmodellierter Marktplatz unheimlich an Speicher gebraucht hätte. Stattdessen hat man das alles mit ein paar einfachen 2D texturen erschlagen.



    Und wie du schon gesagt hast, vor allem bei den gegnern kann man viel an Speicher spaaren indemman wie zum beispiel diese Springenden Spinnen nur Farblich ändert und schon einen anderen Gegner hat. Dazu braucht man dann nichtmal nen eue Textur sondern kann die andere einfach zu Laufzeit im Farbton verändern.



    Wenn man sich mal die Systemspezifikationen der Wii anschaut ist es eh beeindruckend was Nintendo aus derart spartanischer Hardware rausholt.

    Zitat

    Arbeitsspeicher


    88 MB Hauptspeicher (24 MB „internes“ (schnelles) 1T-SRAM, 64 MB „externes“ GDDR3 SDRAM)
    3 MB GPU-Textur-Speicher
    512 MB Flashspeicher (erweiterbar über eine SD- oder (seit Firmware-Update 4.0 auch) SDHC-Card mit einer Größe von bis zu 32 GB)


    Da könnten sich eineige Computerspiele Entwickler mal ne Scheibe abschneiden damit man nicht alle 2 Jahre ne neue Graka braucht mit 1-2GB Grafikspeicher. Denn ich behaupte mal das da nicht viel Optimiert wird. Da ja eh jeder die Hardware hat, wenn icht muss man sie hal kaufen, ich wage sogar zu behaupten das hier Spielehersteller mit Hardwareherstellern zusammenarbeiten denn wäre ja doof wenn man 10 Jahre mit der selben Graka auskommt dann kauft ja keiner mehr eine.

  • Ok, danke.


    Öhm... könnte man denn die Rubine auch mitzählen? Eigentlich ist es ja klar, dass unterschiedlich farbige Rubine auch unterschiedlich viel wert sind, doch man spart ja auch ein wenig Speicherplatz.


    Und die fallengelassene Items in OoT sind ja auch nur einfache Bilder, also keine 3D-Objekte, also auch wieder eine Speicherplatz-Einsparung? Selbst die Bäume in den 3D-Teilen sind ja auch aus 2D-Bildern.


    Also wenn man richtig sucht, dann wird man wohl auch viel finden^^

  • Noch ein wichtiger nachtrag zur allgemeinen Verständnis im zusammenhang mit Speicherverwaltung.


    Und zwar muss ich dazu ein ganz klein wenig ausholen und auf Computer architekturen eingehen, denn hier gibts im großen und ganzen zwei wichtige Architekturen die zu unterscheiden sind:


    1. Von-Neumann Architektur
    Computer so wie wir sie Zuhause stehen haben sind danach aufgebaut.


    Im groben bedeutet das, dass sowohl der "Programm Code" als auch die Daten die in dem Programm abgelegt sind auf ein und dem selben Physiklalischen Speicher liegen und zwar im RAM. Sie sind nur durch das Betriebssystem in ihrem Adressbereich voneinander getrennt.


    Wenn man jetzt also um Datenspeicher zu spaaren Spezielle Datentypen verwendet oder auf Redundanz verzichtet, und dafür aber mehr Programmspeicher benötigt um das auszuwerten, dann kann es sein das man am ende doch keinen Speicher gespaart hat, sondern nur Weniger datenspeicher braucht, dafür aber mehr Programmspeicher, was aber beides im RAM liegt.


    2. Harvard Architektur
    Ältere Spielekonsolen und viele Steuerungen wie Motorsteuerungen im KFZ sind so aufgebaut. Schon der Game Cube dürfte aber nicht mehr nach Harvard aufgebaut sein.


    Hier sind Programm und Datenspeicher vonneinander getrennt. Man kann sich also explizit entscheiden wo man den Speicher hin verlagen will.
    Der RAM ist hier der Datenspeicher und der Flashspeicher meist EEPROMs sind hier die Programmspeicher. Und somit schonmal Physikalisch voneinander getrennt.
    Vorteil: Es kann gelichzeitig auf Daten und Programmspeicher zugegriffen werden, was die Ausführungsgeschwindigkeit erheblich erhöhen kann, bzw. die Effizienz. (Bei geringeren Takt gleicher Befehlsdurchsatz)


    Was das nun für das Programmieren bedeutet:
    Wenn man wenig RAM hat kann man bewusst versuchen die vom Spiel gespeicherte Datenmenge so gering wie möglich zu halten und stattdessen Daten durch komplizierteren Progamm Code zu reproduzieren, was dann zu lasten des Programmspeichers geht nicht zu lasten des RAMs.
    In diesem Fall würde man also Statt einen Betrag in € und $ abzuspeichern ihn nur in € Speichern und dann vom Programm immer wenn benötigt den $ Betrag berechnen lassen.


    Umgekehrt ist es das selbe hat man viel RAM und mus Datenspeicher Spaaren, dann muss man eben leiber mehr Daten abspeichern als das man die Daten durch umständliche Programmabläufe reproduzieren muss.
    Hier hingegen würde man den $ und € Betrag speichern. Somit braucht man weniger Programmcode zum auswerten.

  • Zitat

    Original von Hellton



    Da könnten sich eineige Computerspiele Entwickler mal ne Scheibe abschneiden damit man nicht alle 2 Jahre ne neue Graka braucht mit 1-2GB Grafikspeicher. Denn ich behaupte mal das da nicht viel Optimiert wird. Da ja eh jeder die Hardware hat, wenn icht muss man sie hal kaufen, ich wage sogar zu behaupten das hier Spielehersteller mit Hardwareherstellern zusammenarbeiten denn wäre ja doof wenn man 10 Jahre mit der selben Graka auskommt dann kauft ja keiner mehr eine.



    Das ist genau meine Rede, weshalb ich von Konsolen so begeistert bin. Jene die für Konsolen programmieren haben meiner Meinung nach mehr Respekt verdient als Leute die für immer bessere Computer programmieren und zwar so, dass man diese dann aufrüsten muss. Also Konsolenprogrammierer! Hut ab!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!