| |
|
|
- Página 1 - |
|
| El erste Collisionsabfrage con el Viereck 128X128 Pixel. Yo Bilde el Viereck ahora Schwarz de, así möglichs viele Farben genommen voluntad puede. Como sonst otro Farben en el Viereck el auch el Collisionsfarbe haben ,angesprochen voluntad. Si el Auto el "Viereck" berührt ,welches hiermit erstellt wurde : ogl("glReadPixels",140,140,128,128,~GL_BGRA,~GL_UNSIGNED_BYTE,ogl_rgb#) , se el Valor 255 ausgeben.
Massgebend son el Farben RGB grösser 252. Kann uno en cualquier momento en el CPP-Expediente ändern.
Posesiones sólo una vez el Abfrage con el DEV C++ gemacht o DLL erstellt., porque Yo en ASM primero otra vez gescheitert bin. El DEV C++ Source-Archivos son auch con esta.
El Zip es angehängt.
mfg |
|
|
| |
|
|
|
| |
|
- Página 1 - |
|
| Ablaufzeiten (Brutto)el Collisionsabfrage des Rechteckes 128X128X4 con 10000 Schleifendurchgänge : Rechner con 1,6 Gigahz
El Profano Mientras que-Leerschleife braucht ca 200ms.
ASM con XPIA/XPSE (DLL) son lo 4550 ms .
DEV C++ son lo 6210 ms ( una For-Bucle).
DEV C++ son lo 6260 ms (Mientras que-Bucle).
En 10000 durchgängen lohnt lo dieses en ASM umzusetzen, son ca 1,5 sec unterschied.
mfg peter |
|
|
| |
|
|
|
Frank Abbing | Su Ensamblador-Rutina es no optimiert. Wenn du ellos umstellst de Variables en Register es todavía einiges mehr drin. Ca. 20 Prozent, schätze Yo.
Diese Rutina behält deine Programmstruktur en, debería aber ya trabajar más rápido: KompilierenMarcaSeparación
If 0
AsmStart rgb_farbe (ogl_rgbxy#,groesse%)
mov edi,para2
xor ecx,ecx
mov ebx,para1
.while ecx<=edi
mov al,[ebx]
mov cl,[ebx+1]
mov dl,[ebx+2]
.if al>252
mov eax,255
.break
.endif
.if cl>252
mov eax,255
.break
.endif
.if dl>252
mov eax,255
.break
.endif
lea ebx,[ebx+4]
lea ecx,[ecx+4]
.endw
AsmEnd(z%)
EndIf
|
|
|
| |
|
|
|
Jörg Sellmeyer |
El Profano Mientras que-Bucle braucht ca 200ms.
Bist Usted sicher, que seculares más que 20-veces más rápido es como ASM? |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 22.08.2008 ▲ |
|
|
|
|
| Soll Leer-Bucle heissen, porque Yo bastante oben auch de Brutto spreche. Der Test se ejecuta en allen en el gleichen Mientras que-Bucle de Profano
Yo habe auch veces dieses Freebasic getestet para DLL redactar.
Wer en Freebasic una DLL redactar möchte y kein ASM kann/möchte y kein "C", es así bien bedient.
El Freebasic-DLL braucht 7400ms also sólo 1 Sekunde länger como DEV C++.
Könnte para el Basicprogrammierer , el una DLL redactar möchten uno el besten Freewarealternativen ser.
En meiner Collisionstest-Auswertung con el Freebasic-DLL en el Bildschirm a el Grafik, me está el Diferencia optisch no aufgefallen. Das Objeto flitzte weiterhin siempre todavía hin y her trotz el Überprüfung/Auswertung.
mfg peter |
|
|
| |
|
|
|
| Franco, deine braucht 3,5 sekunden länger.
Yo blanco nun no, como el con el Registern y LEA como funktioniert. Auf cada Fall muss el Adresse siempre en "4" weitergehen.
mfg peter |
|
|
| |
|
|
|
Frank Abbing |
Franco, deine braucht 3,5 sekunden länger.
Unrichtig! Register trabajo siempre más rápido como Varablen en el Speicher, incluso si ellos lokal son. Solche Tests Yo ya Dutzende durchgeführt. Und así una Assemblerroutine benötigt niemals 3,5 Sekunden länger, ellos benötigt überhaupt sólo wenige Millisekunden total. Selbst si du con grossen Bitmaps arbeitest. Usted puede el gerne con el ProSpeed.dll testen, el zahlreiche Bitmapeffekte sabe. Irgendwas va en deinen Tests gewaltig torcido. Was genau se el Rutina porque hacer? Sie bricht doch inmediatamente de, si ellos una muy hellen Farbwert findet. Wenn du una Robotersoftware escribir willst, el el Daten uno Cam auswertet, musst du ya el número heller Bildpunkte zählen. Vorher aber el Cambild grau hacer, o. schwarz-blanco. |
|
|
| |
|
|
| |
|
- Página 2 - |
|
|
| Noch bin Yo no beim Roboterbild, el ha todavía zeit. Yo möchte sólo una vez el schnellsten Routinen encontrar para el Bildauswertung en el zusammenhang con OpenGL y deren Darstellung. Befinde mich aún en el Anfangsstufe porque Yo el Profano sólo antes 3 Wochen kennengelernt habe. Como el ASM con dazu kommt ha se el Lernumfang geändert. Und habe nebenbei ya nette erkenntnisse con Getdibits , Setdibits usw gesammelt.
Hier el Code para el Laufzeiten testen : KompilierenMarcaSeparaciónDEF rgb_farbe_asm(2) ! "ogl-asm-test.dll","rgb_farbe"
DEF rgb_farbe_asm_o(2) ! "ogl-asm-test.dll","rgb_farbe_o"
declare bildxy# ,ogl_rgb#,x&,y&,z%
var groesse%=128*128*4
dim bildxy#,groesse%,z%
dim ogl_rgb#,groesse%
x&=10000
Print "Bereich mit 0 füllen"
whileloop 0,groesse%-1
byte ogl_rgb#,&loop=0
endwhile
Print "rgb_farbe-asm"
y&=&GetTickCount
Whileloop x&
z%=rgb_farbe_asm(ogl_rgb#,groesse%)
EndWhile
y&=&GetTickCount-y&
Print "Fertig in "+Str$(y&)+" Millisekunden."
Print "while-schleife"
y&=&GetTickCount
Whileloop x&
EndWhile
y&=&GetTickCount-y&
Print "Fertig in "+Str$(y&)+" Millisekunden."
Print "rgb_farbe-asm_o"
y&=&GetTickCount
Whileloop x&
z%=rgb_farbe_asm_o(ogl_rgb#,groesse%)
EndWhile
y&=&GetTickCount-y&
Print "Fertig in "+Str$(y&)+" Millisekunden."
WaitInput
End
y aquí el ASM-Code , woraus Yo una DLL erstellt con XPIA/XPSE KompilierenMarcaSeparación
AsmStart rgb_farbe_o (ogl_rgbxy#,groesse%)
mov edi,para2
xor ecx,ecx
mov ebx,para1
.mientras que ecx<=edi
mov al,[ebx]
mov cl,[ebx+1]
mov dl,[ebx+2]
.if al>252
mov eax,255
.romper
.endif
.if cl>252
mov eax,255
.romper
.endif
.if dl>252
mov eax,255
.romper
.endif
lea ebx,[ebx+4]
lea ecx,[ecx+4]
.endw
AsmEnd(z%)
AsmStart rgb_farbe
Parámetros ogl_rgbxy#,groesse%
LOCAL r :BYTE
LOCAL g :BYTE
LOCAL b :BYTE
LOCAL n :DWORD
mov eax,para2
mov n,eax
mov ecx,0
mov ebx,para1
.mientras que ecx<=n
mov al,[ebx+ecx]
mov r,al
mov al,[ebx+ecx+1]
mov g,al
mov al,[ebx+ecx+2]
mov b,al
mov al,b
.if al>252
mov eax,255
.romper
.endif
mov al,g
.if al>252
mov eax,255
.romper
.endif
mov al,r
.if al>252
mov eax,255
.romper
.endif
add ecx,4
.endw
AsmEnd(z%)
|
|
|
| |
|
|
|
Frank Abbing | Peter, du musst y& después de deiner ersten Zeitmessung auch otra vez zurücksetzten...
Ausserdem misst du no el Geschwindigkeit el Assemblerroutine, pero el Dauer uno Dll-Aufrufs. Wobei du el Dll nichtmal en el Speicher lädts.
Mi Messungen bestätigen mi Aussage de heut nachmittag. Su Rutina benötigt para el Bucle 344 Millisekunden, si yo esta Hundert Millionen(!) veces durchlaufen lasse. Mi Rutina benötigt para el gleiche Schleifenanzahl 172 Millisekunden. Es exakt doppelt así rápidamente!
Hier el simple Testroutine, en du en cualquier momento media Code gegen deinen austauschen kannst para Testen: KompilierenMarcaSeparación {$cleq}
declare ogl_rgb#,y&
var groesse%=100000000
dim ogl_rgb#,groesse%
cls
Sleep 3000
y&=&GetTickCount
AsmStart rgb_farbe (ogl_rgb#,groesse%)
mov edi,para2
xor ecx,ecx
mov ebx,para1
.while ecx<=edi
mov al,[ebx]
mov cl,[ebx+1]
mov dl,[ebx+2]
.if al>252
mov eax,255
.break
.endif
.if cl>252
mov eax,255
.break
.endif
.if dl>252
mov eax,255
.break
.endif
lea ebx,[ebx+4]
lea ecx,[ecx+4]
.endw
AsmEnd(z%)
Print Str$(Int(&GetTickCount-y&))
WaitInput
dispose ogl_rgb#
/../funcion-referencias/XProfan/end/'>End
| Sei en Zukunft vorsichtiger con deinen Behauptungen. Yo möchte no, dass de meiner Software y de Ensamblador überhaupt una falsches Bild entsteht, sólo porque du fehlerhafte Aussagen verbreitest aufgrund deiner fehlerhaften Testverfahren y Codes. | |
|
|
|
| |
|
|
|
| El 1. Tiempo ca 4000ms
El 2. Tiempo ca 200ms
El 3. Tiempo ca 8000ms
Dieses Testprogramm es de diesem Foro. Man muss siempre mißtrauischer voluntad, traue keinem Fremden Programa. Yo habe así algo ya geahnt.
Yo habe me de tiempo el Taktcyklen herausgesucht y umgerechnet. Yo komme fast en deine Tiempo. So algo schärft el Geist, aber trotzdem scheiss arbeit.
Macht siempre otra vez Spass.
Es Programmieren. Hoch lebe el propio Überprüfung.
So ahora gehst para nächsten Thema....., lo va más Jungs y Mädels.
mfg |
|
|
| |
|
|
|
Frank Abbing | Schau dir media Code doch a. Usted misst el Dll-Aufruf, el ha con Assemblergeschwindigkeit rein nada a tun.
Was misstrauisch? XPIA es mein Programa. |
|
|
| |
|
|
|
| Franco du bist Super. Auch esta se ejecuta con deiner Messung y deinem ASM-Vorschlag sólo knapp 300ms. Es doch qué. Super Sache. Como war el Wurm drin.
Posesiones lo con uno FreeBasic-DLL getestet, braucht 532ms. Kann also hochgerechnet ca pro Sekunde 93 Bilder auswerten con 128*128*4 Pixel en una Framerate de 30 o kann en 970ms ca 53 BMP-Texturen einlesen. KompilierenMarcaSeparaciónEXTERN "windows-ms"
FUNCTION rgb_farbe( adr AS ANY PTR ,ByVal wert As uinteger) AS INTEGER EXPORT
DIM i AS UInteger,n As UInteger
Dim b As Ubyte,g As Ubyte,r As UByte,a As UByte
FOR i = 0 TO wert Step 4
b=Peek(BYTE, adr+i )
g=Peek(Byte,adr+i+1)
r=Peek(Byte,adr+i+2)
If (b>252) Or (g>252) Or (r>252) Then
a=255
Exit for
EndIf
NEXT
Return a
END Function
function bmptex ( adr AS ANY PTR ,ByVal wert As uinteger) AS INTEGER EXPORT
DIM i AS UInteger,n As UInteger
Dim b As ubyte,g As ubyte,r As UByte
FOR i = 0 TO wert Step 4
b=Peek(BYTE, adr+i ) And 255
g=Peek(Byte,adr+i+1) And 255
r=Peek(Byte,adr+i+2) And 255
If (r=0) and (b=0) and (g=0) Then
Poke Byte,adr+i+3,0
Else
Poke Byte,adr+i+3,255
EndIf
Poke Byte,adr+i+2,b
Poke Byte,adr+i,r
NEXT
END function
END Extern
KompilierenMarcaSeparación |
|
|
| |
|
|
|
| So, dieses Thema es ahora sólo una vez por para mi Zwecke. Im Anhang como Zip : Un Collison con un Viereck. Objektsteuerung con el Tasten : QWES. Dabei el FreeBascic Bas, woraus Yo el beiliegende DLL erstellt habe con el Programa FreeBasic. Als nächstes kommt evtl una unregelmäßiges Kollisionsobjekt.
Tal vez schafft el auch una otro Foro-User.
Mein Schwerpunkt restos sólo una vez en 2D.
mfg peter |
|
|
| |
|
|