Inwiefern aussieht? Kann dir gerade nicht folgen. Die Farben werden einfach nur hintereinander weg, mit einem kleinen Header davor, an das Arduino Nano übertragen, das kümmert sich dann um die RGB Stripe Ansteuerung.
Eine fertige Routine hab ich da nicht wirklich, ich hab mir nur ein Testprogramm geschrieben, dass ein Bild auf der Platte nutzt, ein paar Bereiche außen rum als LED Quellen nutzt, um dann rum zu probieren wie die einzelnen Farben raus kommen, je nach dem wie ich diese berechnen lasse. Allerdings lasse ich mir die Ergebnisse in einem Fenster anzeigen, nicht auf den LEDs.
Intern arbeite ich da mit einem lediglich 120x90 Pixel großen Bild, das dann erst in die LED Bereiche "zerlegt" wird, das sind genug Pixel um damit etwas anfangen zu können. Ich denke aber ich mach die interne Auflösung später von der Anzahl der LEDs abhängig, wäre sinnvoller. Mein Setup hat z.B. Oben 39 LEDs, für oben reicht in der Breite 1 Pixel (aber verkleinert mit Smooth Filter, nicht mit RAW), wichtiger sind die Pixel die in das Bild hinein gehen, die brauche ich zum berechnen.
Wobei ich mir hier gedacht habe, dass je weiter sie hinein ragen, desto weniger werden die Farben mit eingerechnet. So das eben die LEDs auch noch etwas reagieren, wenn z.B. eine Explosion nicht bis zum ganz äußerten Rand reichen. Auch sollte dadurch bei einer Explosion, die sich ja erst zum Bildrand ausbreitet, die LEDs nicht so ruckartig anspringen, weil im einen Frame war sie noch außerhalb des Frames und im nächsten im inneren... zack von dunkel schlagartig auf hellem Farbton. Standard ist ja den Bereich für eine LED einfach mit Smooth auf 1x1 Pixel zu verkleinern, dadurch erhälst du praktisch den Farbdurchschnitt des Bereichs, was oft nicht gerade die besten Ergebnisse liefert.
Zu aufwendig darf die Berechnung natürlich auch nicht sein, sonst dauert die Berechnung zu lange.
Edit: -----------------------------------------
Bin ich doch noch über eine Idee gestolpert, die ganz gut aussieht (zusammen kopiert, rein zum Funktionsverständnis).
Code: Alles auswählen
*buf2 = AllocateMemory(Width*Height*4)
CreateImage(0,Width,Height,32)
StartDrawing(ImageOutput(0))
*buf2 = DrawingBuffer()
Get_Frame_Bytes(*dxgi_manager, @buf_size, @*buf)
CopyMemory(*buf,*buf2,buf_size)
StopDrawing()
Hatte erst versucht Get_Frame_Bytes() direkt in den DrawingBuffer() schreiben zu lassen, aber das schein wohl nicht zu gehen, kriege ich bloß ein schwarzes Bild raus. Oder geht das doch irgendwie?
So klappt es aber, auch wenn das Bild auf dem Kopf steht (vertikal gespiegelt), was aber für die Weiterverarbeitung völlig egal ist, zumindest in meinem Fall, da das Bild ja nicht zum anzeigen gedacht ist. Ich hatte eigentlich mit falschen Farben gerechnet, weil ich BGRA statt RGBA von der DLL zurück kriege, aber auch das wäre egal gewesen. ^^
Wenn ich so in Schleife aufnehme, komme ich bei nem Spiel, dass mit 30 FPS läuft und somit die Grafikkarte nicht auslastet, auf 27 bis 30ms, wovon ~2-3ms das kopieren der Daten von einem Buffer zum anderen ist und nochmal ~1-3ms das verkleinern des Bildes auf 120x90 Pixel, allerdings mit RAW, mit Smooth schießt der Wert gleich hoch auf über 100ms.
Sind doch recht gute Werte, das abrufen des Bildes über die DLL dann noch in einen extra Thread packen und es ist noch genug Puffer die Daten zu verarbeiten ehe das nächste Bild vorliegt. Im Schnitt gehen jetzt ca. 4-6ms für CopyMemory() und ResizeImage() drauf, bleiben noch ca. 27ms für die Verarbeitung (max. 33ms um 30FPS nicht zu unterschreiten). Das ist doch etwas Spielraum.
Mal sehen wie viel ms drauf gehen jedes einzelne LED zu berechnen, ich hab insgesamt 115 Stück, da kann sich also schnell was aufsummieren.