Gesamte Bildschirm mit einer Pixelfarbe Füllen - schnell
-
was hat denn das für einen Sinn? Du schreibst mehrmals auf einen einzelnen uchar. Und am Ende würde das den Array überschreiten.
-
@randa: ich schreibe doch nicht nur auf einen einzelnen uchar sondern bewege mich doch im Array weiter
Den Array überschreitet es doch nicht wegen curpix<pixelnum
@H.L.T.O: du hast recht. Habe ich auch schon ausprobiert. Habe mit Blt einen einzelnen Pixel auf den ganzen Bildschirm skaliert und es ist wirklich schneller !!???? Versteh ich aber nicht ganz denn Blt kann doch nicht soooo viel schneller sein als direkt in die Pixeldaten schreiben... Blt muss doch schließlich auch auf die Pixel zugreifenWeiß vielleicht jemand warum ???
-
@H.L.T.O: du hast recht. Habe ich auch schon ausprobiert. Habe mit Blt einen einzelnen Pixel auf den ganzen Bildschirm skaliert und es ist wirklich schneller !!???? Versteh ich aber nicht ganz denn Blt kann doch nicht soooo viel schneller sein als direkt in die Pixeldaten schreiben... Blt muss doch schließlich auch auf die Pixel zugreifen
blit ist unheimlich optimiert
-
@otze: Kommt mir auch so vor das Blit unheimlich optimiert...
Aber leider muss ich auch sagen dass mir auch Blt noch zu langsam ist um einen Farbübergang des gesamten Bildschirms von Schwarz auf weiß fließend - ohne Striche - zu schaffen wenn ich ein Bitmap anlege in dem die einzelnen Pixel von RGB(0,0,0) auf RGB(255,255,255) von links nach rechts ansteigen und ich dann die einzelnen Pixel von links nach rechts mit Blt auf den ganze Bildschirm strecke. Liegt es vielleicht daran dass Blt viel Rechenzeit braucht um einen einzelnen Pixel auf den ganzen Bildschirm zu strecken.
Eine Funktion wie void FillScreen(RGB rgb) wär n TRAUM...
-
problem ist wahrscheinlich, dass ein direktzugriff auf den videobuffer eine große Sünde ist, der videobuffer ist nicht für den direktzugriff designed, und somit sind die treiber der graka darauf nicht einmal annähernd ausgelegt.
teste mal 2 dinge:
1.eine normale textur mit den maßen deiner auflösung mit dem farbübergang belegen,
und dann mittels blit in einem durchgang kopieren.das müsste eigentlich schneller sein
2. eine normale textur mit den maßen deiner auflösung mit dem farbübergang belegen, und dieses dann mittels transformierten vertices auf den screen bringen(dh ein großes 4eck,mit den vertices 0/0 bildschirmbreite/0, 0/bildschirmhöhe, bildschirmbreite/bildschirmhöhe, und die vertices haben als FVF den flag dass sie ebreits transformeirt sind).
das müsste eigentlich verdammt schnell sein
-
er will also den ganzen bildschirm gelb oder blau haben?
wieso macht er dann nicht direct3d->Clear(..., ...., ...., Farbe)
-
er will einen Farbübergang
-
dali schrieb:
Aber leider muss ich auch sagen dass mir auch Blt noch zu langsam ist um einen Farbübergang des gesamten Bildschirms von Schwarz auf weiß fließend - ohne Striche - zu schaffen wenn ich ein Bitmap anlege in dem die einzelnen Pixel von RGB(0,0,0) auf RGB(255,255,255) von links nach rechts ansteigen und ich dann die einzelnen Pixel von links nach rechts mit Blt auf den ganze Bildschirm strecke.
Strecke vorher.
Bye, TGGC (Der Held bei Dir!)
-
Naja bin draufgekommen warum es diese Striche gegeben hat.
Peinlichpeinlich.
Es hatte nichts mit dem zu tun dass die Operationen jeden Pixel einzeln zu setzen zu langsam wären noch das Blt für das Strecken eines Pixels auf Bildschirmgröße länger brauchen würde.
Das Problem war dass ich direkt in das PrimarySurface / Bildschirm geschrieben habe...Aber man kann auch daraus lernen. Blt ist schneller als Pixel einzeln setzen denn es gab deutlich weniger Striche. Obwohl das hätte glaub ich jeder hier vorher auch schon gewußt
@otze: trotzdem danke für die Mühe.
@devent: ich wollte nen farbübergang
@tggc: striche entstanden eben nicht durch strecken.
-
dali schrieb:
@randa: ich schreibe doch nicht nur auf einen einzelnen uchar sondern bewege mich doch im Array weiter
Den Array überschreitet es doch nicht wegen curpix<pixelnum ?Achso, ich hab verstanden das dein Buffer 8 Bits hat. So ist's ok.
