4. nochmal put pixel

nochmal put pixel

  • B

    hi,

    ist es möglich einen das man ne put pixel methode schreibt die weniger als 0,000625 ms braucht?
    wenn ja, wie?

    MFG BlockBuster

    0
  • N

    Wie lange das Ding braucht haengt immer vom CPU ab... hm... mal schaun, ob das auf nem 60Mhz Prozessor was werden wuerde...
    60Mhz (Intel 486 kompatibel) schafft also 60*1000*1000 => 60.000.000 clocks pro Sekunde maximal. => fuer ein clock cycle ca. 0,0000000016666... Sekunden.
    Nun noch die Putpixel routine: (einfachster Fall - real mode)
    ;di muss gesetzt sein...
    call PutPixel ;3 => near call
    push es ;3
    mov bx,0A000h ;1
    mov es,bx ;3
    mov [es:di],al;1
    pop es ;3
    ret ;5
    => 19 clock cycles => 0,0000000316... Sekunden => 0,000031666... ms
    wie du siehst: es geht 😉 mit zB. einem 1Ghz Prozessor sollte das selbst in Windows kein Problem sein...

    Hoffe jetzt nur, dass ich mich net verrechnet habe... also auf das Zeug keine Garantie 😃

    0
  • S

    Wie kann man bei der Methode denn X,Y und die Farbe angeben ?

    0
  • N

    Die Farbe wird in al uebergeben.
    x und y muessen vorher schon in di umgerechnet sein. Hierbei bietet es sich natuerlich an fixe Werte fuer di zu benutzen, anstatt mit 2 Variablen x und y erstmal herumzurechnen... Wenn fuer jeden zu setzenden Pixel jedesmal die Position im Bildschirmspeicher voellig neu berechnet werden sollte, wird das ganze a bissel langsamer. Zum Zeichnen von Bitmaps o.ae. ist das dann natuerlich noch weniger geeignet, als die vorherige Variante...

    Aber nur mal so zum Spass an der Freud, eine Putpixel Funktion, die x und y erwartet:
    ;x in bx y in dx Farbe in al - bx cx dx werden veraendert. zum Sichern, muessen nochmal 15 clock cycles dazugerechnet werden... (1 fuer push reg16 und 4 fuer pop reg16)
    call PutPixel ;/3
    push es ;/3
    mov cx,dx ;/1
    shl dx,08h ;y256 /2
    shl cx,06h ;y    64 /2
    add dx,cx ;=>y320 /1
    add bx,dx ;=>y    320+x /1
    mov dx,0A000h ;/1
    mov es,dx ;/3
    mov [byte ptr es:bx],al ;/1
    pop es ;/3
    ret ;/5
    ==>26 clock cycles => 0,000043333 ms

    0
  • B

    hi also das heißt mit der letzten funkion kann ich meinen gesamten bildschirm (320x200) in 2,773312 ms "vollmalen"? das stimmt doch net ganz oder?

    320 x 200 = 64000
    64000 x 0,000043333 ms = 2,773312

    dann kann man ja superflüßige animationen erstellen etc. denn das menschliche auge kann nur etwas 25 bilder pro sekunde "erkennen" also alle 40ms ein neues 🙂

    MFG BlockBuster

    0
  • N

    Schoen waers 😃 Der Prozessor ist Willig, die restliche Hardware jedoch meist nicht 😉
    1. Ist die Bildschirmrefreshrate net so hoch.
    2. kannst du doch nicht NUR mit dieser Proc jedesmal ein neues Bild erstellen...

    0
  • B

    hi,

    schade 🙂
    welche teile der hardware verlangsamen denn diesen vorgang?
    kann man die refreshrate net irgendwie umstellen?
    wie soll man sonst nem OS eine schöne Oberfläche geben? Wie ist denn das beispielsweiße bei windows? ich könnte mir vorstellen das die nicht alle 40ms den ganzen bildschirm neu "malen" sondern nur den teil der sich geändert hat, stimmt das?

    0
  • N

    Hab gerade bemerkt: man sollte keine Beitraege zwischen Tuer und Angel erstellen 🙄
    Also: Wenn du zum Neuzeichnen des Bildschirms 2,773312 ms brauchst, gibt das ca.50 Bilder pro Sekunde. Das laesst sich selbst mit aelteren Grafikkarten noch gut umsetzen.
    Und: ja, bei Windows werden meist nur Teile des Bildschirms neu gezeichnet.
    [Nachtrag:]
    Die meisten Grafiken in einem OS, wie zB. rechteckige Fenster/Buttons oder Bitmaps wuerde ich nicht durch eine solche "langsame" Putpixel-proc zeichnen.

    [ Dieser Beitrag wurde am 15.07.2002 um 00:36 Uhr von Nobuo T editiert. ]

    0
  • B

    was meinsten denn mit tür und angel? 😕
    also wenn nicht mir ner put pixel routine, wie dann? funktionen zum zeichnen eines rechteckes bestehen doch auch auf putpixel routinen oder?

    so ich guck jetzt mal schön gemütlich seven days 🙂

    0
  • N

    Mit der ersten aussage meinte ich, dass ich wenig Zeit hatte...

    Ein ausgefuelltes Rechteck wuerde ich zB. eher so zeichnen:
    di=Position linker oberer Ecke
    mov dx,di
    mov cx,YLaenge
    Loop1:
    push cx
    mov cx,XLaenge
    mov al,Farbe
    rep stosb
    add dx,XResolution ;Bildschirmaufloesung X
    mov di,dx
    pop cx
    loop Loop1

    Etwas schneller, gel 😉

    Mit einem Bitmap kann man dann so aehnlich umgehen...
    Eine putpixel routine, die x und y Koordinaten erstmal in einen Speicherindex umrechnet etc. ist wirklich in den seltensten Faellen sinnvoll...

    0
  • M

    Hi,

    das Problem ist, dass maximal 8 Millionen Pixel pro Sekunde
    (bei 16 bit tiefe) gesetzt werden können. Mehr ist definitiv nicht zu
    Schaffen. Trotz AGP-BUS !!!Trotz optimierten ASM-Code !!
    Gelesen können nur die Hälfte.
    Auch bei einer noch so schnellen CPU ist nicht mehr drin !!

    That's it.

    Cu
    Manitu 🕶

    0
  • T

    Und man sollte vielleicht noch in betracht ziehen,d ass man den Bildschirm zwar evtl. schnell vollmalen kann, aber das zu malende Bild muss wohl auch irgendwie ausgerechnet werden, im Speicher hinterlegt und dann bei den PutPixel-Routinen wieder vom Speicher geholt werden...da kommt einiges zusammen 🙂

    0
  • B

    hi nochmal,

    und könnt ihr mal die wirklich "schnellste" und "beste" putpixel routine posten? also was total optimiert ist etc.

    0
  • B

    *push*

    0
  • N

    *siehe 4. und 2. Posting*
    was sehr viel schnelleres habe ich noch net gesehen 😕

    0
Anmelden zum Antworten