snesfreaks.com

Und noch ein Thread mit Fragen von mir
Hier sollen, wie der Titel sagt, Fragen allgemeiner Natur rein und ich fange auch gleich mal an.
Ich habe mich die letzte Zeit mit Hintegründen beschäftigt und schaffe es jetzt auch in die verschiedensten Hintergründen die verschiedensten Sachen anzuzeigen aber eine Sache verstehe ich nicht ganz.

Hier also mein Thema: Paletten

Folgender Sachverhalt, wir haben den CGRAM, der Platz für 512Byte hat. Das entspricht genau 256 Farben. Ich hatte jetzt die Idee, von lytron inspiriert, eine Textbox zu programmieren.
Ich schalte das Snes also in den BGMODE 3. Laut Doku 2 Hintergrundebenen. Die erstere mt 256 Farben, die 2. mit 16.
In den ersten Hintergrund packe ich also meine Tiles(eine hübsche Graslandschaft) und in den 2. dann einfachen Text, dessen Tiles das PriorityBit gesetzt haben.
Hier kommt jetzt mein Problem, der erste Hintergrund füllt den CGRAM komplett und ich weiß jetzt nicht, wo ich die Palette des 2. Hintergrundes hinpacken soll? Muss ich die Palette für BG2 irgendwie mit in die Palette von BG1 inkludieren?
In allen Tutorials die ich so per google gefunden haben konnte ich da keine Informationen finden.
Ich hoffe ihr könnt mir helfen =)

Richtig. Das SNES hat eine globale Palette von 256 Einträgen. Ein 256-Farben-Layer benutzt logischerweise alle davon.
Ein Tile im 16-Farben-Layer nutzt eine von 8 16-Farben-Paletten, die sich in der globalen Palette von 0-127 erstrecken.
Ein Tile im 4-Farben-Layer nutzt eine von 8 4-Farben-Paletten, die sich in der globalen Palette von 0-31 erstrecken.
Ausnahme: Mode 0, wo BG1 0-31, BG2 32-63, BG3 64-95 und BG4 96-127 haben kann. (Aus dem Gedächtnis, also vorsichtshalber ohne Peng)

Die Nummer der jeweiligen Palette ergibt sich aus der Palettennummer in der Tilemap.

D.h. die Palette(n) für den 16-Farben-Layer muss/müssen in der 256er-Palette berücksichtigt werden.

Sprites haben immer 16 Farben und können wie auch die Tiles eine von 8 Paletten annehmen, allerdings fangen Sprites bei Paletteneintrag 128 an.

Ich kann dir keine fachgerechte Antwort geben, ich würde einfach probieren, wenn du die Tilemap für den BG mit der Textbox schreibst, mit den Palettenbits zu spielen (Bits 3 bis 5 (von 0 bis 7 gezählt) im High Byte).
Wenn ich mich recht entsinne, nimmt er für den BG mit 256 logischerweise alle Farben, die im CGRAM sind. Für den BG mit 16 Farben nimmt er die Farben 0-15 wenn du Palette 000 nutzt, 16-31 bei Palette 001, 32-47 bei Palette 010 usw.

Probier es aus und guck, ob ich damit richtig liege.

@Lytron
Du hast vollkommen Recht. Bestätigt durch Selbstversuche wie du sie beschrieben hast und ikari_01´s Post.

Leider habe ich das Verhalten befürchtet =/
Ich bekomme immer mehr Respekt vor den Programmieren bzw. viel mehr vor den Grafikern, die so ein empfundenes Farbenfeuerwerk mit nur 256 Farben hinbekommen

Ist mit den 256 Farben wirklich alles ausgereizt oder gibt es noch irgendwelche geheimen Super Tricks mit denen man da was drehen kann?

Farbauti hat geschrieben:@Lytron
Du hast vollkommen Recht. Bestätigt durch Selbstversuche wie du sie beschrieben hast und ikari_01´s Post.

*hüstel* Das freut mich...

Farbauti hat geschrieben:Leider habe ich das Verhalten befürchtet =/
Ich bekomme immer mehr Respekt vor den Programmieren bzw. viel mehr vor den Grafikern, die so ein empfundenes Farbenfeuerwerk mit nur 256 Farben hinbekommen

Japp, das ist eben PixelArt.
In der PixelArt-Szene ist es übrigens immer noch eine der Herausforderungen, möglichst wenig Farben zu verwenden, auch wenn heutzutage diese Begrenzungen nicht mehr bestehen.
Ganz tricky wird es, wenn du z. B. nur vier Farben (drei + transparenz) hast. Dann kannst du z. B. als Farben nehmen: ein helles Rot, ein mittelhelles Grün und ein dunkles Blau. Und der Trick ist, dass du das Blau z. B. nicht bloß bei allen Oberflächen verwendest, die von ihrer Oberfläche her eine blaue Farbe haben, sondern du das dunkle Blau auch für alles nimmst, was eine "dunkle Helligkeitsstufe" hat. Klingt nach einem ziemlichen Farbkladeradatsch, ist es aber nicht, wenn man es anständig anstellt:
Hier sieht man zum Beispiel einen lila Elefanten. Die Haut des Elefanten ist ganz offensichtlich lila. Wenn man aber genau heranzoomt, sieht man z. B., dass die Schattierung des Rüssels mit Türkisgrün gemacht ist, und das nicht zu knapp.
Kunst.

Farbauti hat geschrieben:Ist mit den 256 Farben wirklich alles ausgereizt oder gibt es noch irgendwelche geheimen Super Tricks mit denen man da was drehen kann?

Nein. Es gibt die Möglichkeit, durch Farbsubtraktion noch mehr herauszuholen. Wenn du Terranigma kennst - Farbsubtraktion ist der Effekt auf den Seifenblasenwolken im Heimatdorf, die in allen Regenbogenfarben scheinen.
Ich kann dir empfehlen, mal nach der Smile! Christmas Demo 1994 zu suchen, da sieht man das sehr schön, wie das funktioniert. Wie das aber technisch funktioniert... weiß ich nicht, weil es mich zur Zeit noch nicht interessiert hat.

Farbauti hat geschrieben: Ich bekomme immer mehr Respekt vor den Programmieren bzw. viel mehr vor den Grafikern, die so ein empfundenes Farbenfeuerwerk mit nur 256 Farben hinbekommen

Ist mit den 256 Farben wirklich alles ausgereizt oder gibt es noch irgendwelche geheimen Super Tricks mit denen man da was drehen kann?

Es gibt noch einen low-fidelity direct color mode, bei dem du in gewissen Grenzen direkt Farben selektieren kannst, ohne an die Palette gebunden zu sein.
Wurde selten verwendet, als konkretes Beispiel fällt mir nur das Armaturenbrett in Super Road Blaster ein (da ich das selbst gemacht habe und nicht Hintergrundpaletten des Videos für so etwas "verschwenden" wollte).

Außerdem kannst du mittels color math noch Transparenzeffekte erzeugen, sowie per HDMA Farbwerte zeilenweise verändern um so mehr Farben auf den Bildschirm zu bekommen.

Aber seien wir ehrlich:
256 Farben bieten eine Menge Möglichkeiten, und gute Grafiker erzielen mit deutlich weniger fantastische Ergebnisse.
Wenn's scheisse aussieht, brauchst du einen besseren Grafiker, nicht mehr Farben.

Schnell gegoogeltes Beispiel, 21 Farben:

d4s hat geschrieben:Schnell gegoogeltes Beispiel, 21 Farben:

(SCHLAUMEIER)
Wir sehen hier das Werk "Poison Tree" von Fool, einem der bekannteren User von Pixeljoint.com.
Geboren in Moskau, ist dieser 48-jährige Künstler mittlerweile wohnhaft in Cleveland, Ohio, und verdingt sich als Lauten- und Geigenbauer. In regelmäßigen Abständen reicht er bei besagter Website neue Kleinodien ein, die völlig zurecht schnell in die dortige Hall of Fame wandern.
(/SCHLAUMEIER)

Und ganz nebenbei machen die User da auch regelmäßige "Mockups", sie malen Bilder, die aussehen wie Screenshots aus Spielen. Treibt dann auch ganz kuriose Blüten, wenn es einen Screenshot der "Saw"-Filme in FFTA-Optik gibt...

lytron hat geschrieben: (SCHLAUMEIER)
Wir sehen hier das Werk "Poison Tree" von Fool, einem der bekannteren User von Pixeljoint.com.
Geboren in Moskau, ist dieser 48-jährige Künstler mittlerweile wohnhaft in Cleveland, Ohio, und verdingt sich als Lauten- und Geigenbauer. In regelmäßigen Abständen reicht er bei besagter Website neue Kleinodien ein, die völlig zurecht schnell in die dortige Hall of Fame wandern.
(/SCHLAUMEIER)

Danke, Captain Obvious.
Du gewinnst die Klugscheissermedaille in gold.

Also ich fand das jetzt durchaus informativ. ;D

Ich habe jetzt ein wenig über die Thematik nachgedacht und bin mir aber noch nicht sicher was der elegantere Weg ist.
Als Programmierer hat man ja nun die Möglichkeit dem Grafiker zu sagen, dass er mit den Farben klar kommen muss. Heißt der Grafiker hätte
für BG1(256Farben Palette) nur noch die 256Farben - 16Farben(BG2) - 16Farben(für eine SpritePalette) = 224 Farben. Gleichzeitig muss dafür gesorgt werden, dass die ersten 16 Farbslots für die BG2 Palette leer bleiben und die letzen 16 für die Spritepalette.

Die 2. Grafikerfreundlichere Möglichkeit wäre, die Palletten erst im Code zu mischen.
Das stelle ich mir in der Theorie nicht so schwer vor.
Wir haben 3 Palletten, BG1(256Farben), BG2(16Farben) und Sprite(16Farben).
Die beiden letzteren Paletten bleiben identisch und werden an Platz 0-15 bzw 249-255 positioniert.

Als nächstes schaue ich mir die einzelnen Farben der originalen 256farben-Palette an, die von den anderen beiden überschrieben wurden, und Suche mir in der bereits gemischten Pallete die Farbe, die dieser am meisten ähnelt. Wenn ich die gefunden habe, muss ich dann nur noch im Tileset die original Farbe suchen und mit der neu gefundenen überschreiben.
Das sorgt dafür, dass sich die Tilesets von BG1 automatisch an die die neue Palette anpassen.
Nachteil hiervon wäre allerdings, dass die Farben der Tilesets von BG1 abhängig von den anderen Paletten aussehen würden.

Ich hoffe das war verständlich formuliert...

Was denkt ihr darüber?(speziell die 2. Möglichkeit) brauchbar?unbrauchbar?totaler scheiß ?

Farbauti hat geschrieben:Ich habe jetzt ein wenig über die Thematik nachgedacht und bin mir aber noch nicht sicher was der elegantere Weg ist.
Als Programmierer hat man ja nun die Möglichkeit dem Grafiker zu sagen, dass er mit den Farben klar kommen muss. Heißt der Grafiker hätte
für BG1(256Farben Palette) nur noch die 256Farben - 16Farben(BG2) - 16Farben(für eine SpritePalette) = 224 Farben. Gleichzeitig muss dafür gesorgt werden, dass die ersten 16 Farbslots für die BG2 Palette leer bleiben und die letzen 16 für die Spritepalette.

Du kannst es ja auch so sehen:
Dein Grafiker hat immer noch 256 Farben zur Auswahl, es ist nur so, dass er 32 von dir bzw. sich selbst vorgegeben bekommt.
Um d4s' Argument noch einmal zu untermauern (auch wenn es nicht nötig ist), dass gute Grafiker mit erheblich weniger als 256 auskommen, habe ich nochmal bei Pixeljoint ein paar Beispiele rausgesucht, wo z. T. besonders quietschebunte Bilder mit (z. T. weit) weniger als hundert Farben gemacht wurden (Die Farbenanzahl steht jeweils dabei: 1, 2, 3, 4, 5, 6). Diese Bilder geben, finde ich, ein direktes Gefühl dafür, was für eine gigantische Möglichkeit allein hundert Farben geben... das ist alles so viel bunter als das SNES-LotR.

Farbauti hat geschrieben:Die 2. Grafikerfreundlichere Möglichkeit wäre, die Palletten erst im Code zu mischen.
Das stelle ich mir in der Theorie nicht so schwer vor.
Wir haben 3 Palletten, BG1(256Farben), BG2(16Farben) und Sprite(16Farben).
Die beiden letzteren Paletten bleiben identisch und werden an Platz 0-15 bzw 249-255 positioniert.

Als nächstes schaue ich mir die einzelnen Farben der originalen 256farben-Palette an, die von den anderen beiden überschrieben wurden, und Suche mir in der bereits gemischten Pallete die Farbe, die dieser am meisten ähnelt. Wenn ich die gefunden habe, muss ich dann nur noch im Tileset die original Farbe suchen und mit der neu gefundenen überschreiben.
Das sorgt dafür, dass sich die Tilesets von BG1 automatisch an die die neue Palette anpassen.
Nachteil hiervon wäre allerdings, dass die Farben der Tilesets von BG1 abhängig von den anderen Paletten aussehen würden.

Ich hoffe das war verständlich formuliert...

Was denkt ihr darüber?(speziell die 2. Möglichkeit) brauchbar?unbrauchbar?totaler scheiß ?

Ich kann nur sagen, wie ich es probieren würde.
Ich benutze PCX2SNES für die Umwandlung von PCX in die PIC/CLR-Dateien (du auch, oder nimmst du was anderes?).
Ich würde per Experiment gucken, in welcher Reihenfolge PCX2SNES die Farben in der CLR-Datei umwandelt. Ich gehe davon aus, dass es die Farben in der Reihenfolge anordnet, wie sie das erste Mal in der Grafikdatei auftreten. Und wenn das so ist, dann hast du eigentlich leichtes Spiel: Dann muss nämlich dein Grafiker im ersten (oder zweiten, es wäre besser, wenn das erste komplett leer/transparent ist) Tile deines 256-Farben-Tilesets jeden Pixel für die Palette nutzen. Und dann machst du in die erste Zeile (d. h. die ersten 16 Pixel) dieses Tiles die Farben deiner Textbox, und in die letzte Zeile die Farben des Sprites.*
Wenn du am Ende eine dieser Grafiken fertig hast und definitiv weißt, dass du (länger) nichts mehr an ihr ändern wirst, kannst du ja mit einem Hexeditor dieses "Palettentile" per Hand löschen; die Farben sind ja bereits in der CLR-Datei und dementsprechend wird sich an ihrer Reihenfolge nichts ändern.
Übrigens, wenn das so funktioniert, wie ich mir das denke, erspart dir das außerdem auch Arbeit, weil du dann am Ende alle Farben schon in einer CLR-Datei hast und nur noch einmal vorzugsweise per DMA den Kram in den CGRAM übertragen musst.
Es so zu machen wird dir viel nachträgliche Arbeit ersparen, denn, wenn ich deine Lösung richtig verstanden habe, würdest du dann die Tiles durchgehen und per Hand jede Zahlennummer ändern, weil du ebenso per Hand nach der Konvertierung die Reihenfolge der Farben änderst.

Kannst du mir folgen?
Macht das Sinn, was ich schreibe?

*
(SCHLAUMEIER)
Wobei es dann natürlich zu Komplikationen kommen kann, wenn dein Grafiker eine schiefe Zahl (d. h. eine, die nicht teilbar durch 16 ist) von Farben nutzt, weil dann deine Spritepalette z. B. zur Hälfte in Palette 101, zur anderen Hälfte in Palette 110 liegt.
(/SCHLAUMEIER)

Habe das angeführte Beispiel aus der Smile Christmas Demo 1994 mal als Video aufgenommen. Ich drehe dann und dann mal einen der BGs im ZSNES aus, damit das ganze noch etwas offensichtlicher wird, wie es funktioniert.