Schnellste Methode eine Rechteck zu zeichnen?

[Kekskiller]

Ich möchte aus purem Ehrgeiz mein Projekt komplett mit selbstgecodeten Zeichenfunktionen gestalten und bin wirklich schwer am überlegen, wie ich das bei großen Rechtecken hinbekommen soll.

Der Code den ich gerade verwende:

Code: Alles auswählen

; Code von Max 'Kekskiller' Beutling

Global dbuffer.l, dbpitch.l, dbformat.l, dbbytes.l

Procedure GetBuffer() ;wechselt den screenmemorybuffer auf den aktuellen startdrawing-output
  dbuffer = DrawingBuffer()
  dbpitch = DrawingBufferPitch()
  dbformat = DrawingBufferPixelFormat()
  If dbformat = #PB_PixelFormat_16Bits
    dbbytes = 2
  ElseIf dbformat = #PB_PixelFormat_32Bits_BGR Or dbformat = #PB_PixelFormat_32Bits_RGB
    dbbytes = 4
  EndIf
EndProcedure

Procedure Rect32(x1.l, y1.l, x2.l, y2.l, c.l)
  
  Protected db.l, db2.l
  Protected w.l, h.l
  Protected county.l
  Protected countx.l
  
  If x1 > x2
    Swap x2, x1
  EndIf
  
  If y1 > y2
    Swap y2, y1
  EndIf
  
  db = dbuffer + y1 * dbpitch + x1 * dbbytes
  
  For county = y1 To y2
    
    db2 = db
    
    For countx = x1 To x2
      
      PokeL(db2, c)
      db2 + dbbytes
      
    Next
    
    db + dbpitch
    
  Next
  
EndProcedure

Was kann ich da noch an Speed rausholen? Auf nem 800*600-Screen (testweise) komme ich bei einem Quadrat von 400*300 Pixeln Größe ohne Debugger auf 20 Frames... Das ist eindeutig nicht akzeptabel, wenn man bedenkt, dass die Pixel später noch mit Transparenz- und AlphaBlending-Effekten versehen werden sollten, also dynamische Farbberechnung der Pixel.

Das ist eigentlich auch der Hauptgrund, denn ich will KEINE PB-internen Special Effects, Sprites oder 3D-Sprites benutzen. Ich bin nicht sehr begabt in Assembler, obwohl das vielleicht einen kleinen Speedschub geben würde.

Das Hauptproblem sind die vielen Pixel. Das Probleme mit mehreren Schleifen zu lösen ist wesentlich schneller als mit einer einzigen, da hier noch Abfragen für "Zeilenumbruch" gemacht werden müssen.

Was kann ich an meinem Code noch machen?

[edel]

Du kannst ja schonmal auf PokeL verzichten und Zeiger nehmen.

Code: Alles auswählen

[...]
*db2.long = db
[...]
*db2\l = c 
[...]

[Kekskiller]

Hab ich schon probiert, wenn man das Poke ausklammert, ist es auch nicht schneller. Ev. kann man mehrere Blöcke Speicher auf einmal schreiben, was aber auch wieder vorberechnet werden muss und so für Echtzeit nicht geeignet ist.

[inti]

also wenn du einfarbige flächen zeichnest dann sollte das ausrollen der for/next-schleifen was bringen:

ungetestet:

Code: Alles auswählen

  For county = y1 To y2
   
    db2 = db
   
    For countx = x1 To x2/8
     
      PokeL(db2, c)
      db2 + dbbytes
      PokeL(db2, c)
      db2 + dbbytes
      PokeL(db2, c)
      db2 + dbbytes
      PokeL(db2, c)
      db2 + dbbytes
      PokeL(db2, c)
      db2 + dbbytes
      PokeL(db2, c)
      db2 + dbbytes
      PokeL(db2, c)
      db2 + dbbytes
      PokeL(db2, c)
      db2 + dbbytes
     
    Next
   
    For countx2 = x2/8 To x2

      PokeL(db2, c)
      db2 + dbbytes

    Next

    db + dbpitch
   
  Next 

[hardfalcon]

Warum eigentlich soviele Pokes? Für ausgefüllte Rechtecke könnte man doch vor der For-Schleife z.B. eine komplette Pixelzeile berechnen, und diese dann innerhalb einer einzigen For-Schleife fèr jede Zeile ein mal "en bloc" in den Speicher schreiben.

[Kaeru Gaman]

> Warum eigentlich soviele Pokes?

>> also wenn du einfarbige flächen zeichnest dann sollte das ausrollen der for/next-schleifen was bringen:

bitte erst den kompletten thread lesen, worum es überhaupt geht, bevor der senf dazugegeben wird!

[Kekskiller]

Leute, ich weiß was falsch war.

a) Ich hatte ein normalerweise unbedeutendes Delay(1) zwischen der Maus- und Keyboard-Aktualisierung. Ohne das bekam ich urplötzlich 43 Frames
b) im Fenstermodus geht so einiges an Geschwindigkeit flöten
c) Nachdem ich viel rumprobiert habe und auch erstes Alphablending integriert hatte, musste ich feststellen, dass Peek() extremst lahm ist. Unabhängig ob Pointer oder Befehl. Als ich in der Hilfe nach kleinen Hinweisen auf die Lösung des Problemes suchte, wurde mir schlagartig klar, wie ich enorm viel Speed rausholen kann: Das Bild im RAM manipulieren anstatt im Grafikspeicher. Der RAM ist architektonisch dem Prozessor viel näher als der Grafikspeicher der GraKa, also habe ich ein Sprite mit #PB_Sprite_Memory erstellt, es als Speicher benutzt und später gezeichnet: BOOM!

Ich kanns garnicht fassen, wie fix jetzt alles geht! Man, jetzt kann ich all diese tollen Konzepte umsetzen, die ich mir fein säuberlich mathematisch zurecht gelegt habe... Boah.... ich halt das nicht mehr aus, heute platz ich.



Was stell ich als nächstes an? Hm... Ich denke ich werde mir daraus ein paar selbstprogrammierter Pixelshader mit Macros erstellen... MUAHAHAHAHAHA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Fluid Byte]

Ich hatte ein normalerweise unbedeutendes Delay(1) zwischen der Maus- und Keyboard-Aktualisierung. Ohne das bekam ich urplötzlich 43 Frames

Warum?

Das ist nicht das gleiche wie ein Delay() bei WindowEvent() zu benutzen. Das gilt nur für Anwendungen nicht aber für Direct X basierte Spiele welche mit 100% CPU Leistung laufen sollten um die volle Power auszunutzen. Das ja' grad der Witz einer solchen Schnittstelle.

[Kekskiller]

Ich finds trotzdem ziemlich seltsam, warum das einen starken Geschwindigkeitsverlust verursacht. Meiner Meinung nach geschlampte Programmierung, wenn eine 1 Millisekunde den ganzen Rest vom Programm um ein vielfaches der geraubten Zeit verlangsamt.

[Xaby]

Vielleicht findest hier auch noch was, das dir gefällt ...

http://www.purebasic.fr/german/viewtopi ... highlight=