Open Source Led Matrix Steuerung: PixelController

Zitat von michuNeo

danke für die blumen wenn du nix dagegen hast, werde ich diesen satz umgehen auf meine webseite (pixelinvaders.ch) schmeissen!

Ja, gerne, wie gesagt, *für mich* ist das so, eben auch hautpsächlich wegen der Modularität/Erweiterbarkeit...

habe schon gesehen, dass Du auf der Neophob.com schon den mini-DMX-Output erwähnst... da steht auch was von HL1606... gibt's da ein Output-Modul für..? - weil der kann ja nur 8 Farben (*insg.* 3 bit) und ein paar Verläufe...

da wäre es wohl besser, den TM1804 zu erwähnen, der kann auch 3x 8 bit, ist relativ verbreitet, und kann auch mit meiner SEDU-SW angesteuert werden...

Zitat von michuNeo

hmm tönt nach einer sinnvollen erweiterung ja. ich muss mir das noch genau überlegen, weil wenn ich mehrere pixelinvaders panels verwende kann ich einerseits ein visual für zwei outputs verwenden, andererseits kann ich auch ein visual auf beide outputs scretchen...

wenn ich das richtig verstanden habe, sind das aber max. 4 versch. Panels, oder..? - ich weiß nicht, wie das da intern läuft, aber evtl. kann man das ja auch so machen:

würde dann bedeuten, Visual Nr. 2 (das auch gerade bearbeitet wird) geht auf Panel 1 und 3, Visual 4 geht auf Panel 2 und Visual 5 auf Panel 4... bei mir wäre halt oben immer nur ein Balken aktiv, da ja nur ein Output...

EDIT: Sorry, dein edit gerade erst gesehen - schau' ich mir gleich mal an

Zitat von michuNeo

da ist schon implementiert, einfach alt+NR drücken. wenn du das ändern willst, rechter mausklick auf "pf keyboard", öffnen. dort wird definiert, was passiert, sprich du kannst dort deine änderungen machen.

geht bei mir leider nicht - egal ob Nr. oder alt+Nr., er macht immer das "current visual"...

und editieren kann ich da in der pd-Datei irgendwie auch nix:

also ich kann da nix verschieben/ändern/anders "verkabeln"...

Zitat von michuNeo

edit: achja, geile videos von pixelcontroller schau ich mir doch immer gerne an

Klar, wenn die Kugelmatrix mal läuft, gibt's ein Video davon, natürlich mit Schwenk auf den Laptop, damit man auch sieht, womit die angesteuert wird...

Übrigens, witzig, ich habe doch oben das mit der "XML-Datei" erwähnt - und mich vorher schon gewundert, warum das "Blinken" heisst... ich kannte vorher nur "Blinkenlights", also dieses CCC-Hochhaus in Hamburg, und die kleine Version "Blinkenleds" (LED-Matrix auf Lochraster über Parallelport gesteuert) - schon Jahre her, und dass es da ein eigenes Dateiformat gibt, wusste ich noch nicht... bisschen gegoogelt, da gibt's ja sogar nen graphischen Editor dafür...

generell schon komisch, alles was man vor hat, hat schon mal jemand gemacht... - Deine SW ist ja nun im Prinzip genau das, was mein Kumpel und ich für unsere Matrix machen wollten...

Und sowas in der Art (Matrix aus Kugeln) hat vor Jahren (2004!) schon mal hier in Regensburg jemand gebaut, wie ich erfahren habe, witziger Weise kenne ich den sogar vom sehen her, wusste aber nicht, dass der auch (also schon viel länger als ich) so Zeug bastelt...

aber egal, man muss ja nicht immer das Rad neu erfinden....

ääh, was wollte ich *eigentlich*...? - ja, die Umsortier-SW mit Gammakorrektur vorstellen... wie die Zeit vergeht, was Essen müsste ich auch noch...

Hm, bei mir ist da nun kein zusätzlicher Balken... aber k.A. was das ist/woran's liegt...

Zitat von michuNeo

um in pure data was zu editieren, musst du in den edit mode wechseln (ctrl. + e),

Ah, das wusste ich nicht! - wie gesagt, ich muss mir nun erst mal das PD etwas genauer ansehen..

Zitat von michuNeo

die aktuellen keyboard einstellungen gelten für mein macbook.

ah, OK, die Sache wieder... (nicht falsch auffassen, bin selbst Mac-User in der Arbeit, allerdings immer noch OS9... ;))

Zitat von michuNeo

und zu den unterstützen output module, isch schrieb

Zitat
It is quite sim­ple to sup­port more stan­dards pro­to­cols like WS2801, HL1606 etc.

also noch nicht, sollte aber einfach sein!

Ja, und ich meinte eben, HL1606 zu unterstützen wird nicht so einfach sein (bzw. kein sinnvolles Ergebnis bringen), weil der R, G und B jeweils nur an und aus kann...

und WS2801/TM1804 *wird* ja bereits unterstützt, zwar nicht direkt mit nem Output-Modul (wäre auch schwierig, wo soll das Signal raus kommen am Rechner) aber eben über mini-DMX und meine SW... das kannst Du gerne erwähnen und die auch verlinken (der Thread in der Lobby), das erhöht ja evtl. den potentiellen Interessentenkreis (also eben die, die schon ne WS2801/TM1804-Matrix haben...)

Zitat von michuNeo

und vonwegen es gibt immer jemand der schon das selbe gemacht hat, ich habe gestern auch unter http://www.instructables.com/id/Rave-Rov?le-Dance-Stage/ meinen pixel doppelgänger gefunden

naja, das ist nicht direkt ein Doppelgänger, da sind die Seiten ja zu/lichtdicht... - das erinnert eher an den Tisch hier, wobei man auf dem aber nicht tanzen sollte...

Dein Panel (mit den transparenten Seiten) erinnert eher an das hier...

versteh' mich nicht falsch, aber das geniale an Deinen Panels ist ja eben die Ansteuer-SW - das Panel selbst ist immer gleich, immer irgendwie LEDs mit Treibern oder als Matrix, Raster, Plexi drüber...

So, erst mal ne Theorie: Ich habe mal rein zum Spaß in der config.properties bei Mini-DMX-Baudrate 250000 eingestellt - gab dann beim Öffnen des Comports kein Gemecker, erst nachher, das kein Ping zurück kommt (klar, mein Receiver steht ja noch auf 115200...)

Kann das sein, dass das bei Dir nicht geht, weil der ja den VCP vom Arduino öffnen will, und *der* die 250k nicht unterstützt..? - der VCP vom FT232 aber schon... Atmowin geht darüber ja auch mit 250k...

bin jetzt zu faul, wieder den 16 MHz Quarz aufs Board zu löten, werde ich morgen aber mal ausprobieren...

dann, zu dieser Gamma-Sache: Ich habe ja die SW gemacht, die jede 2. Zeile "umdreht", damit man die Matrix in Schlangenlinien verkabeln kann - zum testen brauchte ich ein Bild, bei dem erkennbar ist, was rechts und links ist, und habe dafür den Gradienten genommen:

Nun ist mir aufgefallen, dass der auf den LEDs sehr unschön kommt, die erste LED recht dunkel, die nächsten 2 deutlich heller, und die letzten 5 dann schon alle fast Anschlag...

klar, das kommt von der unlinearen Empfindlichkeit des Auges, 50% PWM ist eben nicht 50% Helligkeit... ist ja bekannt.

*Am Bildschirm* korrigiert das die Grafikkarte jedoch entsprechend, so dass ein (auf der Matrix viel zu heller) Wert von 128/128/128 eben 50% grau ist...

Und bei Dir korrigieren das die LPD6803, die haben ja nur 5 bit Input-Auflösung, die sie aber gamma-korrigieren auf 8 bit PWM - bei Dir sollte der Gradient und die Farben also eh' passen...

das mit den Farben ist mir vorher auch schon aufgefallen bei unserer SW, siehe Video:

dass die Farben zu hell und blass kommen, dieses Dunkelgrün der Pflanze z.B. ist auf der Matrix hellgelbgrün...

Und das deckt sich eben *exakt* mit den "theoretischen Vorhersagen", die schon vor knapp 2 Jahren in diesem Thread gemacht wurden (siehe die Bilder dort)...

da ging's ja darum, dass sich eben auch die Farben ändern, wenn man jeden Kanal mit ner eigenen Korrekturkurve behandelt, meine Ansicht war dann, dass sie aber eben genau deswegen dann stimmen, weil's die Grafikkarte ja auch so macht - und so ist es auch...

ich habe daher mal in meine SW ne Gammakorrektur eingebaut, mit der Tabelle, die ich hier (huh, das ist schon über 3 Jahre her, wie die Zeit vergeht!) mal gemacht hatte... und damit ist das Ergebnis schon deutlich besser.

die Tabelle ist halt nicht ganz korrekt gerechnet und gerundet (war damals auch noch Anfänger), das wird noch korrigiert...

klar, mit so ner Korrektur hat man dann nicht mehr die vollen 8 Bit Auflösung, aber doch noch deutlich mehr (aktuell 197 Stufen) als die 5 Bit des LPD6803...

hier anbei mal die SW mit der Gammakorrektur, aktuell auf 8 Spalten eingestellt, das kann in der Datei "settings.inc" eingestellt werden:

; ================================================================================================
; Konverter mini-DMX auf WS2801/TM1804 in Schlangenlinienanordnung
;
; benutzerdefinierte Einstellungen
; ================================================================================================


.equ MATRIX_WIDTH		= 8			; Breite der Matrix in Spalten (2-85)


.equ BAUD_MDMX			= 115200		; Baudrate Mini-DMX-Empfang


.equ RGB_ORDER			= 0			; RGB-Reihenfolge:
							; 0 = nicht tauschen
							; 1 = tauschen RGB -> GRB
							; 2 = tauschen RGB -> RBG
							; 3 = tauschen RGB -> BGR
							; 4 = tauschen RGB -> BRG
							; 5 = tauschen RGB -> GBR


.equ PIX_REPEAT			= 1			; LEDs pro logischem Pixel (1-255)


.equ Pix_COUNT			= 256			; Pixel-Anzahl (1-256)
.equ Pix_PORT 			= PortC			; Ausgabeport WS2801/TM1804-Daten
.equ Pix_DDR 			= DDRC			; DDR WS2801/TM1804-Daten
.equ Pix_SDO			= 0			; Ausgabepin WS2801/TM1804 Data
.equ Pix_SCO			= 1			; Ausgabepin WS2801 Clock


; ================================================================================================

die Gamma-Korrektur ist an, wer sie zum Vergleich mal abschalten will, muss nur in der Datei "_ISR_Byte_Received.inc" die Zeile

rcall	_SUB_Gamma_Cor					; Gamma-Korrektur auf empf. Byte anwenden

auskommentieren...

ist jetzt kein o.t., ich habe diese SW ja extra wegen der Zusammenarbeit mit PixelController gemacht - da kommt dann noch ne Version, die per Jumper konfigurierbar ist, wird dann in dem Thread in der Lobby vorgestellt...

Zitat von michuNeo

und das mit der gamma korrektur ist so ne sache, die lpd6803 haben das wirklich nicht schlecht out-of-the-box gelöst (wenn auch unterschiedlich von bestellung zu bestellung)

Das ist dann natürlich auch doof, wenn es jedes Mal anders ist - ansonsten ja eigentlich ne recht gute Idee, wenn einem die Auflösung reicht, dass dann gleich Gamma-Korrektur dabei ist...

Zitat von michuNeo

ich hatte das gleiche problem mit meinem rainbowduino (12bit) und den code inkl. tabelle habe ich hier:

Der sieht aber komisch aus: die Werte gehen ja auch nur von 0 bis 255.. - müssten ja eher eben bis 4.095 gehen bei 12 Bit Ausgabe... klar, man kann diese Werte dann natürlich x16 nehmen, aber da verschenkt man ja wieder Auflösung, weil z.B. da am Anfang, wo alles auf 1 gerundet ist, gäbe es bei ner echten 12-Bit-Tabelle auch schon unterschiedliche Zielwerte...

ich werde nun mal zum Spaß die in dem anderen Thread verlinkte Tabelle aus dem Mikrocontroller.net nehmen, die war mir damals "zu dunkel", aber es macht auch nen Unterschied, ob man nun was beleuchtet, oder wie hier in die LEDs rein schaut, da darf 50% (von meinem Empfinden her) schon noch dunkler sein, damit es auch wirklich "halbe Helligkeit" ist...

da wäre übrigens auch ne Tabelle für 16 Bit drin, und eine für 10 Bit, aber leider keine für 12 Bit...

Zitat von michuNeo

sprich der ws2801 hat KEINE gamma korrektur onboard?

Nein, so wie die meisten dieser Treiber... da gibt man einfach den PWM-Wert rein...

ideal wäre hier ja sowas wie der MYxxx mit 12 oder 16 Bit Auflösung, weil da könnte man dann die 8 Bit Input ohne Stufen/Auflösung zu verlieren in der SW Gamma-korrigieren... müsste dann natürlich aber auch bis zur doppelten Datenmenge an die Pixel raus schieben...

Zitat von michuNeo

hmm du bist sicher das du die letzte version verwendest?

Ja, ich habe dann extra noch mal runtergeladen... ist der Link evtl. falsch..? - ich probier's dann noch mal... irgendwie haben die letzten 3 Versionen alle 1.0.3 geheissen...?

Ich probier's dann nachher noch mal aus...

Ja, nun heisst's auch 1.0.3.2, und der Geeky Stuff ist drin

für die Mitleser: Nun auch mit Balken, der anzeigt was raus geht - und bei dem Blinkenmovie wird wohl sogar der aktuelle Frame angezeigt

Weitere freudige Nachricht: Der kann den FT232-VCP mit 250k öffnen (sollte sogar 500k gehen, mal ausprobieren, im Terminal geht's jedenfalls), eine Umsetzung von mini-DMX auf WS2801/TM1804 ist also ganz normal mit meiner SW auf dem SEDU-Board zu machen, ohne extra Baudratenquarz auflöten zu müssen!

ich habe noch nicht ausprobiert, wie groß man die Matrix im Pixelcontroller maximal einstellen kann, aber evtl. geht dann mit 500k und "Modus B1" (= 1.536 Byte Nutzdaten) sogar ne Matrix mit 32x16...

wegen der Gamma-Tabelle: Das ist wieder die Begriffsverwirrung, Du meinst 12 Bit *insgesamt*, ich *pro Farbe* - klar, der Rainbowduino hat ja nur 3x 4 Bit Farbtiefe, deswegen auch diese grob abgestufte Tabelle, wo letztlich nur 16 versch. Werte raus kommen:

0,      0,      0,      0,      0,      0,      0,      0,
                0,      0,      0,      0,      0,      0,      0,      0,
                0,      0,      0,      0,      0,      0,      0,      0,
                0,      0,      0,      0,      0,      0,      0,      0,
                0,      0,      0,      0,      0,      0,      0,      0,
                0,      0,      0,      0,      16,     16,     16,     16,
                16,     16,     16,     16,     16,     16,     16,     16, 
                16,     16,     16,     16,     16,     16,     16,     16, 
                16,     16,     16,     16,     16,     16,     16,     16,
                16,     16,     16,     16,     16,     16,     16,     16,
                32,     32,     32,     32,     32,     32,     32,     32, 
                32,     32,     32,     32,     32,     32,     32,     32, 
                32,     32,     32,     32,     32,     32,     32,     32, 
                32,     32,     32,     32,     32,     32,     32,     32, 
                32,     32,     32,     32,     48,     48,     48,     48, 
                48,     48,     48,     48,     48,     48,     48,     48, 
                48,     48,     48,     48,     48,     48,     48,     48, 
                48,     48,     48,     48,     64,     64,     64,     64, 
                64,     64,     64,     64,     64,     64,     64,     64, 
                64,     64,     64,     64,     64,     64,     64,     64, 
                64,     64,     64,     64,     64,     64,     64,     64, 
                80,     80,     80,     80,     80,     80,     80,     80, 
                80,     80,     80,     80,     80,     80,     80,     80, 
                96,     96,     96,     96,     96,     96,     96,     96, 
                96,     96,     96,     96,     96,     96,     96,     96, 
                112,    112,    112,    112,    112,    112,    112,    112, 
                128,    128,    128,    128,    128,    128,    128,    128, 
                144,    144,    144,    144,    144,    144,    144,    144, 
                160,    160,    160,    160,    160,    160,    160,    160, 
                176,    176,    176,    176,    176,    176,    176,    176, 
                192,    192,    192,    192,    192,    192,    192,    192, 
                208,    208,    208,    208,    224,    224,    224,    224, 
                240,    240,    240,    240,    240,    255,    255,    255

bei mir sind's dann eben aktuell 197 Werte pro Farbe, also *insg.* 7.645.373 Farben im Vergleich zu den 4.096 Farben des Rainbowduino bzw. 32.768 der LPD6803-Pixel...

ich meine das so, "8 Bit auf 12 Bit" heisst bei mir pro Kanal, also ich habe 8 Bit Werte rein (256 Stück), und suche mir zu jedem einen Wert aus einer Menge von 4.096 möglichen PWM (Ausgabe) Werten... jeweils für R, G und B

ja, und mit 500 k geht es sogar auch!

und man kann die Matrix sogar auf 32x32 stellen

(da braucht man aber schon ne deutlich leistungsfähigere Kiste als meine )

Notiz an mich selbst: ich baue die Modi B1 und B2 (1.536 bzw. 3.072) also auch noch ein in meine Umsetzer-SW... muss dann aber die Output-Routine auch noch anpassen, die kann i.M. max. 256 Pixel ansteuern - mal sehen, ob sie 1.024 an einem Strang auch noch mit vernünftiger Framerate packt...

ich habe ein Mic am Rechner, und die Kick/Snare/Hihat-Dinger haben auch geblinkert - habe nur nicht gleich den Zusammenhang gecheckt...

was mir noch aufgefallen ist: Bei ner größeren Matrix wird der Debug-Buffer auch größer - bei meiner 20x10 passt er dann nicht mehr auf den Monitor (1.440x1.050):

ginge das, das so zu machen, dass der so klein bleibt wie im Post weiter oben..? - also, klar, bei 20x10 ist es ja ein anderes Seitenverhältnis, aber dass er dann in dem Fall halt weniger hoch wird, statt insgesamt größer...?

die Größe wie oben reicht ja zum sehen was da passiert, und evtl. rechnet das dann auch schneller, wenn die Auflösung nicht so hoch ist...?

Super, funktioniert, vielen Dank! - ist immer schön, wenn man was gutes noch besser machen kann....

ich stehe halt auf "aufgeräumtes Layout", und das ist so easy machbar:

es ist übrigens tatsächlich so, dass das Ganze bei mir flüssiger läuft, wenn das debug window kleiner ist - klar, müssen ja weniger Pixel gezeichnet werden...?

ansonsten habe ich mal Ausgabe (und Empfang bei mir natürlich) mit 1 Mbit/s probiert - funktioniert einwandfrei... so alle 10-15 sek. wird mal ein nicht empfangener Ack angezeigt...

da laufen die Animationen dann aber seltsamer Weise (also auch am Bildschirm schon) wieder ein bisschen weniger flüssig - anscheinend beansprucht das Daten senden den (meinen) Rechner doch mehr als gedacht...?

interessant für mich war jedenfalls, bei 1 Mbit/s habe ich ja nur noch 160 Takte zwischen 2 empfangenen Bytes, das reicht aber für gamma-Korrektur und umsortieren und dass dann noch genug für die Ausgabe übrig ist...

ob's bei 1.024 Pixel raus schicken dann auch noch schnell genug ist, k.A, muss ich ausprobieren - die Ausgaberoutine könnte man noch schneller machen, wenn man die Kompatibilität zu TM1804 weg lässt, bei dem wird ja 0 und 1 durch versch. lange Pulse kodiert, im Durchschnitt 10 Takte, ohne die TM1804-Ausgabe wäre der SW-SPI noch mal gut 4x schneller

dazu übrigens noch, das mit den 512 bzw. 1.024 Pixeln geht auf nem "normalen" SEDU dann natürlich nicht, da der ja "nur" 1k RAM hat - das läuft dann auf der Version mit Mega644 (4k RAM)...

Ich habe heute mal eine 10x10 Pixel Matrix aus den 50x50mm Pixeln zusammen gesteckt und mit dem PixelConverter getestet (250kBaud). Das hat sofort ohne Probleme funktioniert. Ich bin begeistert. Ein Video dazu wird es in Kürze geben.

Eins habe ich nicht hinbekommen: die Farb-Reihenfolge der Pixel passt nicht. Dadurch sieht die Feuer-Simulation natürlich Sch... aus. In der Config-Datei gibt es eigentlich einen Punkt, um das einzustellen. Leider ist es mir nicht gelungen, die richtigen Farben hinzubekommen. Was muss denn da konkret eingestellt werden? Es sind ja zwei Parameter mit Komma getrennt.

Ansonsten fehlt mir sicher noch einiges Wissen in der Bedienung und Konfiguration. Aber das Tool macht schon Spaß. Ach ja, wie erzeugt man eigentlich eigene Effekte?

Ich hatte ja vor, ne kleine Bedienungsanleitung hier rein zu stellen, mache ich dann bei Gelegenheit noch...

wie meinst Du das mit "eigenen Effekten"...?

Das Ding ist ja modular aufgebaut, die Effekte wie Plasma etc. werden jeweils durch ein Stück SW erzeugt, da kann man auch eigene Module schreiben und einbinden - wenn man's kann (Java)

relativ leicht geht das mit diesen Blinkenlight-Dingern, da sind ja schon ein paar Animationen im Ordner "Data/Blinken" - diese .bml-Dateien... solche kann man mit nem Editor erstellen, leider aber nur in Schwarz/weiß, mit der Tint-Funktion kann man die dann zumindest einfärben...

Die Farben für die LEDs kannst Du übrigens auch in der SW auf dem SEDU tauschen, in der Datei "settings.inc":

.equ RGB_ORDER			= 0		; RGB-Reihenfolge:
						; 0 = nicht tauschen
						; 1 = tauschen RGB -> GRB
						; 2 = tauschen RGB -> RBG
						; 3 = tauschen RGB -> BGR
						; 4 = tauschen RGB -> BRG
						; 5 = tauschen RGB -> GBR

ja, krass! - es gibt tatsächlich Menschen, die zu solcher Musik noch grobmotorischer und weniger im Takt rumhampeln als ich!

Nicht falsch verstehen! - ich mag' solche Musik, deswegen hampel ich eben auch dazu rum...

Und ich hoffe, dass Du nicht einer der DJs bist, und ich somit in's Fettnäpfchen getreten bin...

Achja: Das macht sich echt gut, die Panels vor dem Tisch!

EDIT: Du bist also wieder aus dem Urlaub zurück...? - habe heute die "Überraschung" zur Post gebracht, sollte dann Montag oder so ankommen...

Also ich finde die SW super wie sie ist - und ich will ja hier keine übetriebenen Ansprüche stellen

was noch schön wäre:

Evtl. doch das Umsortieren für auf versch. Arten anders verkabelte Matrixen gleich bei Dir in der SW - hätte den Vorteil, dass man auch mit dem "normalen" SEDU größere Matrixen betreiben könnte, weil dann muss ich die Bytes nicht mehr umsortieren, sondern kann sie gleich wie sie rein kommen weiter schicken, also kein RAM nötig, also auch 1.024 Pixel mit dem Mega16 möglich.

Das geht ja deswegen, weil zwischen den Frames immer ne Pause ist, die 1 ms Wartezeit für die WS2801 ist da also quasi "automatisch" mit dabei... - muss ich noch mal durchrechnen, je nach Framegröße und Baudrate...

bei 3.075 Byte über 1 Mbit/s z.B. braucht ein Frame vom Rechner zum SEDU ca. (wenn nix "hakelt") 30,75 ms - dazu muss dann 1 ms Pause, sagen wir mal insg. 32 ms für den Frame, wären also noch 31,5 fps - wenn Deine SW mit max. 25 fps ausgibt sollte das auch mit gelegentlichen Verzögerungen kein Problem sein...

Mehr Effekte wären halt auch noch schön, aber wie gesagt, die müsste man ja alle einzeln programmieren...

ich muss mir das eh' alles noch mal genauer in Ruhe ansehen, ich kenne und kann ja noch nicht alle Möglichkeiten, die das Teil bietet, z.B. habe ich noch so ein Drumpad, da könnte ich mal schauen wie ich das alles damit per Midi steuern kann, und ob ich das schnalle, wie man in Processing programmierte Effekte da integrieren kann...

auch mit der Soundsteuerung muss ich noch mal gucken, habe das noch nicht so ganz kapiert - z.B. wäre es cool, wenn bei dieser "Drops"-Animation eben z.B. bei jedem Bassschlag ne Reihe Tropfen kommen würden, das geht ja bestimmt auch irgendwie einzustellen, oder..?

klar, ne Videograb-Funktion wäre auch super, da könnte man das dann ganz easy erweitern, indem man einfach andere Animationen "abfilmt" - aber das geht ja in Java nicht so einfach, das darf ja nicht auf den Bildschirmspeicher zugreifen..? (oder war das Flash..?)