Wir entwickeln Software für aktuelle und klassische Computersysteme
Wir (Heavy Stylus [RGCD], ALeX, Taxim und ich) haben gestern SPACE LORDS bei der CSDB veröffentlicht. Damit steht auch diese Version kostenlos, quasi als Weihnachts-/Neujahrs-Geschenk, zum Download zur Verfügung. Wir wünschen, frohe Weihnachten gehabt zu haben und einen guten Rutsch ins neue Jahr.
Anlässlich der 16KB Cartridge Game Development Competition (2012) von RGCD haben ALeX und ich (unter unserem Label P1X3L-Net) heute das Spiel SpaceChem Nano veröffentlicht. Es ist, wie auch die anderen am Wettbewerb teilnehmenden Games auf der CSDB zu finden und kann dort heruntergeladen und bewertet werden. Um Enttäuschungen zu vermeiden: Bei Verwendung eines echten C64 benötigt man zusätzlich eine Commodore Maus (1351) zum Spielen. Auf Emulatoren wie VICE kann man diese natürlich auch emulieren – man muss aber evtl. konfigurieren, dass sie sich im virtuellen Controlport 2 befindet.
SpaceChem Nano basiert auf dem PC/Mac/Linux/iOS/Android-Game SpaceChem aus dem Hause Zachtronics Industries. Es musste allerdings auf Grund der geringeren technischen Möglichkeiten des C64 um einige Funktionen erleichtert werden. Wir denken aber, dass es trotzdem Spaß macht, im Reaktor Atome zu Molekülen zusammenzubauen.
Wahrscheinlich ist SpaceChem Nano das erste Spiel seit 28 Jahren, welches auch auf dem, im Vergleich zum C64 abgespeckten, Commodore Ultimax (nur 4k RAM, kein Kernal, kein Basic, kein Font, kein Serial I/O), auch MAX Machine oder VC-10 genannt, funktioniert. Wer noch so einen seltenen Klassiker besitzt, wird sich bestimmt über diese Nachricht freuen.
Foto: RGCD
Endlich haben wir es geschafft: Space Lords (Centaurus) für den C64 ist auf dem Markt! Seit gestern Abend kann man das Modul in einer normalen und einer Deluxe-Variante (unterscheiden sich nur in der Verpackung) im RGCD-Shop bestellen. Zusätzlich gibt es eine sehr preiswerte Download-Version für die Kunden, denen es nicht um den Erwerb eines attraktiven und gleichzeitig einfach zu handhabenden (Modul einstecken) Sammler-Objekts geht, sondern die einfach nur schnell losspielen wollen.
Hier ist die Beschreibungsseite auf RGCD.co.uk zu finden
Und hier geht es direkt zur Bestellung
Verbesserungen gegenüber der Competition-Version:
Die Entwicklung bleibt nicht stehen. Da wir Space Lords demnächst auf 16K-Cartridge veröffentlichen wollen, sind wir fleißig dabei, das Spiel weiter aufzuwerten. Erst einmal hat ALeX den Code stark aufgeräumt und er wird jetzt auch (wie der Rest des Spiels schon vorher) per Exomizer gepackt, sodass wir überhaupt Platz für Verbesserungen haben. Die Mehrheit der Veränderungen führe ich nachfolgend als Aufzählung fort (und werde sie im Laufe der Zeit, wenn nötig, ergänzen):
Optimierter, gepackter Code
Ladebildschirm mit Fortschrittsbalken
Optimierte Hintergrundgrafiken (Burgelemente, Weltraum)
Animierte Multicolor-Plasmabälle
Neue Grafiken für Geister-Schutzschilde (ausgeschiedenen Spieler)
Links-Rechts-Umkehr für Paddles bei oben liegender Burgposition (per Feuer-Button)
Anzeige-Unterscheidung des einzelnen Paddles jedes Paars/Ports (X/Y)
Schnellerer Spielablauf (Bälle starten schneller und werden seltener langsam)
Plasmaball/Abwehrkapsel-Kollisionsabfrage verbessert
Neue Namens-Eingabeboxen: alphabetisch bei eindimensionaler Eingabemöglichkeit (z.B. Paddles), QWERTY bei zweidimensionaler Eingabemöglichkeit (z.B. Joystick), Rahmen in Alienfarbe, hervorgehobener OK-Button
Musik-Abspielmöglichkeit im Intro-Screen (inkl. Demo-Musik)
Ich hoffe, man erkennt, dass wir viele Anregungen aus Probespielen und Compo-Bewertungen umgesetzt haben (und auch weiterhin werden), damit ein tolles Spiel-Modul bei dem Projekt herauskommt.
Update 1:
Wir werten jetzt auch aus, an welcher Stelle der Schild-Vorderseite ein Plasmaball auftrifft und lassen ihn in unterschiedlichen Winkeln abspringen. Dadurch bekommt man eine bessere Kontrolle über den Weg des abprallenden Plasmaballs, um ihn in eine bestimmte Richtung zu lenken.
Update 2:
Neue Textfarbe und Ausblendungen für die Credits unterhalb des Logos
Spielernamen werden in den Farben der jeweiligen Aliens dargestellt
Die Paddle-Drehrichtung der oben befindlichen Spieler wird mit einem Icon angezeigt, Standard-Drehrichtung ist nun umgekehrt
Bei der Namens-Eingabe wird der Spiralnebel im Hintergrund angezeigt und nicht mehr das Logo
Update 3:
Im Startscreen werden jetzt (auf wechselnden Positionen) Alien-Lords, Namen und Kronen angezeigt
Wechselnde Anzeige von Intro-Screen und Highscores, Spiel-Start auch bei Highscore-Anzeige möglich
Rundenanzeige am linken Rand
Neue Sounds bei Siegerehrung, schnelleres Addieren der Punkte, Spielernamen an Treppe in Farbe
Musik setzt direkt nach Siegerehrung wieder ein
Space Lords Andromeda II (28.5 KiB, 1. December 2011)
Die RGCD-Compo ist beendet und unser Space Lords hat es immerhin auf den 4. Platz geschafft. Alle teilgenommenen Games kann man von der CSDB.dk herunterladen und sich angucken bzw. spielen. Die Juroren waren so freundlich, zu jedem Titel ein paar Bemerkungen zu schreiben – die zu unserem Spiel möchte ich hier zitieren:
“Warlords was fun on the 2600 – and it’s more fun here, as it’s prettier by far. Initially unimpressive as it’s just a reworking of such an old concept – but paddle support, 4-players and good AI and mulitiplayer and multiball shenanigans make this a really fun diversion.” (Andy Jenkinson)
“C64 port of a classic. Cute graphics, nice gameplay. Could use >16KB maybe but its quite enjoyable. Could be faster maybe, would make a perfect party-game then. Very detailed considering its simple idea and 16KB limit.” (Enthusi)
“A Warlords clone/conversion for the C64 has been well overdue, and Space Lords was a huge surprise when released. It is brilliant, with many features from the original and some good AI built in too. Actually, some credit is well due for the AI that has been included, as it means that many can play the game compared to the original Warlords if you don’t have any friends. Presentation is simple, but does the job – with name entry for each player. Graphically functional, the game features some cartoony creatures to defend. Sound wise, it is a little bit quiet – with no music, and minor effects in the game. Overall a welcome surprise at the end of the competition, which means yet another Atari classic has made the transition 
” (Frank Gasking)
“Submitted just minutes before the deadline, Space Lords is a great conversion of Atari’s Warlords that (like the original coin-op) supports up to four players. Graphically it’s gorgeous and as a party game it totally rocks, but sadly the compo version lacks music. A great effort and debut game release nonetheless!” (Heavy Stylus)
“Another fun game here! A simple idea – defend the walls of your googly alien’s base in a corner of a screen using a breakout bat – and try to deflect the ball/comets into the walls of your enemy. Nice graphics, functional sfx, great playablility, smooth movement (and it gets nice and hectic once more balls come into play). Like this!” (Kenz)
“The C64 hasn’t had many Warlords style games, so I was pleased to see one here. Bonus points for supporting the four player adapter. However not being able to catch the fireballs is a major flaw, along with the wide-reaching arc of the bats themselves, making it hard to attack other players.” (Mayhem)
“Excellent puzzle game where the player is tasked to defend their little monster by moving the paddle across the defensive wall deflecting oncoming balls. With several balls flying around, things can get pretty hectic and soon requires super fast reflexes. Some great visuals and multiplayer option round things off nicely.” (Nreive)
“Space Lords is a surprisingly tricky bat and ball/base defence game with colourful alien antagonists reminiscent of the metropolitan clientele of the Amiga’s Shufflepuck Café. Multiball bonuses toughen the game up, and it’s quite easy to knacker your own base if you aren’t too careful.” (Ruari O’Toole)
“Visually beefed up Warlords on the C64 and it even manages a good single player game.” (T.M.R)
Mehr Kommentare (zu den anderen Games) kann man bei RGCD.co.uk nachlesen.
Die letzten, verhüllenden Schleier fallen, tatata: Unser Spiel für die RGCD C64 cartridge development competition heißt Space Lords und basiert vom Spielprinzip her auf dem Spielhallen-Klassiker Warlords aus dem Jahr 1980, welcher den meisten Classic-Gamern durch die erfolgreiche Atari 2600 Umsetzung bekannt ist. Warlords ist im Prinzip eine Art Breakout für 4 Spieler und so ist es auch bei unserer, in den Weltraum verlegten, Adaption.
Space Lords ist gedacht als spaßiges Party-Spiel für bis zu 4 Teilnehmer. Um möglichst Vielen die Gelegenheit zum Mitspielen zu geben, wird eine große Anzahl unterschiedlicher Eingabegeräte unterstützt. Die wichtigsten: “Paddles” von Atari, wie auch von Commodore. Da hier immer 2 Controller an einem Controll-Port des C64 Platz finden, können auf diese Weise 4 Personen gleichzeitig spielen. Sind allerdings keine (oder zu wenige) Paddle-Controller vorhanden, kann man auch Joysticks (Beschleunigung durch Feuer-Button), Commodore 1351 Mäuse und sogar Amiga Mäuse verwenden. Zur Komplettierung der Möglichkeiten kann zudem ein Spieler die Tastatur zum Steuern nutzen und es wird auch der gängigste 4-Spieler-Adapter (mit 2 zusätzlichen Control-Ports) unterstützt. An diesen können weitere 2 Joysticks oder Amiga Mäuse angeschlossen werden. Nicht von echten Spielern gesteuerte Alien-Lords werden vom Computer übernommen.
Die vier Alien-Lords kämpfen um die Krone ihrer Galaxie. Jeder Lord hat eine Raumstation am Rande des Spiralnebels und versucht, die Feuerbälle, die zwischen den Gegener hin- und her geschleudert werden, mit einem beweglichen Schutzschild abzuwehren. Man verteidigt sich solange, bis die Raumstationen immer weiter zerstört und die dort befindlichen Lords getroffen werden. Wer zuletzt übrig bleibt, bekommt die goldene Krone der Galaxie verliehen. Achtung, die Feuerbälle werden schneller und nach gewissen Abständen kommen auch weitere hinzu!
Space Lords befindet sich noch in der Entwicklung – wir haben aber die Hoffnung, das Spiel bis zum Abgabe-Termin Ende November fertig zu haben. Bitte drückt uns die Daumen, dass es keine unüberwindbaren Hindernisse bei Komplettierung und Fehlersuche gibt und dass wir bei der Competition gut abschneiden.
Nachdem wir jetzt schon sehr lange an unserem ersten “großen” C64 Spiel herum gebastelt haben, möchten wir nun noch etwas mehr zeigen, um langsam den Vorhang des Schweigens und Versteckens zu öffnen. Der Release-Termin rückt immer näher und zusätzlich zu der oben gezeigten Grafik können wir schon mal sagen, dass der Name des Spiels mit “Space …” anfängt.
Wir sind gerade fleißig und entwickeln ein Spiel für den C64. Es handelt sich um eine grafisch aufgepeppte und in einen neuen Kontext gestellte Arcade-Umsetzung. Wir wollen noch nicht zu viel verraten aber eines ist ohnehin schon bekannt: Es wird ein 16K-Modul.
Übersetzte Zusammenfassung und Kommentar
Ich beziehe mich in diesem Text auf eine Untersuchung von Philip “Pepto” Timmermann zu der Erzeugung der C64-Farben durch den VIC-II Chip, veröffentlicht (im Internet) um 1999 (der Artikel ist nicht datiert, aber ein angehängter Brief, der sich auf den Artikel bezieht und die Erkenntnisse weitgehend bestätigt, ist vom 27.9.1999). Der Text wird als Preview bezeichnet und sollte ab 2001 weitergeführt werden, was aber wohl bis heute (Anfang 2010) nicht geschehen ist.
Link zum Originaltext: www.pepto.de/projects/colorvic
Los geht’s:
Der Artikel beschreibt als erstes die Problematik, die C64-Farben auf heutigen Computersystemen korrekt zu simulieren und dass es eine Vielzahl von verschiedenen Farbpaletten gibt, die allesamt zu keinen optimalen Ergebnissen kommen. Timmermann erklärt, dass die Farbpalette 16 Farben in 9 Helligkeiten (late VIC-II luma) umfasst und dass sie im YUV-Farbraum (PAL-TV-Norm) erzeugt wird.
Die Helligkeit: Wenn man die mittels Oszilloskop gemessenen Helligkeiten (Y) der Farben in 8 Bit darstellen möchte, dann erhält man folgende Werte: 0, 64, 80, 96, 120, 128, 159, 191, 255.
Die Farbe: Timmermann hat das Chroma-Signal (U/V) mit einem Vektorskope gemessen und festgestellt, dass alle C64-Farben auf einem perfekten Kreis um den Kreuzungspunkt von U und V liegen und somit exakt die selbe Sättigung aufweisen. Deshalb gibt es keine Differenzen zwischen den U- und V-Koordinaten, sondern man hat nur einen Wert. Die Winkel sind perfekt teilbar durch 22,5° (ein Viertel von 90°).
Nun kennt man Y, U und V und kann sie in den RGB-Farbraum konvertieren, nur muss man herausfinden, welche Sättigung maximal möglich ist, ohne ungültige RGB-Farben zu bekommen. Da Braun die “Peak”-Farbe der C64-Palette ist (ihre Umrechnung zu RGB erzeugt als erstes einen negativen Blau-Wert), gibt sie den maximalen Sättigungsgrad vor. Mittels Näherungsverfahren kommt Timmermann auf einen Wert von ca. 34. Man sollte aber bedenken, dass Monitore/TVs Clipping betreiben (also zu hohe Werte abschneiden), wenn Werte “out of Gammut”, also außerhalb der Darstellungsmöglichkeiten liegen.
Timmermann geht davon aus, dass die von ihm berechneten, normalisierten Farben, denen entsprechen, die man auf einem Monitor/TV sieht, dessen Farbe, Helligkeit und Kontrast in Normalstellung stehen (bei Commodore-Monitoren haben die Regler einen Einrastpunkt für die “Normal”-Stellung). Wenn man eine höher gesättigte Palette erhalten möchte, soll man seine Berechnungen mit größeren Werten (vor der Gamma-Korrektur) durchführen. Er erwähnt noch, dass der damals neue C64-Emulator “CCS64 2.0 Beta” die Werte für Kontrast, Helligkeit, Sättigung und Gamma “on the fly” mittels seiner Berechnungen verändern kann.
Timmermann berechnet nun die YUV-Farbwerte der C64-Farben. Ich mache das hier beispielhaft für die Farbe rot:
Winkel = 5 x (360° : 16) | Y = 10 x (255 : 32) | U = Peak x Cos(Winkel) | V = Peak x Sin(Winkel)
Winkel = 112,5° | Y = 79,6875 | U = -13,01434923670814368 | V = +31,41941843272073796
Danach brechnet er nach folgender Formel die RGB-Farben:
R = Y + 1,140 x V | G = Y – 0,396 x U – 0,581 x V | B = Y + 2,029 x U
R = 116 | G = 67 | B = 53
Erst nach den Umrechnungen zu RGB und allen Korrekturen/Manipulationen soll die Gamma-Korrektur erfolgen. Timmermann ist sich bzgl. der von ihm verwendeten Gamma-Werte nicht ganz sicher. Er definiert den Gamma-Wert vom C64-Monitor als 2,5 (obwohl er für PAL laut ihm offiziell bei 2,8 liegt) und den Gamma-Wert des Zielsystems bei 2,2 (PC-Norm, Macs verwendeten bislang 1,8). Die Gamma-Korrektur erfolgt mit der Formel: R, G und B-Wert jeweils hoch 1,136 (2,5 : 2,2) und danach das Ergebnis auf 8-Bit-Werte proportional strecken.
Zum Schluss zeigt Timmermann einige Bilder, die zum Vergleich jeweils mit seiner errechneten und der original CCS64-Farbpalette erzeugt wurden und listet die Hex-Werte der 16 C64-Farben für die Nutzung in eigenen Programmen auf:
000000 | FFFFFF | 68372B | 70A4B2 | 6F3D86 | 588D43 | 352879 | B8C76F
6F4F25 | 433900 | 9A6759 | 444444 | 6C6C6C | 9AD284 | 6C5EB5 | 959595
Abgeschlossen wird die Veröffentlichung durch einen Brief von Bob Yannes (Mitentwickler des VIC-II), der kurz über die Unterschiede von PAL (YUV) und NTSC (YIQ) eingeht und weitgehend die Erkenntnisse von Timmermann bestätigt, mit der Ausnahme, dass sie die Auswahl der Farben nicht wirklich so wissenschaftlich betrieben hätten, sondern, nachdem sie die Möglichkeit hatten, beliebige Farben zu erzeugen, ganz einfach den Geschmack hätten entscheiden lassen. Um Platz auf dem Chip zu sparen, hätten sie bei einigen Farben dann einfach die auf dem Farbkreis gegenüberliegende gewählt, da sie sich so bestimmte Werte teilen konnten. Zum Schluss erwähnt Yannes noch, dass es durchaus Toleranzen gab, was die Farbdarstellung einzelner Rechner anbelangte.
Kommentar
Was die Messwert-Erfassung von Timmermann angeht, gibt es wohl kaum Widerspruch. Auch seine Erkenntnisse und Berechnungen möchten wir nicht anzweifeln.
Jetzt habe ich aber das Problem, dass die so definierten Farben weder in den Emus (ohne Verwendung einer PAL-Emulation) noch auf den Screenshots im Netz so aussehen, wie ich sie von meinen C64-Modellen zuhause kenne. Im Zusammenspiel der 16 Farben zueinander stimmen die Pepto-Farben besser als jede optisch erzeugte Palette aber sie wirken insgesamt zu wenig gesättigt, zu schmutzig, zu dunkel.
Nun wollte ich feststellen, ob es sich bei mir um einen Einzelfall handelt oder ob bei anderen Personen und Geräten auch die Farben stark abweichen.
ALeX und ich haben daraufhin einen Test gestartet, der ermitteln soll, wie Personen die C64-Farben wahrnehmen und ihnen hilft, möglichst ähnliche Farben auf dem Zielsystem zu finden. Hierzu wird ein Testbild auf dem C64 gezeigt und das gleiche Bild in einem Java-Programm auf dem Zielsystem. in diesem Programm kann man nun mittels verschiedener Farbregler jede Farbe so einstellen, dass sie (vor allem im Vergleich zu den anderen Farben) der Darstellung auf dem C64 entspricht.
Näheres dazu kann man in zwei weiteren Blog-Einträgen lesen: Zum einen gibt es eine allgemeine Einführung zu unserer Projektidee und zum anderen gibt es eine detailierte Anleitung, wie man am Projekt teilnimmt und seine eigene Farbtabelle bestimmt.
Dieses Projekt dient der Erzeugung einer empirisch ermittelten RGB-Farbpalette aus den 16 Farben des klassischen C64-Computersystems. Da es keine eindeutige Übertragung der C64-Farben auf heute gebräuchliche RGB-Farbwerte gibt, haben wir eine optisch angenäherte Farbpalette ermittelt und verbessern sie stetig weiter.
Beim Spielen in verschiedenen C64-Emulatoren auf unterschiedlichen Systemen und vor allem beim Betrachten von C64-Screenshots auf Webseiten fiel uns auf, dass es keine einheitliche Darstellung der 16 Farben des C64 auf aktuellen System gibt. In den Emulatoren kann man meist zwischen einer großen Anzahl von Farbtabellen à 16 Farben auswählen und zusätzlich oft noch die Farben weiter manipulieren (in VICE z.B. mit der PAL-Emulation). Die C64-Screenshots auf Webseiten muss der Betrachter allerdings so nehmen, wie sie der Autor abgespeichert hat.
(Hier fehlen noch Abbildung unterschiedlicher Farbtabellen oder Screenshots)
Die Farben des C64 wurden nicht als RGB-Werte definiert, sondern analog erzeugt und aufbereitet, daher gibt es keine direkte Umrechnung. Es gibt zwei Möglichkeiten, die Farben des C64 heute möglichst originalgetreu darzustellen: Erstens auf dem Wege des optischen Vergleichs und zweitens über Erkenntnisse, wie die C64-Farben erzeugt werden.
Farben über optischen Vergleich
Alle existierenden Farbtabellen, bis auf die Pepto-Palette, auf die ich später noch zu sprechen komme, basieren auf dem Vergleich der C64-Farben auf einem TV (oder damals üblichen 14″-CRT-Monitor) und der Darstellung auf einem Zielsystem (meistens ein PC). Grundsätzlich nicht die dümmste Idee, allerdings weist sie mehrere Probleme auf:
1) Bei fast allen erzeugten Farbtabellen wurde jeweils nur eine einzige Rechnerkombination verwendet, Monitore weichen in Ihrer Farbdarstellung aber stark voneinander ab.
2) Das verwendete Zielsystem (z.B. Amiga mit Röhrenmonitor) entspricht in seiner Farbdarstellung oft nicht dem heutigen Stand, die ermittelten RGB-Farben wurden aber einfach übertragen.
3) Es gab meist nur einen Betrachter, der den Vergleich durchgeführt hat. Dieser hat evtl. aber Probleme, die Farben richtig zu treffen und es gibt kein Korrektiv.
4) Es wurden keine für diesen Zweck optimierten Testbilder verwendet, bei denen die Farben im Zusammenspiel mit anderen gezeigt werden, z.B. Farbverläufe oder Original-Artwork. So werden Helligkeiten und Farbübergänge nicht optimal getroffen.
5) Es wurden nur unzureichende Werkzeuge für die Einstellung der nachempfundenen Farben auf der Zielplattform verwendet, z. B. RGB-Farbregler in Grafikprogrammen.
Die so erzeugten Farben mögen bei dem Ersteller mehr oder weniger passen, solange er seine Hardware nicht verändert aber verbindlich für andere Systeme ist das natürlich nicht. Deshalb gibt es ja so viele unterschiedliche Farbtabellen, denn genau so sind sie entstanden.
Die Pepto Palette
Deshalb waren alle froh über Pepto Timmermanns gänzlich anderen Ansatz, die 16 Farben des C64 zu ermitteln: Nicht gucken, sondern messen und rechnen.
Stark gekürzte Vorgehensweise: Mit einem Oszilloskop die Helligkeit der Farben am Monitorausgang messen und die Werte in 256 Abstufungen (8 Bit) übertragen. Dann mit einem Vektorskope die Winkel des Chroma-Signals (U/V) messen. Die Farbwinkel sind durch 22,5° teilbar, U- und V-Koordinaten haben den gleichen Wert und die Farben weisen alle die gleiche Sättigung auf. Nun kennt man Y, U und V und kann sie in den RGB-Farbraum konvertieren, nur muss man herausfinden, welche Sättigung maximal möglich ist, ohne ungültige RGB-Farben zu bekommen. Da Braun die “Peak”-Farbe der C64-Palette ist (ihre Umrechnung zu RGB erzeugt als erstes einen negativen Blau-Wert), gibt sie den maximalen Sättigungsgrad vor. Erst nach den Umrechnungen zu RGB und allen Korrekturen/Manipulationen soll die Gamma-Korrektur erfolgen. Dafür muss man die ermittelten Farbwerte mit den PAL-Gamma-Werten und denen des Zielsystems verrechnen und auf 8 Bit strecken.
Eine etwas ausführlichere Übersetzung ins deutsche kann man in diesem Blog-Eintrag finden.
(hier kommen evtl. noch Beispielbilder hin)
Das Problem
Eigentlich könnte man jetzt sagen (und viele tun dies auch): Fertig, Problem gelöst! Jetzt habe ich aber das Problem, dass die so definierten Farben weder in den Emus (ohne Verwendung einer PAL/TV-Emulation) noch auf den Screenshots im Netz so aussehen, wie ich sie von meinen C64-Modellen zuhause kenne. Im Zusammenspiel der 16 Farben zueinander stimmen die Pepto-Farben besser als jede optisch erzeugte aber sie wirken insgesamt zu wenig gesättigt, zu schmutzig, zu dunkel. Die Original-Farben des C64 sind zwar nicht besonders brillant (rot und orange sind eher Brauntöne und das Gelb gleitet ins grau-grünliche ab) aber so extrem, wie die Pepto-Farben es zeigen, ist es nach meinem Augenschein nun auch wieder nicht. In Gesprächen mit anderen C64 Nutzern wurde meine Beobachtung bzgl. der zu blassen Farben bestätigt. Evtl. passiert im Monitor/TV mit den Farben etwas, dass Timmermann nicht mit in seine Berechnungen einbeziehen konnte, evtl. werden sie getweakt oder es wirkt sich das unterschiedliche Verhalten der drei Leuchtstoffschicht-Grundfarben im TV aus. Was kann man also tun?
Die Lösung
Wir haben mit den Pepto-Formeln viel herumgerechnet, andere Gamma-Korrekturen verwendet, die Sättigung erhöht etc. aber nie kamen wir zu einem Ergebnis, dass die Farben so aussehen ließ, wie ich es von meinen C64-Rechnern gewohnt war. Um festzustellen, ob nur ich ein Problem mit den Farben habe oder wie andere das wahrnehmen, haben ALeX und ich das Community Colors Projekt gestartet. Im Prinzip wollten wir den Farbabgleich so machen, wie es auch zuvor meist gemacht wurde (durch optischen Vergleich) aber ohne die genannten Nachteile. Diese Probleme werden durch 3 Maßnahmen vermieden:
1) Wir bekommen Farbvergleichen von unterschiedlichen Systemkombinationen und Betrachtern und mitteln die Werte statistisch aus. Die Farben eines zu dunklen Schirms werden durch die Farben eines zu hellen Schirm z. B. ausgeglichen. Dadurch sind wir sehr fehlertolerant.
2) Wir verwenden ein optimiertes Testbild mit vielen Anwendungsfällen der Farben: Sie stehen auf unterschiedlichen Hintergründen, es gibt Bilder, Verläufe, Graukeile und Flächen. Dadurch kann der Betrachter die Farben im Zusammenspiel sehen und die beiden Bilder besser in Einklang bringen.
3) Wir verwenden bessere Farbauswahlboxen, als sie die meisten Grafikprogramme bieten. So unterstützen wir den Betrachter, die von ihm gewünschte Farbe auch wirklich zu treffen.
Eine Kritik zu unserer Projekt-Idee möchte ich nicht unerwähnt lassen: Warum soll man eine weitere Farbpalette ermitteln, wenn man doch einfach die Pepto-Farben in der PAL-Emulation eines C64-Emulators tweaken kann? Dazu möchte ich folgendes erwidern: Erstens haben nicht alle C64-Emulatoren so eine PAL-Emulation, zweitens trauen sich die meisten gar nicht, die Farben zu verändern, da sie ja “aufwändig berechnet und optimal” sind und drittens gibt es eine Vielzahl von Anwendungen, wo man auf keine PAL-Emu zurückgreifen kann. Die Community Colors sind in erster Linie gedacht für Anwendungsfälle, wo man schnell und einfach eine möglichst passende Palette braucht: Bei C64-Screenshots auf Webseiten und auch bei Grafikkonvertern zum “matchen” der Farben.
Die Community-Farben werden ermittelt, indem ein Testbild auf dem C64 mit der Darstellung des gleichen Bildes in unserer Java-Anwendung auf einem PC (Windows/MacOS/Linux) verglichen wird. Die PC-Farben können im Java-Programm nach Augenschein per Regler angepasst werden, bis eine Übereinstimmung mit der C64-Darstellung gegeben ist. Danach kann diese optimierte Farbpalette zu unserem Server übertragen werden. Wir generieren dann aus allen übertragenen Farbwerten eine gemittelte Farbpalette, indem wir die Gammakorrektur des jeweils verwendeten Zielsystems heraus rechnen, alle Farben in den geräteunabhängigen LAB-Farbraum transferieren, dort geometrische Mettelwerte errechnen und in den standardisierten sRGB-Farbraum (inkl. Gamma-Anpassung) konvertieren.
Schon die ersten übertragenen und gemittelten Profile haben uns gezeigt, wie gut die empirisch erzeugte Farbpalette funktioniert. Die Abstufung der Farben und Helligkeiten zueinander sind genau so überzeugend, wie die der Pepto-Palette aber die Sättigung der meisten Farben ist höher, was die Grafiken einiges schöner und überzeugender macht. Wir meinen, die CoCo-Palette stellt einen überzeugenden Kompromiss zwischen Genauigkeit und Farbbrillanz dar und beweist damit ihre Existenzberechtigung.
(hier werden wir Beispielbilder einfügen)
Wir haben nun eine ausreichende Anzahl von Farbsätzen bekommen, um eine recht stabile Wahrnehmungs-Farbpalette zu erzeugen. Damit sie von allen interessierten Personen genutzt werden kann, z. B. um Screenshots für Webseiten zu generieren oder für die Farbumwandlung eines Grafikkonverters, stellen wir hier demnächst die Community Colors V1.0 hier zur Verfügung. Wir möchten uns an dieser Stelle bei allen bedanken, die an der Erstellung der Farbpalette beteiligt waren und uns Profile geschickt haben. Trotzdem möchten wir auch weiterhin darum bitten, uns Farbprofile zukommen zu lassen, damit wir diese in die CoCo-Farbpalette integrieren können. Denn besser geht immer.