| |
|
|
- Seite 1 - |
|
| Die erste Collisionsabfrage mit dem Viereck 128X128 Pixel. Ich Bilde das Viereck jetzt Schwarz ab, damit möglichs viele Farben genommen werden können. Da sonst andere Farben im Viereck die auch die Collisionsfarbe haben ,angesprochen werden. Wenn das Auto das "Viereck" berührt ,welches hiermit erstellt wurde : ogl("glReadPixels",140,140,128,128,~GL_BGRA,~GL_UNSIGNED_BYTE,ogl_rgb#) , wird der Wert 255 ausgeben.
Massgebend sind die Farben RGB grösser 252. Kann man jederzeit in der CPP-Datei ändern.
Habe erst einmal die Abfrage mit dem DEV C++ gemacht bzw DLL erstellt., weil ich in ASM erstmal wieder gescheitert bin. Die DEV C++ Source-Dateien sind auch mit dabei.
Die Zip ist angehängt.
mfg |
|
|
| |
|
|
|
| |
|
- Seite 1 - |
|
| Ablaufzeiten (Brutto)der Collisionsabfrage des Rechteckes 128X128X4 mit 10000 Schleifendurchgänge : Rechner mit 1,6 Gigahz
Die Profan While-Leerschleife braucht ca 200ms.
ASM mit XPIA/XPSE (DLL) sind es 4550 ms .
DEV C++ sind es 6210 ms ( eine For-Schleife).
DEV C++ sind es 6260 ms (While-Schleife).
Bei 10000 durchgängen lohnt es sich dieses in ASM umzusetzen, sind ca 1,5 sec unterschied.
mfg peter |
|
|
| |
|
|
|
Frank Abbing | Deine Assembler-Routine ist nicht optimiert. Wenn du sie umstellst von Variablen auf Register ist noch einiges mehr drin. Ca. 20 Prozent, schätze ich.
Diese Routine behält deine Programmstruktur bei, sollte aber schon schneller arbeiten: KompilierenMarkierenSeparieren
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 |
Die Profan While-Schleife braucht ca 200ms.
Bist Du sicher, daß Profan mehr als 20-mal schneller ist als ASM? |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 22.08.2008 ▲ |
|
|
|
|
| Soll Leer-Schleife heissen, weil ich ganz oben auch von Brutto spreche. Der Test läuft bei allen in der gleichen While-Schleife von Profan
Ich habe auch mal dieses Freebasic getestet zum DLL erstellen.
Wer in Freebasic eine DLL erstellen möchte und kein ASM kann/möchte und kein "C", ist damit gut bedient.
Die Freebasic-DLL braucht 7400ms also nur 1 Sekunde länger als DEV C++.
Könnte für die Basicprogrammierer , die eine DLL erstellen möchten einer der besten Freewarealternativen sein.
Bei meiner Collisionstest-Auswertung mit der Freebasic-DLL auf dem Bildschirm an der Grafik, ist mir der Unterschied optisch nicht aufgefallen. Das Objekt flitzte weiterhin immer noch hin und her trotz der Überprüfung/Auswertung.
mfg peter |
|
|
| |
|
|
|
| Frank, deine braucht 3,5 sekunden länger.
Ich weiss nun nicht, wie das mit den Registern und LEA da funktioniert. Auf jeden Fall muss die Adresse immer um "4" weitergehen.
mfg peter |
|
|
| |
|
|
|
Frank Abbing |
Frank, deine braucht 3,5 sekunden länger.
Unrichtig! Register arbeiten immer schneller als Varablen im Speicher, selbst wenn sie lokal sind. Solche Tests habe ich schon Dutzende durchgeführt. Und so eine Assemblerroutine benötigt niemals 3,5 Sekunden länger, sie benötigt überhaupt nur wenige Millisekunden insgesamt. Selbst wenn du mit grossen Bitmaps arbeitest. Du kannst das gerne mit der ProSpeed.dll testen, die zahlreiche Bitmapeffekte kennt. Irgendwas geht bei deinen Tests gewaltig schief. Was genau soll die Routine denn machen? Sie bricht doch sofort ab, wenn sie einen sehr hellen Farbwert findet. Wenn du eine Robotersoftware schreiben willst, die die Daten einer Cam auswertet, musst du schon die Anzahl heller Bildpunkte zählen. Vorher aber das Cambild grau machen, bzw. schwarz-weiss. |
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
| Noch bin ich nicht beim Roboterbild, das hat noch zeit. Ich möchte erst einmal die schnellsten Routinen finden für die Bildauswertung im zusammenhang mit OpenGL und deren Darstellung. Befinde mich noch in der Anfangsstufe weil ich das Profan erst vor 3 Wochen kennengelernt habe. Da das ASM mit dazu kommt hat sich der Lernumfang geändert. Und habe nebenbei schon nette erkenntnisse mit Getdibits , Setdibits usw gesammelt.
Hier der Code für die Laufzeiten testen : KompilierenMarkierenSeparierenDEF 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
und hier der ASM-Code , woraus ich eine DLL erstellt mit XPIA/XPSE KompilierenMarkierenSeparieren
AsmStart rgb_farbe_o (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%)
AsmStart rgb_farbe
Parameters 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
.while 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
.break
.endif
mov al,g
.if al>252
mov eax,255
.break
.endif
mov al,r
.if al>252
mov eax,255
.break
.endif
add ecx,4
.endw
AsmEnd(z%)
|
|
|
| |
|
|
|
Frank Abbing | Peter, du musst y& nach deiner ersten Zeitmessung auch wieder zurücksetzten...
Ausserdem misst du nicht die Geschwindigkeit der Assemblerroutine, sondern die Dauer eines Dll-Aufrufs. Wobei du die Dll nichtmal in den Speicher lädts.
Meine Messungen bestätigen meine Aussage von heut nachmittag. Deine Routine benötigt für die Schleife 344 Millisekunden, wenn ich diese Hundert Millionen(!) mal durchlaufen lasse. Meine Routine benötigt für die gleiche Schleifenanzahl 172 Millisekunden. Das ist exakt doppelt so schnell!
Hier die simple Testroutine, bei der du jederzeit meinen Code gegen deinen austauschen kannst zum Testen: KompilierenMarkierenSeparieren {$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#
End
| Sei in Zukunft vorsichtiger mit deinen Behauptungen. Ich möchte nicht, dass von meiner Software und von Assembler überhaupt ein falsches Bild entsteht, nur weil du fehlerhafte Aussagen verbreitest aufgrund deiner fehlerhaften Testverfahren und Codes. | |
|
|
|
| |
|
|
|
| Die 1. Zeit ca 4000ms
Die 2. Zeit ca 200ms
Die 3. Zeit ca 8000ms
Dieses Testprogramm ist aus diesem Forum. Man muss immer mißtrauischer werden, traue keinem Fremden Programm. Ich habe so etwas schon geahnt.
Ich habe mir mal die Taktcyklen herausgesucht und umgerechnet. Ich komme fast auf deine Zeit. So etwas schärft den Geist, aber trotzdem scheiss arbeit.
Macht immer wieder Spass.
Das ist Programmieren. Hoch lebe die eigene Überprüfung.
So jetzt gehst zum nächsten Thema....., es geht weiter Jungs und Mädels.
mfg |
|
|
| |
|
|
|
Frank Abbing | Schau dir meinen Code doch an. Du misst den Dll-Aufruf, das hat mit Assemblergeschwindigkeit rein gar nicht zu tun.
Was misstrauisch? XPIA ist mein Programm. |
|
|
| |
|
|
|
| Frank du bist Super. Auch diese läuft mit deiner Messung und deinem ASM-Vorschlag nur knapp 300ms. Das ist doch was. Super Sache. Da war der Wurm drin.
Habe es mit einer FreeBasic-DLL getestet, braucht 532ms. Kann also hochgerechnet ca pro Sekunde 93 Bilder auswerten mit 128*128*4 Pixel bei eine Framerate von 30 bzw kann bei 970ms ca 53 BMP-Texturen einlesen. KompilierenMarkierenSeparierenEXTERN "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
KompilierenMarkierenSeparieren |
|
|
| |
|
|
|
| So, dieses Thema ist jetzt erst einmal durch für meine Zwecke. Im Anhang als Zip : Eine Collison mit einem Viereck. Objektsteuerung mit den Tasten : QWES. Dabei die FreeBascic Bas, woraus ich die beiliegende DLL erstellt habe mit dem Programm FreeBasic. Als nächstes kommt evtl ein unregelmäßiges Kollisionsobjekt.
Vielleicht schafft das auch ein anderer Forum-User.
Mein Schwerpunkt bleibt erst einmal bei 2D.
mfg peter |
|
|
| |
|
|