letzter Beitrag von Retrofan am
Heh, dieses Steckschwein-Projekt gefällt mir sehr gut. Allerdings habe ich keine Erfahrung mit separatem Video-RAM, abgesehen von etwas VDC-Gehacke.
Wie muss ich mir so etwas vorstellen? Wird da alles, was der Videochip irgendwann anzeigen soll, Byte für Byte ins VRAM geschrieben? Also am Anfang eines Levels muss ich erst mal x Kilobyte in einer Schleife kopieren?
Aufgrund dieser (zumindest Anfangs-)Probleme beim Design einer Videoausgabe würde ich auf ein Hardwarescrolling, welches über die Bitebene hinaus auf die Adreßebene geht, zunächst verzichten.
Ok, das finde ich natürlich verständlich. Die Prioritäten liegen erstmal woanders.
Die Arbeitsweise wäre beim Pixeln genauso, wie man es vom C64 kennt, nur eben mit 320 statt 160 Pixeln horizontal. Das würde den erfahrenen 8-Bit-Pixlern sehr entgegen kommen – und trotzdem wäre es auch neu.
Eine nicht zu verachtende Erleichterung käme durch den Umstieg auf (quasi) quadratische Pixel hinzu, nämlich dass man die Grafik viel leichter drehen kann, anstatt sie jedes Mal komplett neu pixeln zu müssen. Ob rollende Objekte, MOBs oder Grafikteile aus einer anderen Perspektive, wie bspw. die orthogonalen Pendants zu den Mauern in einem Labyrinth in der Draufsicht.
Wie viele aus der potentiellen Zielgruppe können ARM-Assembler oder sind bereit, einen komplett neuen Befehlssatz zu lernen?
ARM würde ich auch ausschließen. Kennt man schon genug von anderen Geräten. Was das Lernen eines neuen Befehlssatzes anbelangt, nun ja, wieviele Leute haben zuerst 6502 und später 68000 gelernt? Oder 6502 und Z80? Oder 6502 und x86? 6809? ARM? Das dürften weitaus mehr sein, als Du denkst. Bei Assembler ist es nämlich wie bei den prozeduralen Sprachen: Kennst Du eine, kennst Du alle. Hürden wären Übergänge zu anderen Sprachkonzepten wie OOP oder funktionale Programmierung. Das ist bei Assembler aber nicht gegeben. Schaut man sich folgende Befehle an:
fallen einem schon viele Ähnlichkeiten auf, die einem Programmierer dabei helfen, sich in kürzester Zeit in den neuen Befehlssatz einzuarbeiten. Ehrlich gesagt... Wer Schwierigkeiten hat, eine handvoll Befehle auswendig zu lernen, sollte vielleicht überlegen, ob Assemblerprogrammierung wirklich das richtige für ihn/sie ist.
Sicher, aber Programmlogik hat ja wenig mit Retro zu tu
*Hust* Also das erzähl bitte mal den Machern von "Sam's Journey" oder überhaupt irgendeinem Spieleprogrammierer von damals oder heute. Ich befürchte, Du verstehst unter Programmlogik etwas ganz anderes. Programmlogik bedeutet die Art und Weise, wie Sam springt, wieviele Gegner es gibt und wie sie sich bewegen, wieviele Bonuspunkte der Spieler bekommt, wo der Levelausgang ist und vieles, vieles mehr. Programmlogik umfaßt den allergrößten Teil des Codes. Daher nutzt es auch wenig, wenn der Computerbauer einem Spieleprogrammierer sagt: "Schau mal. Um dir die Arbeit zu erleichtern, haben wir hier Sprites für Dich. Ist das nicht toll. Da freust Du Dich, gell, denn jetzt ist das Spiel schon so gut wie fertig."
Ich halte Grafik- und Soundprogrammierung per Chip-Register für eines der wesentlichsten Elemente beim Retro-Coding: "Banging the metal".
[..]
Eine Bibliothek mit einer Schnittstelle? Nein danke.
Also ist die Programmierung auf dem AppleII für Dich nicht retro? 
Früher war es Pflicht, daß zum Apple auch eine Auflistung des Roms mitgeliefert wurde mit Angabe der Adressen und Parameter für die Routinen. "Banging the metal" heißt doch nicht, daß man jedes Mal das Rad neu erfinden muß. "Banging the metal" heißt auch nicht "Chipregister", sondern z. B. direkter Zugriff auf die Bitmap, komplette Übernahme des Rechners inklusive IRQ und die Möglichkeit, Peripherie ohne Treiber ansprechen zu können. "Chipregister" mag für Dich auf dem C64 ein besonderes Merkmal sein (warum auch immer), aber das gilt nicht für andere Rechner. Und noch einmal: Der allerallergröße Teil des Spielcodes und damit die eigentliche Arbeit am Programm besteht aus individuellen Routinen für Spielersteuerung usw., die man in einer allgemeingültigen Bibliothek gar nicht zusammenfassen kann.
Mir ging es darum, dass Spiele-Entwicklung auf einem Retro-System etwas völlig anderes ist als in einer Hochsprache auf Basis von SDL zu entwickeln.
Öh... nein. Ich mache beides, und für mich gibt es da nicht so viele Unterschiede, im Gegenteil: Es ist üblich, zuerst die Algorithmen in einer Hochsprache auszutesten und dann anschließend nach Assembler zu übertragen.
Keine Editoren, Bibliotheken und Compiler installieren/nachladen, keine Bibliotheks-Header einbinden, keine Compiler-Durchläufe...
Was das Nachladen anbelangt, so hängt das einzig davon ab, wie groß das Rom ist und was man alles da reinpacken will. Bibliotheks-Header einbinden? Was ist so schwer an einem "USES turtlegraphics;" Hatte damals[tm] damit nie Probleme. Und warum keine Compiler-Durchläufe? Ich habe damals mit Pascal angefangen, und glaube nicht, daß es mir geschadet hat. Okay, der UCSD-Compiler war langsam (wegen der 16 Bit-virtuellen Stackmaschine auf einem 8 Bit-Prozessor), aber wer sagt, daß das bei einem neuen Rechner so sein muß? Man kann wohl eher davon ausgehen, daß ein Compiler so schnell ist, daß man bei dem von Dir erwähnten Programm die Compile-Zeit kaum bemerken dürfte. Dafür ist aber die Ausführungszeit wesentlich schneller. Natürlich kann man auch einen Interpreter nehmen, aber... warum?
ein Compiler u.U. ähnlich effektiven Code erzeugt wie ein Mensch
Solch einen Compiler wird es nicht geben, es sei denn, jemand setzt sich hin und schreibt so etwas, was ich jedoch für sehr unwahrscheinlich halte.
hilft also beim "Umstieg" auf Assembler.
Ich bin nicht überzeugt, ob der Umstieg auf Assembler wirklich das Kriterium für eine Hochsprache sein sollte. Da stehe ich eher auf dem Standpunkt: entweder Assembler oder richtige Hochsprache. Dieser Mischmasch aus beiden Welten erfüllt m. E. keinen wirklichen Zweck. Abgesehen davon gibt es goto auch in anderen Hochsprachen außer Basic (, sofern man sich das antun will). Ansonsten sehe ich nicht, wie die Beschränkungen von Basic (keine Prozeduren, lokale Variablen, Parameterübergabe, Verbundstrukturen, mehrdimensionale Arrays...) nützlich sein sollen und nicht nur einfach nervig. Wer schnellen Code schreiben will, soll doch besser gleich zu Assembler greifen und nicht den Umweg über eine schlechte Halb-Hochsprache gehen.
ber auch hier war von "Der Rechner wäre nur zu dem [IIgs] OS kompatibel" die Rede...
Das war nur am Rande und bezog sich nicht auf das Endsystem, sondern lediglich auf die Möglichkeit, den Umstieg für bestimmte Nutzer einfacher zu machen und schon einmal Software mitliefern zu können.
Also am Anfang eines Levels muss ich erst mal x Kilobyte in einer Schleife kopieren?
Höchstwahrscheinlich. Alles, was irgendwie angezeigt werden soll, muß zunächst zum Videochip transportiert werden. Aus diesem Grunde eignen sich solche Video-Ram-Systeme nicht für schnelle Graphik, es sei denn man hat gleichzeitig sehr, sehr viel Videospeicher und einen eigenen Graphikprozessor, der Funktionen wie Scrollen und Kopieren übernehmen kann, also sowas wie einen PC. 
Ok, das finde ich natürlich verständlich. Die Prioritäten liegen erstmal woanders.
Hinzukommt, daß man m. M. n. auf das Hardwarescrolling noch leicht verzichten kann. Schon bei einem 6502 mit 2 Mhz könnte man ohne Probleme Textspeicher (Zeichen) und Farbspeicher scrollen und hätte noch genügend Zeit für andere Dinge. Problematisch wird es eigentlich erst, wenn man komplett auf Bitmap setzt, da dann wirklich große Mengen transportiert werden müssen.
Was das Lernen eines neuen Befehlssatzes anbelangt, nun ja, wieviele Leute haben zuerst 6502 und später 68000 gelernt?
Als Teenager oder mit Anfang 20? Für neue, aufregende Technologie? Klar. Diese Leute sind jetzt 50+ - und die Technologie um die es geht ist ein wenig aufregendes, für Taschengeld erhältliches Retro-Spielzeug.
Ehrlich gesagt... Wer Schwierigkeiten hat, eine handvoll Befehle auswendig zu lernen
Es geht nicht um "Schwierigkeiten", sondern um Einstiegshürden. Offenbar haben wir da unterschiedliche Vorstellungen davon, was jemand von einem 100 Euro-Spielzeug erwartet - lassen wir's dabei.
Problematisch wird es eigentlich erst, wenn man komplett auf Bitmap setzt, da dann wirklich große Mengen transportiert werden müssen.
Das wäre für mich der primäre Einsatzzweck eines möglichen Scrollingbeschleunigers, wodurch viele Arcadespiele grafisch profitieren können. Durch die Beschränkung auf drei bzw. vier beliebige Farben pro Kachel bliebe dabei auch der 8-Bit-Charme erhalten.
Wie schaut es eigentlich mit freier Adressierung des Color-RAMs aus? Ist das erwünscht/vorgesehen und gibt es da auch FPGA-spezifische Hürden zu überwinden?
Eine nicht zu verachtende Erleichterung käme durch den Umstieg auf (quasi) quadratische Pixel hinzu, nämlich dass man die Grafik viel leichter drehen kann, anstatt sie jedes Mal komplett neu pixeln zu müssen.
Und wenn man dann noch von "quasi" abrücken würde, das dadurch entsteht, dass das perfekte 16:10-Seitenverhältnis (320 x 200 Pixel) des C64-Screens auf PAL oder NTSC gequält/verzerrt wird, könnte man modernere Monitore/TV-Screens viel besser ausfüllen, als das bei sonstigen Retro-Systemen (die oft immer noch auf 4:3-Darstellung beharren) der Fall ist.
Es geht nicht um "Schwierigkeiten", sondern um Einstiegshürden.
Die Frage dabei ist doch, ob ein neuer Retro-Rechner eher angenommen wird, wenn er sich genau so verhält, wie ein damaliger (also eine der üblichen CPUs hat) oder ob Programmierer daran interessiert sind, was Anderes/Neues (zumal es ja Arbeitserleichterung darstellen soll) auszuprobieren, einfach weil es spannend ist, zu gucken, was damit geht.
Das ist ja das Kernproblem bei allen Komponenten eines solchen Rechners, egal ob es sich um die CPU, die Grafik, den Sound oder was auch immer dreht: Ist es zu sehr am bekannten dran, dann stellt sich die Frage nach dem Mehrwert, dem USP, der Existenzberechtigung gegenüber den Bestandsgeräten. Ist es davon zu weit entfernt, gibt es ein Akzeptanz-Problem (weil zu exotisch oder zu modern). Die Kunst ist es, die richtige Mischung zu finden – zugegeben: keine einfache Aufgabe.
Dass es grundsätzlich "Bedarf" für solche Retro-Geräte gibt, sieht man ja an der Resonanz. Sonst könnte man ja auch gleich sagen: Es gibt genügend alte Systeme, finde da was möglichst passendes für dich und leb' damit. Es scheint aber einen Wunsch nach neuen-alten Rechnern zu geben. Dieser Thread dient ja auch dazu, auszuloten, ob die Lücke, die die damaligen Systeme evtl. gelassen haben, ausreicht, um noch etwas "dazwischen" zu platzieren, das ausreichend spannend (für Entwickler und auch User) ist.
Ich denke es gibt da sehr unterschiedliche "Geschmaecker" und daher wird es vermutlich auch nicht das eine, neue, tolle System geben, das dann alle gute finden.
Es gibt diejenigen, die Kompatibilitaet zu was existierendem wollen. Es gibt diejenigen, die Limitierungen wollen. Es gibt diejenigen, die deutlich mehr Power wollen. Es gibt diejenigen, die moderne Schnittstellen wollen. Es gibt diejenigen, die alles wie damals wollen. Es gibt diejenigen, die FPGA wollen. Es gibt diejenigen, die Original-Bauteile wollen. Es gibt diejenigen, die drauf coden wollen. Es gibt diejenigen, die damit spielen wollen. Es gibt diejenigen, die etwas huebsches wollen. Es gibt diejenigen, die was zum Basteln wollen. Es gibt diejenigen, die es moeglichst einfach bedienen koennen wollen. Es gibt diejenigen, die was zum Rumhacken wollen.
Vieles davon laesst sich nicht in einem einzigen Rechner unterbringen, daher muss letztendlich derjenige, der so ein System entwirft, sich ueberlegen, was ER damit erreichen moechte und dieses Ziel dann auch verfolgen. Jeder wird es nicht toll finden, damit muesste man dann nunmal leben.
Ich denke es gibt da sehr unterschiedliche "Geschmaecker" und daher wird es vermutlich auch nicht das eine, neue, tolle System geben, das dann alle gute finden.
Vollkommen korrekt!
Vielleicht dient ja dieser Thread dazu, dass man zumindest einen gewissen Konsens findet und sowas in der Art eines "Forum64-Community-Retrocomputer" herauskristallisiert? Das wäre doch ein schönes Gemeinschaftsprojekt.
Immerhin gab es zu Weihnachten schon ein Forum64-Heftchen mit Listings zum Abtippen. 
Vieles davon laesst sich nicht in einem einzigen Rechner unterbringen, daher muss letztendlich derjenige, der so ein System entwirft, sich ueberlegen, was ER damit erreichen moechte und dieses Ziel dann auch verfolgen. Jeder wird es nicht toll finden, damit muesste man dann nunmal leben.
Das ist korrekt. Und ich erweitere meine Aussage bzgl. der "Lücke", in die ein weiterer Retro-Rechner stoßen muss. Nicht nur die alten Geräte definieren, welcher Platz noch frei ist, sondern natürlich auch die anderen Parallel-Projekte (sollten sie alle fertig werden).
Ich denke, bzgl. des angestrebten Preises konkurriert nur der Rechner vom 8-Bit-Guy mit unserem Vorschlag (so vage er auch noch ist). Was mir beim Commander 16 aber nicht gefällt, ist vor allem die BASIC-V2-Fixierung des Machers. Ein Nicht-Assembler-Programmierer wird damit auch nicht viel mehr anfangen können, als mit einem C64 – und ist fast zum reinen Konsumieren verdonnert.
Der Mega65 ist meines Erachtens eh eher ein Sammel-Computer, der wegen der Gehäuse-Ähnlichkeit zum C65 gekauft werden wird – und vielleicht noch wegen der C64-Kompatibilität. Über letzteres ist er eher Konkurrenz zu TC64 und 64U, beim Preis liegt er wahrscheinlich noch darüber. Den Käufern wird es egal sein, ob über ein paar BASIC-Programme hinaus dafür neue Software entsteht – da oftmals Vitrinen-Objekt.
Auch der C256Foenix wird seine Freunde finden. Und ein weiteres Projekt muss das berücksichtigen – man muss die Leute einsammeln, die sich bei den anderen Projekten nicht wiederfinden, aus welchem Grund auch immer. Das war ja auch der Antrieb, diesen Thread zu starten. Statt zu weinen, weil sich die anderen Projekte zu weit weg von dem bewegen, was man selber gerne hätte, fasst man lieber die eigenen Wünsche mal zusammen und gleicht sie mit den Wünschen derer ab, die die anderen 3 Rechner auch nicht kaufen würden/werden.
Was ich an M. J.s Vorschlag gut finde, ist es, den Fokus auf gute Programmierbarkeit und die nur vorsichtige Verbesserung der grafischen Fähigkeiten zu legen. Das deckt sich mit meinen Vorstellungen. Was die CPU angeht, dazu kann ich nicht wahnsinnig viel beitragen – allerdings habe ich Befürchtungen, dass man sie schlecht als "Retro" anpreisen kann, wenn sie zu leistungsfähig ist und sich zu weit von bestehenden 8-Bit-CPUs entfernt. Auch wenn Programmierer das Konzept vielleicht lieben werden. Vielleicht sollten das einige Coder hier im Forum mal richtig ausdiskutieren, ob sie sich für eine andersartige CPU begeistern könnten oder nicht. Was man nicht außer Acht lassen sollte: Die Projekte, die auf echte CPUs setzen, MÜSSEN nehmen, was es schon gibt. Wenn wir einen Großteil des Rechners als FPGA umsetzen wollen (und vorab vielleicht sogar nur als Emulation), haben wir als Alleinstellungsmerkmal, uns unseren eigenen Wunsch-Prozessor auszudenken.
Ich denke, bei vielen anderen Merkmalen gibt es hier durchaus einen Konsens: Wirklich günstiger Preis (unter 150, besser noch unter 100 €), Anschlussmöglichkeit an aktuelle Screens, sehr moderate Grafik- und Soundfähigkeiten (die unter denen von frühen 16-Bit-Rechnern liegen), SD-Karte als Massenspeicher, mitgelieferte, leistungsfähige Programmiersprache im "ROM", Verzicht auf kryptische DOS-Kommandos. Ich denke, das ist doch schon ein ganz ordentlicher Konsens, den hier wahrscheinlich fast alle unterschreiben können.
Vielleicht dient ja dieser Thread dazu, dass man zumindest einen gewissen Konsens findet und sowas in der Art eines "Forum64-Community-Retrocomputer" herauskristallisiert? Das wäre doch ein schönes Gemeinschaftsprojekt.
So ist die Diskussion ja auch eigentlich gedacht. Ich denke, je mehr Leute man ins Boot holen kann (gerade auch welche mit Expertise), desto größer die Wahrscheinlichkeit auf Realisierung (wobei da nicht der Fokus drauf liegt) und desto mehr Spaß und Befriedigung für alle Beteiligten.
Ich denke, bei vielen anderen Merkmalen gibt es hier durchaus einen Konsens: ... Anschlussmöglichkeit an aktuelle Screens
Die Frage ist halt, was aktuell ist. VGA (analog), DVI (analog oder digital), HDMI oder DP?.
Und falls man sich aus pragmatischen Gründen zunächst für VGA entscheidet: Welche Probleme sind bei einer späteren Wandlung oder Umrüstung auf digitale Ausgabe vieleicht schon abzusehen und können eventuell schon im Vornhinein berücksichtigt werden?
Welche Probleme sind bei einer späteren Wandlung oder Umrüstung auf digitale Ausgabe vieleicht schon abzusehen und können eventuell schon im Vornhinein berücksichtigt werden?
Vielleicht sollte man sich beim geplanten Retrocomputer von der ganzen Hardware trennen und das ganze als reine Emulation hochziehen.
Das kostet dann kein Geld bei der Anschaffung und man hat alle verrückten Freiheiten, wie Befehle die euch schon immer beim 6502 gefehlt haben oder Sprites ohne Multiplexerproblemen usw.
Wer will kann das fertig emulierbare System dann immer noch nach FPGA umsetzen.
Die Frage ist halt, was aktuell ist. VGA (analog), DVI (analog oder digital), HDMI oder DP?.
Und falls man sich aus pragmatischen Gründen zunächst für VGA entscheidet ...
Vielleicht ist es doch kein Konsens. Mit "aktuell" meine ich eigentlich auf jeden Fall was digitales.
Vielleicht sollte man sich beim geplanten Retrocomputer von der ganzen Hardware trennen und das ganze als reine Emulation hochziehen.
Wir haben ja schon gesagt, dass eine Emulation für den Anfang nicht verkehrt wäre – schon um ohne große Kosten alle Komponenten auf einander abzustimmen und die ganze Sache wirklich "rund" zu machen. Aber am Ende sollte meines Erachtens immer ein "Gerät" stehen, keine reine Software – einfach, weil ich davon überzeugt bin, dass eine reine Software-Lösung nicht die Bindung/Emotion aufbauen kann, die "the real thing" schafft.
Vielleicht waere es parallel zu diesem Thread ganz interessant, mal aufzulisten, was es alles schon an solchen Projekten gibt. Es gibt da ja wirklich einiges... aber vieles davon ist halt irgendwie halb-fertig oder hat keine nennenswerte Verbreitung. Auch waere es interessant, mal eine Liste von Dingen zu machen, die die Leute an existierenden Computern toll finden. Das kann einem ebenfalls Ideen liefern, was der "Super-Computer" alles koennen sollte. Zum Beispiel wenn ein Computer die Sprites auf eine geschickte Art und Weise handlet oder coole Dinge erlaubt, die andere Computer aus der selben Zeit nicht koennen.
Ich habe ja auch mal ein aehnliches Vorhaben gestartet (allerdings rein in Software), da sah meine Palette relativ aehnlich aus:
Im Prinzip habe ich ebenfalls versucht, alle wichtigen Farben unterzubringen, allerdings gibt es kein Braun. Dafuer aber orange und sowohl von Cyan als auch Lila zwei Helligkeiten. Dafuer nur 2 Graustufen.
Allerdings war das jetzt noch nicht zwingend als "final" anzusehen
Sie hat natuerlich auch eine gewisse Aehnlichkeit mit der 16-Farben-EGA-Palette, allerdings gab es dort z.B. kein orange.
Ansonsten finde ich es uebrigens auch wichtig, dass man sich Gedanken macht, ob wirklich unbedingt alles "verbessert" werden muss. Ich z.B. finde nicht, dass man eine Aufloesung in der Richtung 640x480 braeuchte, und mir reichen auch 16 Farben. Im Gegenteil, ich wuerde beim Design eines 8-Bit-Computers vielleicht sogar mehr einschraenken als beim C64. Ich finde z.B. auch eine Aufloesung wie 256x192 ganz sexy, ueber 320x200/240 wuerde ich jedoch auf keinen Fall gehen. Also die Kernfrage ist halt, muss der Computer unbedingt alles uebertreffen, oder kann er auch in gewissen Dingen gleichauf sein oder niedriger spezifiziert sein als der C64 oder ein anderer Zeitgenosse.
Denkbar waere natuerlich auch ein 640x480-Modus aber dafuer nur Monochrom, oder nur mit wenigen Farben. Diesen koennte man dann z.B. fuer den Code-Editor nutzen, oder fuer simple Anwendungen, waehrend Spiele dann doch eher in 320x240 oder 256x192 oder sonstigem laufen wuerden. War ja unter DOS eigentlich auch so, da gab es natuerlich Anwendungen mit 640x480, aber DOOM und Wolfenstein hat man trotzdem mit 320x240 gezockt, was auch vollkommen ausreicht meiner Meinung nach.
Alles anzeigenIch habe ja auch mal ein aehnliches Vorhaben gestartet (allerdings rein in Software), da sah meine Palette relativ aehnlich aus:
Im Prinzip habe ich ebenfalls versucht, alle wichtigen Farben unterzubringen, allerdings gibt es kein Braun. Dafuer aber orange und sowohl von Cyan als auch Lila zwei Helligkeiten. Dafuer nur 2 Graustufen.
Allerdings war das jetzt noch nicht zwingend als "final" anzusehen
Sie hat natuerlich auch eine gewisse Aehnlichkeit mit der 16-Farben-EGA-Palette, allerdings gab es dort z.B. kein orange.
Das sind ja fast CPC Farben. 
Im Prinzip habe ich ebenfalls versucht, alle wichtigen Farben unterzubringen, allerdings gibt es kein Braun.
Du pixelst ja meistens "flat", während ich zu denen gehöre, die sehr viel mit Helligkeitsverläufen und Schattierungen arbeiten. Ich guckte da weniger auf einzelne hübsche bunte Farben, sondern darauf, möglichst viele gute Abstufungen hinzubekommen. Da ist der C64 grundsätzlich besser aufgestellt als die meisten anderen Systeme (mit kleiner Palette). Braun würde ich bei deiner Palette schmerzlich vermissen – wie soll ich z.B. Bäume oder manche Tiere pixeln? Ich habe ja sogar noch die Natur-Farben um das zusätzliche Grün verstärkt, weil es mir so oft fehlte (und ich pixele nun wirklich nicht nur Wald-Szenen, wie man jetzt vielleicht meinen könnte). 
Hier zeigt sich jetzt aber ein "Problem" bei einer festen Palette. Der, der sie vorgibt, definiert den Output-Style merklich mit. Bei einer Auswahl-Palette ist das natürlich weniger der Fall – aber wie gesagt: es bestände die Gefahr, dass es am Ende gar keinen typischen Output gäbe und die Darstellung verhältnismäßig beliebig aussähe.
