Hallo!
Ich habe bei Youtube folgendes Video entdeckt:
http://www.youtube.com/watch?v=_9LWfa2Kt7o&NR=1
Wollte schon immer wissen wie man so "Plasma" programmiert. Vor ein paar
Jahren hatte ich mal ein Assembler Sourcecode für 80x86 der solche
Grafiken erzeugen konnte. Hat jemand von euch sowas oder ähliches
programmiert und kann erklären wie es geht?
Viele Grüße
CHRiS
Also das sieht mir eigentlich nach der ganz einfachen Variante aus. Hier
wird einfach nur eine Farbpalette entsprechend berechnet das man sie
durchschieben kann. Danach erstellt man das Startbild, welches
normalesweise mit Hilfe einer Sinus-Funktion die einzelnen Farben schön
aneinander reiht. Danach wird die Palette nur noch durchrotiert. Ist ein
einfacher aber ganz netter Effekt.
Hier gibts ein Tutorial zu dem Thema:
http://student.kuleuven.be/~m0216922/CG/plasma.html
Michael G. wrote:
> So einfach wie sich das nach Nico anhoert isses auch nicht... vor allem> bei so nem Display in Verbindung mit nem AVR.
Kommt darauf an, das Plasma selbst kann man vorher berechnen, das ist
nicht zwingend von der benutzen Palette abhängig, nur von der Struktur
der Palette. Solange man auf dem Display die Palette direkt manipulieren
kann ist der Rest einfach. Ansonsten ist nur die Frage ob man die Daten
schnell genug zum Display kriegt, man die Palette also auf dem AVR
selbst hat.
So ganz einfach ist das Plasmademo dann aber doch nicht. Schaut man
sich das Video an, so sieht man einen Phasenverlauf, d.h. die
Sinus/Cosinus-Landschaft wandert nach schräg oben. Mit einfacher
Farbtabelle ist das nicht zu machen. Wie in alten C64-Demos wird
hier wahrscheinlich mit Sin/Cos-Tabellen gearbeitet. Der AVR dürfte
für die Pixelberechnung sicherlich schnell genug sein (be 16MHz
mindestens 16 mal schneller als ein C64!)
Gruss
Jörg
Danke schon einmal für die vielen Antworten.
Ich würde erstmal versuchen das ganze auf einem PC zu realisieren bevor
ich mich an einen Controller wagen würde - aber jetzt erstmal das
Tutorial durchlesen :)
Es geht mit Farbtabellen, selber schon gemacht. Ist aber schon recht
lang her (außerhalb von Dos macht es keinen Sinn an der Farbtabelle
herumzuspielen).
>>Es geht mit Farbtabellen, selber schon gemacht. Ist aber schon recht>>lang her (außerhalb von Dos macht es keinen Sinn an der Farbtabelle>>herumzuspielen).
Könntest du mir den Quelltext zur Verfügung stellen - zur Orientierung?
aliendrummer wrote:
>>>Es geht mit Farbtabellen, selber schon gemacht. Ist aber schon recht>>>lang her (außerhalb von Dos macht es keinen Sinn an der Farbtabelle>>>herumzuspielen).>> Könntest du mir den Quelltext zur Verfügung stellen - zur Orientierung?
Das funktioniert bei den heutigen Displays und Displaycontrollern
gewöhnlich nicht, da nicht mehr bzw. sehr selten mit Farbpaletten
gearbeitet wird.
Bleiben eigentlich nur zwei Varianten:
1. In Echtzeit alles berechnen und darstellen
2. Passende, aneinanderreihbare Blöcke vorberechnen und zum Display
schieben
Arc Net wrote:
> Das funktioniert bei den heutigen Displays und Displaycontrollern> gewöhnlich nicht, da nicht mehr bzw. sehr selten mit Farbpaletten> gearbeitet wird.> Bleiben eigentlich nur zwei Varianten:> 1. In Echtzeit alles berechnen und darstellen
Wenn man intern mit Paletten arbeitet ist hier aber auch nur die
Anbindung an das Display das "Problem".
Nico Erfurth wrote:
> Arc Net wrote:>>> Das funktioniert bei den heutigen Displays und Displaycontrollern>> gewöhnlich nicht, da nicht mehr bzw. sehr selten mit Farbpaletten>> gearbeitet wird.>> Bleiben eigentlich nur zwei Varianten:>> 1. In Echtzeit alles berechnen und darstellen>> Wenn man intern mit Paletten arbeitet ist hier aber auch nur die> Anbindung an das Display das "Problem".
Wäre dann eine Art Kombination von 1. und 2.:
Fertige Blöcke im Controller, Palette rotieren, Block pixelweise
auslesen, Farbe aus Palette holen, zum Display schieben.
Hihi. Also leute.. das Video is von mir :-D
Das Video wurde von nem Kumpel online gestellt, mit dem ich manchmal
chatte.. ich konnte das video einfach nicht uploaden und auch sein
versuch war beim ersten mal kläglich gescheitert (Video war zwar oben,
lief aber viel zu schnell) Er arbeitet auch mit AVR32, aber UC3A.
Die Demo hatte ich entwickelt um unsere Rechenleistung und den
Display-Datendurchsatz zu vergleichen.
Ich kann den Effekt gerne online stellen... müsste mal schauen, obs den
Code noch gibt.. war eigentlich nur ne dumme spielerei :-D
Ist ein wenig mehr als nur eine durchrotierte Sinusfunktion. Vorallem,
was die optimierung angeht.. das Bild is jeden Frame live berechnet..
ich hab ja fast keinen Speicher ;-)
Das ist ein AVR32 UC3B mit 32k Ram. Das Display habe ich mit 8bit
parallel Interface angeschlossen. Die Demo läuft im 16-bit Modus.
Ausgebremst wird das ganze durch die GPIOs die verdammt lange brauchen.
(6 takte pro Änderung dank Rev.B) Mein Kollege ausm ICQ hatte ein
SPI-Dispay und der schaffte deutlich mehr FPS durch DMA.
Mit Linux is hier gar nix am start :-/. Quark.
Das Ganze arbeitet aber tatsächlich mit einer Sinustabelle. Diese hatte
ich zur Verfügung, weil ich eigentlich einen DAC-Sinus-test
implementiert haben wollte ;-) Zusätzlich gibt es pro Durchlauf einen X
und y versatz, wobei y verzerrt wird. Außerdem wird noch eine weitere
Variable hochgezählt, die langsam die farben durchrolen lässt.
Dann wird mit hilfe diesen Wertes in die Sinustabelle geschaut.
Den Sinus konnte ich dann dan nochmal mit sich selbst oder beliebig
verwursteln... naja.
Fakt ist, dass zum Schluss das Ergebnis aus dem Sinus zum interpolieren
der Farben genutzt wird. 0 bis 0.33 is eine farbe usw ;-) und dann
blendet das immer langsam über.
Das ganze Interpolieren läuft in Fixkomma 32bit oder 16bit.
Da das ganze recht rechenintensiv ist und die GPIOs bremsen habe ich pro
Frame nur jede zweite Zeile gefüllt. Somit ist der Bildaufbau insgesamt
fließender. Das war aber fürs Video aber egal :-D
Naja beim Overclocking test war der UC3A besser als mein UC3B. Ich
schaffte die Demo bis 78Mhz stabil 84Mhz ausm Kühlschank. Der UC3A
konnte konstant 96Mhz wenn ich mich recht entsinne. Meine 90Mhz hier war
ein Glück, das kurzzeitig funktionierte. Nach änderung des Codes war es
dahin mit der Funktionstüchtigkeit :-(
Aber das kann man ja auch nicht erwarten, wenn man außerhalb der Specs
arbeitet. hehe.
Das Ganze is übrigens ein Testboard für meinen Mp3-Player gewesen. Auf
dem hab ich ein wenig die Grundsätzlichen Sachen etwichelt.
Daraus geworden ist:
www.der-albi.de/bunt.jpg
Die Hardware habe ich jetzt komplett überarbeitet.. eine neue Version
kommt mit Touchscreen und insgesamt größerem Display :-)
MFG
Achso.. wer fragen hat.. gerne stellen ;-)
Albi
UND nochmas :-D
Schaut mal das Video an und macht mal ein wenig lauter. Im
hintergrundläuft Placebo und ich Pfeife einmal ziemlich peinlich mit :-F
Ist mal was zum schmunzeln.. hehe rotwerd
Und das "A O" in dne letzen Sekunden is vom ICQ.. die Message war vom
UC3Aler, ich solle das Video schicken ;-)
Hallo (der) Albi,
kannst du ein wenig mehr über das Display sagen, falls möglich (z.B.
Marke,Preis)?
Ich habe ein wenig Erfahrung mit einem Text-LCD (2-zeilig, inklusive
Std.TreiberChip). Der Chip hat einen internen Font- und Char-Buffer,
der per SPI gelesen und beschrieben werden kann. Die Möglichkeiten sind
also schnell ausgereizt, schaue mich also schon mal nach einem
Graphikdisplay (mögl. mit Farbe) um, habe auch schon an OLED gedacht.
Ist dein Display mit internem Buffer ausgestattet, evtl. mit
Lesezugriff, Oder werden die Pixel in Realzeit vom AVR berechnet?
Und wie sieht es mit der winkelabh. Lesbarkeit aus?
Gruss
Jörg
>>Ich kann den Effekt gerne online stellen... müsste mal schauen, obs den>>Code noch gibt.. war eigentlich nur ne dumme spielerei :-D>>Ist ein wenig mehr als nur eine durchrotierte Sinusfunktion. Vorallem,>>was die optimierung angeht.. das Bild is jeden Frame live berechnet..>>ich hab ja fast keinen Speicher ;-)
das wäre sehr nett. ich hab vor einigen jahren schon versucht sowas hin
zu bekommen.... aber das war zu realschul zeiten....
ein wenig source zum rumspielen wäre echt gut!
Also zum Display: Das Ding hab ich aus China direkt aus ner
Herstellerfirma. Eigentlich ist da kein rankommen für den Privatmann..
außer man gibt sich für mehr aus, als man ist ;-)
Die Firma scheint das Display aber nicht mehr im Sortiment zu haben...
http://www.yaoyu-lcm.com/english/Products_03.asp
Es sollte eigentlich ein YM200T-002A sein. Datenblätter hätte ich da..
aber das interessiert wahrscheinlich nicht ohne Hardware ;-)
Das Display hat intern einen Bildspeicher den man schreiben und lesen
kann. Ich habe immer auf das auslesen verzichtet - das ist zwecklos,
weil grottenlahm.
In meiner Demo wird jeder Pixel aufs Neue live berechnet und in den
Bildspeicher geschrieben. Aber wie gesagt: immer nur jede zweite Zeile.
Was den Code angeht: leider habe ich ihn nicht mehr :-( Ich hätte nie
gedacht das sich jemand für den Schmodder interessiert ;-)
Kern ist wirklich dass man aus dem Zahlenwerten [0.0..1.0] eine Farbe
errechnet. Das ist simples interpolieren ala
"Wenn Wert zwischen 0 und 0.33, belnde rot ein und grün aus."
"Wenn Wert zwischen 0.33 und 0.66, belnde rot aus und blau ein."
usw. man kann auch die farbgrenzen enger setzten und erhält damit mehr
interpolationsmöglichkeiten.
Den Wert mit Hilfe einer Sinusfunktion ortsabhängig zu machen ist nicht
weiter schwer. Das ganze zu verzerren usw ist dann die Krativität des
Programmierers. Ich weiß noch, dass dieses Muster eigentlich ungewollt
entstanden ist. Einfach irgendwas mit den Sinüssen anstellen und es wird
bunt :-) Fertig. hehe.
Mein Code wäre aber für die PC-Programmierung herzlich ungeeignet und
sicherlich auch nicht sonderlich toll verständlich. Im PC verwendet man
für sowas einen FrameBuffer den man auf dem Monitor ausgibt.. und man
kann mit floats arbeiten. Das ist insgesamt viel sinnvoller als ein
AVR32 UC3B.
MFG
Kleiner Plasma-Test in C# (ab Net Framework 2.0)
Der Code verwendet intern eine Bitmap im RGB555-Pixelformat, um ein LCD
zu "simulieren".
Bis auf das Erzeugen der Cos-Tabelle werden nur Integer verwendet.
Hi at all!!!
Ich misch mich dann auch mal ein. Bin der typ der das video hochgeladen
hat. Und das andere video mit dem raumschiff ist von meinem board.
Hab hier erstmal den code für euch von der Farbanimation.
Habe ihn selber für mein board in gut 10min überarbeitet, wie Der Albi
schon gesagt hatte. Dabei habe ich ein Siemens S65 Display in verbindung
mit UC3A benutzt.
Bessere Voreinstellungen + ein Regler mehr zum Spielen...
Aufs wesentliche reduziert sieht das ganze etwa so aus:
(draw müsste z.B. für SPI-Displays entsprechend angepasst werden)
solange da ein math.cos drinne steckt ist das weder aufs wesentliche
reduziert noch SPI-Display fähig, da es dafür auf einen µC laufen muss
;-)
Dafür bräuchte man wirklich mal ne sinnvolle und schnelle lösung. Auch
meine tabelle is eher mist. Viel zu aufwendig sowas. Auch wenn ich für
deren generierung ein programm geschrieben habe...
Der Albi wrote:
> solange da ein math.cos drinne steckt ist das weder aufs wesentliche> reduziert noch SPI-Display fähig, da es dafür auf einen µC laufen muss> ;-)>> Dafür bräuchte man wirklich mal ne sinnvolle und schnelle lösung. Auch> meine tabelle is eher mist. Viel zu aufwendig sowas. Auch wenn ich für> deren generierung ein programm geschrieben habe...
Irgendwie hatte ich so eine ähnliche Antwort erwartet...
1. Auf viel weniger kann man's eigentlich nicht reduzieren, wenn man das
Prinzip zeigen will: Initialisierung der nötigen Tabellen und eine
einfache Zeichenroutine
2. Die Cosinus-Tabelle hat gerade einmal 240 Einträge (480 Bytes) und
wird beim Programmstart berechnet, ob die Generierung der Tabelle mit
allen Funktionen in 480 Bytes passt, eher nicht (oder doch?)
3. Sinus/Cosinus-Tabellen kann man auch ohne math.h berechnen,
insbesondere wenn - wie hier - keine hohe Genauigkeit gefordert ist
(Stichworte: harmonische Schwingung oder Einheitskreis)
4. Die Farbtabelle hat 256 Einträge (512 Bytes)
5. "SPI-Display fähig"
statt lcd[x + y * rtData.Width] = ...
nimmt man eben
lcdBuffer[x] = ...
und schiebt die Daten ausserhalb der x-Schleife zum Display
6. Die ganzen % kann man auch wegoptimieren
7. Eigentlich ging's aliendrummer wohl um die generelle Vorgehensweise
und nicht um handoptimierten Assemblercode
Hey hey.. das war doch kein Angriff... ;-) Ich hab das schon erkannt, wo
und wie oft du den Cosinus benutzt usw..
Mich stört bloß die Benutzung selbst auch manchmal und wollt nur mal in
die Runde werfen, obs denn ne halbwegs gute Alternative zur LUT gibt...
..schon alleine das einbindes von floats braucht nicht nur
Flash-Programmspeicher, sondern auch erstaunlicher weiße mehr ram.
Zumindest beim AVR32.. wo anders habe ichs nicht probiert...
Es wäre cool, wenn du mal ein Bild von deinem Output postest.. ich hab
zwar ein C# hier.. aber keine ahnung, wie das geht.. bin dumm ;-)
MFG
Der Albi wrote:
> Hey hey.. das war doch kein Angriff... ;-)
Bei dem ..., ... Wetter hier...
> Ich hab das schon erkannt, wo> und wie oft du den Cosinus benutzt usw..> Mich stört bloß die Benutzung selbst auch manchmal und wollt nur mal in> die Runde werfen, obs denn ne halbwegs gute Alternative zur LUT gibt...> ..schon alleine das einbindes von floats braucht nicht nur> Flash-Programmspeicher, sondern auch erstaunlicher weiße mehr ram.> Zumindest beim AVR32.. wo anders habe ichs nicht probiert...>> Es wäre cool, wenn du mal ein Bild von deinem Output postest.. ich hab> zwar ein C# hier.. aber keine ahnung, wie das geht.. bin dumm ;-)>> MFG
p.s. in dem Zip ist ein auch Unterorder bin\release mit der Exe
p.p.s. das Gif ist von 240x320 auf 120x160 herunterskaliert
p.p.p.s. sollte das Gif nicht laufen, gibt's auch noch ein PNG
Den Code hab ich leider nicht mehr, das Ding lief übrigens sogar unter
QBasic flüssig (wegen Farbtabelle). Waren nur etwas über 100 Zeilen.
Hat das Bild dabei anfangs per Zufall erzeugt, also ganz ohne Vorgaben
gearbeitet.
Auf die schnelle per Google:
http://www.tek-tips.com/viewthread.cfm?qid=709175&page=8
Wahrscheinlich ist das unter Basicern so beliebt, weil eine der ganz
wenigen Sachen die damit flüssig laufen ;)