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 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.
Ü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.
D64-Diskimage mit Testbild laden:
[download id=”1″ format=”4″]
Die Farben werden ermittelt, indem ein Testbild (hier als D64-Diskimage herunterzuladen) 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 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 bitten um möglichst umfangreiche Teilnahme an diesem Projekt, um einen möglichst großen Datenpool zu erhalten. Als Dank für Ihre Mühe bekommen Sie die ermittelten Daten sofort persönlich zur Verfügung gestellt. Der Testaufbau sollte wie folgt geschehen:
Bitte laden Sie zunächst das D64-Image herunter und kopieren Sie es sich (mittels X-Kabel o. ä.) auf eine echte C64-Diskette. Das auf dieser Diskette gespeicherte Testbild sollte nun auf dem C64 geladen und gestartet werden (es handelt sich um ein FLI-Bild mit integriertem Loader). Alternativ können Sie natürlich das D64-Image (oder den Inhalt) auch auf eine Speicherkarte kopieren, wenn Sie eine Speicherkartenlösung (MMC64, SD2IEC, 1541u) für den C64 besitzen. Bitte verwenden Sie keinen C64-Emulator für den Test, da wir die Farben der echten C64-Hardware ermitteln möchten und keine simulierten!
Stellen Sie nun den C64-Bildschirm so auf, dass sie diesen und den Bildschirm Ihres Referenzsystems (PC oder Mac) gleichzeitig sehen können. Versuchen Sie, das Umgebungslicht und die Bildschirmeinstellungen so anzupassen, dass sie Ihren üblichen Vorgaben entsprechen.
Sobald Sie auf dem C64 das Testbild sehen, können Sie den 2. oben angegeben Link anklicken. Das Java-Applet lädt und startet nun.
Hier sehen Sie das gleiche Testbild mit nicht optimierten Farben. Sie können nun eine beliebige Farbe im Bild per Mausklick auswählen und diese mittels der Regler am unteren Rand verändern, bis sie der Darstellung auf dem Original C64-Bildschirm entspricht. Bitte überprüfen Sie alle Farben bzgl. Ihrer Wirkung zueinander in den Farbstreifen und Testbildern.
Da es immer 2 Farben (außer schwarz und weiß) mit gleicher Helligkeit gibt, werden diese Paare in ihrer Helligkeit standardmäßig gemeinsam verändert (Das Paar wird optisch hervorgehoben). Diese Funktion können Sie ausschalten, wenn Ihre Wahrnehmung eine andere ist.
Nachdem Sie alle Farben angepasst haben, können Sie uns weitere Informationen über den Testaufbau in der rechten Randspalte mitteilen. Wenn Sie zu bestimmten Fragen keine Antworten wissen oder angeben möchten, lassen Sie sie einfach frei. Zum Schluss können Sie individuelle Anmerkungen (andere verwendete Hardware, Verbesserungsvorschläge etc.) und eine persönliche Kennung einfügen.
Sollte Sie verschiedene Hardwarekombinationen testen, verwenden Sie bitte immer die gleiche Kennung, damit wir wissen, dass die Ergebnisse von der gleichen Person kommen. Wenn Sie als Kennung Ihre eMail-Adresse angeben, bekommen Sie automatisch die von Ihnen eingestellten Werte als VICE-Palette, GIF-Farbpalette und RGB-Dezimalwerte zugeschickt. Bis wir eine gemittelte Palette ermittelt haben, können Sie mit ihren persönlichen Farbwerten arbeiten. Am Ende der Studie bekommen Sie dann die empirisch ermittelte Palette zugeschickt.
Wir hoffen, dass die hier ermittelte und von uns “C64 Community Colors” genannte Farbpalette in vielen C64 Screenshots, Webseiten, Grafikkonvertern und Emulatoren verwendet werden wird. Wir bedanken uns bei allen Teilnehmern an unserer Studie für ihre Zeit und Mühe, die sie der Verbesserung der Community Colors gewidmet haben.
Willkommen auf P1X3L.net, der Projektseite von ALeX und Retrofan. Hier stellen wir gemeinsam erstellt Projekte ins Netz, die sich im weitesten Sinn um Mac OS, C64, Spiele und Grafik drehen. Momentan suchen wir Teilnehmer für das Community Colors Projekt, mit dem möglichst gut genäherte RGB-Farb-Entsprechungen zu den C64-Farben gefunden werden sollen.
Parallel arbeiten wir an einem C64 Grafik Konverter, der sich besonders dadurch auszeichnet, dass er Plattform-unabhängig online zur Verfügung stehen wird, besondere Raster- und Farb-Möglichkeiten bietet und bestmöglich auf die Einschränkungen der C64-Grafikmodi eingeht.
Bis zum Release des neuen Konverters steht den Besuchern unserer Website eine kleine Vorversion zur Verfügung, mit der man schon mal farbige Koala-und FLI-Bilder erzeugen kann.
In Zukunft werden wir hier noch weitere (z. T. schon fertig gestellte) Programme und Mac OS X Widgets vorstellen und zum Download anbieten.
Wir wünschen allen Besuchern viel Spaß und hoffen auf baldige Wiederkehr.