| |
| |
|
 | 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 |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Sehr schön! Funktioniert prima - lo wäre sólo schön, si auch todavía irgendwo vermerkst, daß el Tasten Q,W,E,S Bewegungen verursachen. Yo zumindest habe no todos Scancodes en el Kopf  |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 21.08.2008 ▲ |
|
| |
|
|
| Hier sieht uno auch el enorme Geschwindigkeit de el DEV C++ Dll.
Wenn se el Auto ausserhalb des Rechteckes bewegt, necesario 128X128x3 abfragen tener lugar si algo passiert y lo bewegt se siempre todavía super rápidamente sin a ruckeln.
Das war primero mein erstes Ziel. Un fliessende Bewegung con viel kontrollen.
Einen unregelmässigen Körper podría uno auch abfragen.
Daran se ahora getüftelt.
Versuche auch dieses aún en ASM umzusetzen.
mfg
peter |
|
| |
| |
| |
|
|
| Hier es el ASM-Code.
Vorher, bevor el xpse genutzt se , muss esta Änderung tener lugar:
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#) > el Zahl 32993 reinsetzen
Der Grund es, el en el INC-Expediente esta Variable todavía no reingesetzt wurde.
Den Aufruf con el Variables z% y el Drawbefehl auch el Variable z% transferencia : DrawText 20,160,(Formato$("######0 ",z%))
Dann z%=Call(xpia_getprocaddressm(xpia_hmodule&,"rgb_farbe"),ogl_rgb#,groesse%)
Im Anhang es el gesamte Programa para el Ensamblador xpse como Zip.
mfg
peter
KompilierenMarcaSeparación
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%)
./../funcion-referencias/XProfan/endif/'>EndIf
|
 |
| |
| |
| |
|
|
Frank
Abbing |
Im Anhang es el gesamte Programa para el Asssembler xpse como Zip.
Peter, el Inline-Ensamblador heisst XPIA. XPSE es el Precompiler...  |
|
| |
| |
| |
|
|
| Tal vez begreife Yo el todavía en mi Leben.
mfg |
|
| |
| |
| |
|
|
| 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. |
|
| |
| |
| |
|
(1.130)
Deutsch
English
Français
Español
Italia