| |
| |
|
 | 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 |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Sehr schön! Funktioniert prima - es wäre nur schön, wenn Du auch noch irgendwo vermerkst, daß die Tasten Q,W,E,S Bewegungen verursachen. Ich zumindest habe nicht alle Scancodes im Kopf  |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 21.08.2008 ▲ |
|
| |
|
|
| Hier sieht man auch die enorme Geschwindigkeit von der DEV C++ Dll.
Wenn sich das Auto ausserhalb des Rechteckes bewegt, müssen 128X128x3 abfragen erfolgen ob etwas passiert und es bewegt sich immer noch super schnell ohne zu ruckeln.
Das war erstmal mein erstes Ziel. Eine fliessende Bewegung mit viel kontrollen.
Einen unregelmässigen Körper könnte man auch abfragen.
Daran wird jetzt getüftelt.
Versuche auch dieses noch in ASM umzusetzen.
mfg
peter |
|
| |
| |
| |
|
|
| Hier ist der ASM-Code.
Vorher, bevor der xpse genutzt wird , muss diese Änderung erfolgen:
ogl("glReadPixels",140,140,128,128,~GL_BGRA,~GL_UNSIGNED_BYTE,ogl_rgb#) > GL_BGRA entfernen
ogl("glReadPixels",140,140,128,128,32993,~GL_UNSIGNED_BYTE,ogl_rgb#) > die Zahl 32993 reinsetzen
Der Grund ist, das in der INC-Datei diese Variable noch nicht reingesetzt wurde.
Den Aufruf mit der Variablen z% und dem Drawbefehl auch die Variable z% übergeben : DrawText 20,160,(Format$("######0 ",z%))
Dann z%=Call(xpia_getprocaddressm(xpia_hmodule&,"rgb_farbe"),ogl_rgb#,groesse%)
Im Anhang ist das gesamte Programm für den Assembler xpse als Zip.
mfg
peter
KompilierenMarkierenSeparieren
If 0
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%)
EndIf
|
 |
| |
| |
| |
|
|
Frank
Abbing |
Im Anhang ist das gesamte Programm für den Asssembler xpse als Zip.
Peter, der Inline-Assembler heisst XPIA. XPSE ist der Precompiler...  |
|
| |
| |
| |
|
|
| Vielleicht begreife ich das noch in meinem Leben.
mfg |
|
| |
| |
| |
|
|
| 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. |
|
| |
| |
| |
|
(929)
Deutsch
English
Français
Español
Italia