Hi,
habe mir die Developer-Version heruntergeladen, wie zu erwarten funktioniert ein einfaches F5 mit dem Sourcecode nicht.
Die EXE-Datei der Version 1.61 funktioniert aber einwandfrei, es werden Kalender angelegt usw., d.h. die Datenbank funktioniert.
Test auf XP32 / Win764 ohne Probleme.
Beim initialen Start und auch sonst kommt die Fehlermeldung "...sqlite.dll ist keine gültige Windows-Datei...".
umgestiegen auf neues/anderes Windows?
Kann es sein, dass du auf deinem Rechner garkein Outlook hast, sondern Outlook Express?
Trotz ähnlichem Namen sind das zwei völlig verschiedene Programme.
Hab mich eben mal auf einen Rechner eingeloggt, auf dem Outlook läuft, die UDF funktioniert einwandfrei.
Hi,
ich benutze kein Outlook und habe es auch von allen unseren Rechnern entfernt, was aber definitiv nicht stimmt, ist dass die Zeile
Local $oOutlook = ObjCreate("D:\Program Files (x86)\Microsoft Office\Office12\Outlook.Application")
[/autoit]
aus der Outlook.udf kommt!
Wenn du bestehende funktionierende Scripte änderst und dich wunderst, dass diese danach nicht (mehr) funktionieren, hilft es auch nicht, die Leute hier im Forum vorwurfsvoll nach Lösungen für das von DIR verursachte Problem zu drängen!
Hi,
nach ziemlich genau 4 Jahren Forenzugehörigkeit sollte man annehmen, dass du die Suche/Google benutzen kannst....
bilder nebeneinander site:www.autoit.de
in google einzutippern sollte machbar sein
In den ersten beiden Links findes du komplette Scripte, u.a. das hier
Hi,
bist du sicher, dass Rockstar Games für GTA San Andreas diese Features erlaubt? Würde mich wundern....
Zeig doch mal den dazu passenden Link, ich hab auf deren Website und in der aktuellen Spielanleitung jedenfalls nichts gefunden.
Du brauchst überigens nichts grossartig umzubauen, die dll ist direkt per AutoIt ansprechbar.
Wie soll ich das anstellen? (evtl. Converter o.Ä.)
Ja, so würde ich das machen...
Ein frohes neues Jahr euch allen!
Es gibt eine Lösung dafür, nennt sich Deskstream, und übermittelt nicht nur Standbild, sondern auch (in Maßen) Video incl. Zooming, Panning und noch andere Kleinigkeiten^^
Und zum Topic:
Aus der Hilfe:
...gibt die Funktion ein Handle zu einem HBITMAP zurück.
Um die (Screenshot)-Datei zu versenden, musst du den Inhalt erst einlesen und dann stückchenweise versenden...
Beim Server dann wieder zusammensetzen und einen Namen vergeben, speichern, fertig!
Topic2:
HIER gibt es eine Anleitung für die Verwendung von TCP.
Hi,
ja, das kannst du doch per SIMD, siehe Beispielkernel beim AlphaBlend.
Global $KernelSource = "__kernel void alphablend( __global int* output, __global int* dest, __global int* source, const unsigned int width,const unsigned int height,const int alpha)" & @CRLF & _
"{" & @CRLF & _
"uint threadid = get_global_id(0);" & @CRLF & _ ;thread-id, d.h. jedes pixel von 1 bis b*h
"uchar a1= dest[threadid]>>24;" & @CRLF & _;alpha
"uchar r1 =(dest[threadid]&0x00FF0000)>>16;" & @CRLF & _;rdest
"uchar g1 =(dest[threadid]&0x0000FF00)>>8;" & @CRLF & _;g
"uchar b1 =(dest[threadid]&0x000000FF)>>0;" & @CRLF & _;b
"uchar p=(a1*(255-alpha))>>8;"& @CRLF & _;
"uchar a2= source[threadid]>>24;" & @CRLF & _;alpha
"uchar r2 =(source[threadid]&0x00FF0000)>>16;" & @CRLF & _;rsource
"uchar g2 =(source[threadid]&0x0000FF00)>>8;" & @CRLF & _;g
"uchar b2 =(source[threadid]&0x000000FF)>>0;" & @CRLF & _;b
";" & @CRLF & _
";" & @CRLF & _
"uchar a=(a2*(255-p)+(a1*p))>>8;" & @CRLF & _
"uchar r=(r2*(255-p)+(r1*p))>>8;" & @CRLF & _
"uchar g=(g2*(255-p)+(g1*p))>>8;" & @CRLF & _;
"uchar b=(b2*(255-p)+(b1*p))>>8;" & @CRLF & _
";" & @CRLF & _
";" & @CRLF & _
";" & @CRLF & _
"output[threadid] =(a<<24)|(r<<16)|(g<<8)|b;" & @CRLF & _;
"}"
Global $KernelSource = "__kernel void alphablend( __global uchar4* output, __global uchar4* dest, __global uchar4* source, const unsigned int width,const unsigned int height,const int alpha)" & @CRLF & _
"{" & @CRLF & _
"uint threadid = get_global_id(0);" & @CRLF & _ ;thread-id, d.h. jedes pixel von 1 bis b*h
"uchar4 dst= dest[threadid];" & @CRLF & _;destination pixel
"uchar p=((dst.s3*(255-alpha))>>8);" & @CRLF & _;precalculated alpha
"uchar4 src= source[threadid];" & @CRLF & _;source pixel
"uchar4 argb;"& @CRLF & _
"argb.s0=(src.s0*(255-p)+(dst.s0*p))>>8;" & @CRLF & _
"argb.s1=(src.s1*(255-p)+(dst.s1*p))>>8;" & @CRLF & _
"argb.s2=(src.s2*(255-p)+(dst.s2*p))>>8;" & @CRLF & _;
"argb.s3=(src.s3*(255-p)+(dst.s3*p))>>8;" & @CRLF & _
"output[threadid] =argb;" & @CRLF & _;(a<<24)|(r<<16)|(g<<8)|b
"}"
__kernel void alphablend( __global int* output, __global int* dest, __global int* source, const unsigned int width,const unsigned int height,const int alpha)
{
uint threadid = get_global_id(0); //thread-id, d.h. jedes pixel von 1 bis b*h
uchar a1= dest[threadid]>>24; //alpha
uchar r1 =(dest[threadid]&0x00FF0000)>>16; //r dest
uchar g1 =(dest[threadid]&0x0000FF00)>>8; //g
uchar b1 =(dest[threadid]&0x000000FF)>>0; //b
uchar p=(a1*(255-alpha))>>8;
uchar a2= source[threadid]>>24; //alpha
uchar r2 =(source[threadid]&0x00FF0000)>>16; //r source
uchar g2 =(source[threadid]&0x0000FF00)>>8; //g
uchar b2 =(source[threadid]&0x000000FF)>>0; //b
uchar a=(a2*(255-p)+(a1*p))>>8;
uchar r=(r2*(255-p)+(r1*p))>>8;
uchar g=(g2*(255-p)+(g1*p))>>8;
uchar b=(b2*(255-p)+(b1*p))>>8;
output[threadid] =(a<<24)|(r<<16)|(g<<8)|b;
}
__kernel void alphablend( __global uchar4* output, __global uchar4* dest, __global uchar4* source, const unsigned int width,const unsigned int height,const int alpha)
{
uint threadid = get_global_id(0); //thread-id, d.h. jedes pixel von 1 bis b*h
uchar4 dst= dest[threadid]; //destination pixel
uchar p=((dst.s3*(255-alpha))>>8); //precalculated alpha
uchar4 src= source[threadid]; //source pixel
uchar4 argb;
argb.s0=(src.s0*(255-p)+(dst.s0*p))>>8;
argb.s1=(src.s1*(255-p)+(dst.s1*p))>>8;
argb.s2=(src.s2*(255-p)+(dst.s2*p))>>8;
argb.s3=(src.s3*(255-p)+(dst.s3*p))>>8;
output[threadid] =argb;
}der untere Kernel macht dasselbe wie der obere, da gehts jetzt konkret zwar nur um 4 Bytes, aber es gibt natürlich auch andere Datenformate, z.B. 16 Bytes (4 Pixel).
Allerdings bringt das im Großen und Ganzen nur etwas auf CPU´s, da dort dann die SSE-Befehle genutzt werden, d.h. paralle Verarbeitung von 16Bytes.
Die GPU bricht jedes "Problem" auf die kleinste Größe herunter (Anzahl der Workgroups/Workitems), will sagen, es werden (wenn möglich) alle Shader gleichzeitig benutzt.
Verwendet man nun z.B. doppelt große Datenwörter, dann werden eben 2 Shader darauf angesetzt. Im Endeffekt bringt das also auf einer GPU nicht viel, auf einer CPU aber einen massiven Performance-Schub (SSE).
Komprimierung ist ein anderes Thema 
Man könnte die zu komprimierenden Daten anhand der vorhandenen Hardware (Anzahl der Workgroups/Workitems) schon im Vorfeld so in Blöcke aufteilen, dass die Hardware immer optimal ausgenutzt wird.
Leider sind die gängigen Kompressionsalgoritmen darauf angelegt, mehrere Durchläufe NACHEINANDER durchzuführen. Die Daten werden dabei meist insgesamt bearbeitet, will heissen, der Algorithmus komprimiert 1Kb besser als 10 Blöcke zu je 100Bytes....
Aber bei z.B. JPG gehts sowieso nur um 4x4 bzw 16x16 Pixel, da kann man dann sehr schön paralllel arbeiten!
Das Aufteilen in parallel (gleichzeitig) verarbeitbare Blöcke ist also das Geheimnis.
So ist z.B. Kantendetektion per Sobel-Operator seeeehr fix, vor allem da man dann pro Workgroup noch 16kB lokalen Speicher auf der Graka verwenden kann, der im Zugriff ca. 100x schneller ist als globaler Speicher.
Auch Passwort-Cracken ist, wie schon mehrfach bewiesen, nun auch nicht mehr nur Supercomputern vorbehalten.....
Hi,
eukalyptus imul register,16 geht schneller mit shl register,4 (2 hoch 4 = 16) (shl=shift left).
ich hatte solchen "Kleinkram" einfach aussen vorgelassen, denn die Optimierung von Assemblercode auf den heutigen Prozessorern bedeutet nicht (unbedingt) einen Befehl zu verwenden, der einen halben Takt einspart. Aber natürlich hast du Recht, idR ist ein Shift schneller....
Aber auch die Rechnerei mit Variablen im Speicher ist so langsam nicht, solange man darauf achtet, dass die angeforderten Adressen im Lvl1-Cache liegen. Wie gesagt, alles eine Frage, auf welchen Prozessor/Architektur optimiert wird.
Angenommen, wir zerreissen den Code auf Teufel komm raus und holen, sagen wir mal, Faktor 3-4 an Geschwindigkeit raus. Das wäre natürlich in diesem speziellen Fall nicht schlecht, die Framerate würde von 5-10 auf ca. 30 FPS steigen. Bissl Multithreading drumrumgestrickt und in eine Dll verpackt, voila 
Die selbe Arbeit in die Optimierung des OpenCL-Kernels gesteckt, würde die Framerate nicht mal verdoppeln, da nicht die BERECHNUNG der Pixel die meiste Zeit beansprucht, sondern der Transfer der Daten von und zu der Grafikkarte! Und btw., eine Erhöhung von 250fps auf 500? Wer bräuchte das?
Bin gerade dabei, bei OpenCl die reinen Ausführungsszeiten der Kernel auf den einzelnen Geräten und dazu auch den Transfer der Daten in und aus dem Speicher zu "profilen".
Im vorliegenden Fall sieht das so aus:
Bild 600x600 Pixel
Grafikkarte: Ausführungszeit Kernel ~0,9ms, Speichertransfer Grafikkartenspeicher>RAM ~1ms
CPU (dualcore): Ausführungszeit Kernel ~80ms, SpeichertransferRAM>RAM ~0,2ms
Der Zeitaufwand fürs Blitten bleibt jeweils konstant, das lassen wir mal aussen vor.
Bild 6000x6000 Pixel
Grafikkarte: Ausführungszeit Kernel ~90ms, Speichertransfer Grafikkartenspeicher>RAM ~150ms
CPU (dualcore): Ausführungszeit Kernel ~9000ms (!!!), Speichertransfer RAM>RAM ~35ms
Bei diesen Ergebnissen stellt sich nicht mehr die Frage, wo in Zukunft berechnet wird...
Hi,
habe mir den ASM-Code natürlich angeschaut und ausgestoppt.
Die Funktion _ASM_Calc_Color() benötigt auf meinem Rechner ca. 100-200 Millisekunden.
Das liegt unter anderem an "meinem Freund" FPATAN()und auch daran, dass recht viel mit Variablen aus dem Speicher gerechnet wird, statt mit den Prozessorregistern. Alles in allem aber ein feiner Code 
Da ich weiss, wieviel Mühe, Zeit und Nerven es kostet ASM-Code zu optimieren (jaja AspirinJunkie, lach nur ^^), habe ich den AutoIt-Code von Eukalyptus mehr schlecht als recht in einen OpenCl-Kernel transferiert. Sagen wir mal so, es läuft^^, die C-Freaks werden sicher etwas zu verbessern haben.
Auf der CPU (DualCore) ist das OpenCL-Programm in etwa gleich schnell, pro Core also etwa halb so schnell wie der ASM-Code. OpenCl nutzt alle verfügbaren Cores, daher wird schon bei einem Quadcore das Programm ca. doppelt so schnell laufen wie der ASM-Code.
Auf der GPU wird aber wieder mal gezeigt, wo der Hammer hängt! Selbst auf meiner lowlevel-Grafikkarte läuft das Programm ca. 17x schneller als Eukalyptus´ASM-Code....
Sicherlich kann man den OpenCL-Kernel noch optimieren, allein durch SIMD würde der Code auf der CPU ca. 1.5x schneller laufen.
Gerade bei float-Berechnungen die sich gut parallelisieren lassen, führt imho kein Weg an OpenCL vorbei, schon garnicht, wenn auf einer Grafikkarte bzw. GPU gerechnet wird.
Der Kernel gehört natürlich in eine CL-Datei, dann ist der Code wesentlich einfacher zu editieren und auch zu lesen....aber da war die Nacht zuende 
Wer mehrere GPU´s in seinem Rechner hat, kann diese in Zeile 129 einzeln anwählen per _CL_GetDevice("GPU",1,nummer_device) oder die erste einfach per _CL_GetDevice("GPU")
;#AutoIt3Wrapper_UseX64=y
[/autoit] [autoit][/autoit] [autoit];**** Directives created by AutoIt3Wrapper_GUI ****
#include <opencl_easy.au3>
#include <GUIConstantsEx.au3>
#include <WinAPI.au3>
#include <GDIConstants.au3>
#include <Misc.au3>
;"#pragma OPENCL EXTENSION cl_amd_printf : enable"& @CRLF & _
Global $KernelSource = "#define cPI atan(1.0f) * 4.0f" & @CRLF & _;konstanten atan(1.0f) * 4.0f
"#define c2PI cPI*2.0f" & @CRLF & _
"#define cPI2 cPI/2.0f" & @CRLF & _
"void _CLog(float *fR, float *fI)" & @CRLF & _;funktion
"{" & @CRLF & _
"float fRP = sqrt(*fR * *fR + *fI * *fI);" & @CRLF & _
"float fIP = atan2(*fI, *fR);" & @CRLF & _; 'printf("var2 %f\n",fIP);'& @CRLF & _
"if (fIP > cPI) fIP = fIP - c2PI;" & @CRLF & _
"*fR = log(fRP);" & @CRLF & _
"*fI = fIP;" & @CRLF & _
"}" & @CRLF & _
"void _HSVtoRGB(float fH, float fS, float fV, int *iRs, int *iGs, int *iBs)" & @CRLF & _
"{;" & @CRLF & _
"float iR,iG,iB;"& @CRLF & _
"fH = fH*6.0f;" & @CRLF & _
"float iS = floor(fH);" & @CRLF & _
"float fF = fH - iS;" & @CRLF & _
"float fP = fV * (1.0f - fS);" & @CRLF & _
"float fQ = fV * (1.0f - fS * fF);" & @CRLF & _
"float fT = fV * (1.0f - fS * (1.0f - fF));" & @CRLF & _
"switch ((int)iS) {" & @CRLF & _
"case 0:" & @CRLF & _
" iR = fV;" & @CRLF & _
" iG = fT;" & @CRLF & _
" iB = fP;" & @CRLF & _
" break;" & @CRLF & _
"case 1:" & @CRLF & _
" iR = fQ;" & @CRLF & _
" iG = fV;" & @CRLF & _
" iB = fP;" & @CRLF & _
" break;" & @CRLF & _
"case 2:" & @CRLF & _
" iR = fP;" & @CRLF & _
" iG = fV;" & @CRLF & _
" iB = fT;" & @CRLF & _
" break;" & @CRLF & _
"case 3:" & @CRLF & _
" iR = fP;" & @CRLF & _
" iG = fQ;" & @CRLF & _
" iB = fV;" & @CRLF & _
" break;" & @CRLF & _
"case 4:" & @CRLF & _
" iR = fT;" & @CRLF & _
" iG = fP;" & @CRLF & _
" iB = fV;" & @CRLF & _
" break;" & @CRLF & _
"default:" & @CRLF & _
" iR = fV;" & @CRLF & _
" iG = fP;" & @CRLF & _
" iB = fQ;" & @CRLF & _
"}" & @CRLF & _
"" & @CRLF & _
"*iRs = (int)(iR * 255.0f);" & @CRLF & _; 'printf("var %f\n",iR);'& @CRLF & _
"*iGs = (int)(iG * 255.0f);" & @CRLF & _
"*iBs = (int)(iB * 255.0f);" & @CRLF & _
"" & @CRLF & _
"" & @CRLF & _
"}" & @CRLF & _
"__kernel void domain_coloring( __global int* output,const unsigned int iW,const unsigned int iH)" & @CRLF & _
"{" & @CRLF & _
"float fRmi = -3;" & @CRLF & _
"float fRma = 3;" & @CRLF & _
"float fImi = -3;" & @CRLF & _
"float fIma = 3;" & @CRLF & _
"uint threadid = get_global_id(0);" & @CRLF & _ ;thread-id, d.h. jedes pixel von 1 bis b*h;get_global_id(0)
"float y = threadid/iH;" & @CRLF & _ ;pixelkoordinaten
"float x = threadid%iW;" & @CRLF & _ ;pixelkoordinaten
"float fIm = fIma - (fIma - fImi) * y /((float)(iH-1));" & @CRLF & _ ;...Berechnungen
"float fRe = fRma - (fRma - fRmi) * x /((float)(iW-1));" & @CRLF & _ ;...Berechnungen 'printf("var2 %f\n",fRe);'& @CRLF & _
"_CLog(&fRe,&fIm);" & @CRLF & _;
"float fHue = atan2(fIm, fRe);" & @CRLF & _; 'printf("var2 %f\n",fHue);'& @CRLF & _
"while (fHue < 0.0f) fHue = fHue+c2PI;" & @CRLF & _; 'printf("var2 %f\n",fHue);'& @CRLF & _
"fHue = fHue / (c2PI);" & @CRLF & _;warum muss man die klammern um c2PI setzen?????? 'printf("var2 %f\n",fHue);'& @CRLF & _
"float fSat = fabs((float) (sin(c2PI * sqrt(fRe * fRe + fIm * fIm))));" & @CRLF & _;
"float fVal = pow((float) fabs((float) (sin(c2PI * fIm) * sin(c2PI * fRe))), 0.3f);" & @CRLF & _;
"fVal = 0.5f * ((1.0f - fSat) + fVal + sqrt( pow((float) (1.0f - fSat - fVal) , 2.0f) + 0.01f));" & @CRLF & _; 'if (threadid==10) printf("var %f\n",fVal);'& @CRLF & _;if (threadid==10)
"if (fSat>1) fSat=1;" & @CRLF & _
"if (fSat<0) fSat=0;" & @CRLF & _
"if (fVal>1) fVal=1;" & @CRLF & _
"if (fVal<0) fVal=0;" & @CRLF & _;
"int iRc=0,iGc=0,iBc=0;"& @CRLF & _
"_HSVtoRGB(fHue, fSat, fVal, &iRc, &iGc, &iBc);" & @CRLF & _; 'printf("var2 %d\n",iGc);'& @CRLF & _
"output[threadid] = 0xFF000000+(iRc<<16)+(iGc<<8)+iBc;" & @CRLF & _ ;Pixel schreiben 0xFFBBGGRR, BB=GG=RR=t native_powr(iter,2)
"}"
;
[/autoit] [autoit][/autoit] [autoit];Daten
Global $width = 600 ;breite und höhe der gui/grafik, die Anzahl der "Threads" sollte ein Vielfaches von 16 sein!
Global $height = 600
Global $dll = DllOpen("user32.dll")
Global $mouseflag = 1
Global $fps = 0
Opt("GUIOnEventMode", 1)
Opt("MouseCoordMode", 2)
$hgui = GUICreate("Domain Coloring", $width, $height, 1, 1) ;GUI erstellen
$hdc_gui = _WinAPI_GetDC($hgui) ;HDC holen zum blitten
GUISetState()
GUISetOnEvent($GUI_EVENT_CLOSE, "_Exit")
AdlibRegister("_fps", 1000) ;FramesPerSecond
[/autoit] [autoit][/autoit] [autoit];bitmap erzeugen, in $ptr_bitmap steht nach dem Funktionsaufruf der Pointer auf die Pixeldaten
Local $ptr_bitmap, $hbmp_bitmap ;byref
$hDC_bitmap = _CreateNewBmp32($width, $height, $ptr_bitmap, $hbmp_bitmap) ;DC, Pointer auf die Bitmapdaten und ein Handle für GDI+....eine eierlegende Wollmilchsau
Global $DATA_SIZE = $width * $height ;bildgröße=anzahl pixel (rgba)
Global $NULL = 0
;ab hier gehts mit OpenCl los
;Zunächst werden die verfügbaren Geräte(Devices) gesucht.
_CL_GetDevice("ALL") ;..ALL oder CPU oder GPU, ermittelt das Gerät, auf dem die Berechnungen durchgeführt werden.
;zweiter Parameter gibt bei z.b. mehreren Grafikkarten die Nummer des Geräts an
;Puffer für die Bitmap
$output_buffer = DllStructCreate("dword[" & $DATA_SIZE & "]", $ptr_bitmap);halleluja! bitmaps werden immer 16byte-aligned!
$CL_buffer_out = _CL_CreateBuffer($output_buffer)
;Parameter an den Kernel übergeben
_CL_SetArg(0, "ptr*", $CL_buffer_out)
_CL_SetArg(1, "uint*", $width)
_CL_SetArg(2, "uint*", $height)
$CL_DEBUGFLAG = 0 ;Debug-Ausgabe ausschalten, um Geschwindigkeit zu erhöhen
[/autoit] [autoit][/autoit] [autoit]While 1 ;endless loop...
_CL_RunKernel($DATA_SIZE, 0) ;Kernel ausführen, d
_CL_ReadBuffer($CL_buffer_out, $output_buffer);Puffer(alle Pixel) lesen
_WinAPI_BitBlt($hdc_gui, 0, 0, $width, $height, $hDC_bitmap, 0, 0, $srccopy) ;Bitmap in die GUI blitten
$fps += 1 ;Frames pro Sekunde zählen
WEnd
;...das wars schon^^
[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]Func _CreateNewBmp32($iwidth, $iheight, ByRef $ptr, ByRef $hbmp) ;erstellt leere 32-bit-Bitmap; Rückgabe DC und ptr und handle auf die Bitmapdaten
;by Andy
Local $hcdc = _WinAPI_CreateCompatibleDC(0) ;Desktop-Kompatiblen DeviceContext erstellen lassen
Local $tBMI = DllStructCreate($tagBITMAPINFO) ;Struktur der Bitmapinfo erstellen und Daten eintragen
DllStructSetData($tBMI, "Size", DllStructGetSize($tBMI) - 4) ;Structgröße abzüglich der Daten für die Palette
DllStructSetData($tBMI, "Width", $iwidth)
DllStructSetData($tBMI, "Height", -$iheight) ;minus =standard = bottomup
DllStructSetData($tBMI, "Planes", 1)
DllStructSetData($tBMI, "BitCount", 32) ;32 Bit = 4 Bytes => AABBGGRR
Local $adib = DllCall('gdi32.dll', 'ptr', 'CreateDIBSection', 'hwnd', 0, 'ptr', DllStructGetPtr($tBMI), 'uint', $DIB_RGB_COLORS, 'ptr*', 0, 'ptr', 0, 'uint', 0)
$hbmp = $adib[0] ;hbitmap handle auf die Bitmap, auch per GDI+ zu verwenden
$ptr = $adib[4] ;pointer auf den Anfang der Bitmapdaten, vom Assembler verwendet
_WinAPI_SelectObject($hcdc, $hbmp) ;objekt hbitmap in DC
Return $hcdc ;DC der Bitmap zurückgeben
EndFunc ;==>_CreateNewBmp32
Func _fps()
WinSetTitle($hgui, "", "Domain Coloring " & $fps & " FPS")
$fps = 0
EndFunc ;==>_fps
Func _Exit()
Exit
EndFunc ;==>_Exit
die benötigten Includes und weitere Infos gibts HIER
//EDIT
den Kernel in eine Datei ausgelagert
// OpenCL-Kernel
// #pragma OPENCL EXTENSION cl_amd_printf : enable
#define cPI atan(1.0f) * 4.0f //PI
#define c2PI cPI*2.0f
#define cPI2 cPI/2.0f
void _CLog(float *fR, float *fI) //funktion
{
float fRP = native_sqrt(*fR * *fR + *fI * *fI);
float fIP = atan2(*fI, *fR); // 'printf(var2 %f\n,fIP);'& @CRLF & _
if (fIP > cPI) fIP = fIP - c2PI;
*fR = log(fRP);
*fI = fIP;
}
void _HSVtoRGB(float fH, float fS, float fV, int *iRs, int *iGs, int *iBs) // die int werden ByRef übergeben
{
float iR,iG,iB;
fH = fH*6.0f;
float iS = floor(fH);
float fF = fH - iS;
float fP = fV * (1.0f - fS);
float fQ = fV * (1.0f - fS * fF);
float fT = fV * (1.0f - fS * (1.0f - fF));
switch ((int)iS) {
case 0:
iR = fV;
iG = fT;
iB = fP;
break;
case 1:
iR = fQ;
iG = fV;
iB = fP;
break;
case 2:
iR = fP;
iG = fV;
iB = fT;
break;
case 3:
iR = fP;
iG = fQ;
iB = fV;
break;
case 4:
iR = fT;
iG = fP;
iB = fV;
break;
default:
iR = fV;
iG = fP;
iB = fQ;
}
*iRs = (int)(iR * 255.0f); // 'printf(var %f\n,iR);'& @CRLF & _
*iGs = (int)(iG * 255.0f);
*iBs = (int)(iB * 255.0f);
}
__kernel void domain_coloring( __global int* output,const unsigned int iW,const unsigned int iH) // der kernel
{
float fRmi = -3;
float fRma = 3;
float fImi = -3;
float fIma = 3;
uint threadid = get_global_id(0); // ;thread-id, d.h. jedes pixel von 1 bis b*h;get_global_id(0)
float y = threadid/iH; // ;pixelkoordinaten
float x = threadid%iW; // ;pixelkoordinaten
float fIm = fIma - (fIma - fImi) * y /((float)(iH-1)); // ;...Berechnungen
float fRe = fRma - (fRma - fRmi) * x /((float)(iW-1)); // ;...Berechnungen 'printf(var2 %f\n,fRe);'& @CRLF & _
_CLog(&fRe,&fIm);
float fHue = atan2(fIm, fRe);
while (fHue < 0.0f) fHue += c2PI;
fHue /= c2PI;
float fSat = fabs((float) (sin(c2PI * native_sqrt(fRe * fRe + fIm * fIm))));
float fVal = pow((float) fabs((float) (native_sin(c2PI * fIm) * native_sin(c2PI * fRe))), 0.3f);
fVal = 0.5f * ((1.0f - fSat) + fVal + native_sqrt( pow((float) (1.0f - fSat - fVal) , 2.0f) + 0.01f));
if (fSat>1) fSat=1;
if (fSat<0) fSat=0;
if (fVal>1) fVal=1;
if (fVal<0) fVal=0;;
int iR=0,iG=0,iB=0;
_HSVtoRGB(fHue, fSat, fVal, &iR, &iG, &iB);
output[threadid] = 0xFF000000+(iR<<16)+(iG<<8)+iB; //;Pixel schreiben 0xFFBBGGRR
}, dann muss nur noch eine Zeile im Script geändert werden
[autoit]Global $KernelSource = fileread("domain_coloring.cl")
[/autoit]Seeeeehr nice , was soll ich sagen....wie immer
Hi,
ich bin gerade dabei in einem Unternehmen per AutoIt diverse Vereinfachungen vorzunehmen, von einfachen Installationsscripten bis hin zu sehr komplexen Programmen.
Sicherlich könnte man das auch mit anderen Scriptsprachen umsetzen, aber AutoIt ist mir einfach am geläufigsten.
Weiterhin besteht der unschätzbare Vorteil, EXE-Dateien an den Start bringen zu können. Da freut sich der Admin, wenn er die Ausführung sämtlicher anderen Scripte verbieten kann!
Keine Angst mehr vor irgendwelchem virulenten Code, der sich in diversen *.doc oder *.xls-files verbirgt.
Wie sieht Ihr die Zukunft von AutoIT ?
Ist mir zzt. völlig schnurz, die Ziel-BS sind XP/Server2008 und Win7. Und dafür reicht die aktuelle AutoIt-Version absolut aus.
Die Powershell 3.0 ist leider nicht mit XP und Server2008 kompatibel.
HIERgibt es eine Tabelle in der die Länge der Codes nach cells/character angegeben sind (Seite 9 imho)
@James1337, nach dieser Tabelle arbeitet er ja schon....
Die 64Bit-Variante ermöglicht also einen Parameter für ErrorCorrectionLevel, die 32Bit-Variante hingegen nicht. Das finde ich ziemlich schräg.
Nein, die 32-bit-dll von UEZ funktioniert auch mit dem 5. Parameter!
BugFix , in deiner im QR_creator.au3 enthaltenen dll können nur 4 parameter übergeben werden!
IDA gibt jedenfalls nur 4 Parameter an, wenn du einen 5. übergibst....crash...
.text:10003B20
.text:10003B20 public GenerateBMPW
.text:10003B20 GenerateBMPW proc near ; CODE XREF: GenerateBMPA+2Fp
.text:10003B20
.text:10003B20 arg_0 = dword ptr 8
.text:10003B20 arg_4 = dword ptr 0Ch
.text:10003B20 arg_8 = dword ptr 10h
.text:10003B20 arg_C = dword ptr 14h
.text:10003B20
.text:10003B20 push ebp
.text:10003B21 mov ebp, [esp+arg_0]
In UEZ´s dll können 5 parameter übergeben werden....und dann funktioniert auch der AutoIt-Code
Hi,
so wie ich den c++-Code und die Delphi-Beispiele interpretiere, wirkt DestroyBuffer() nur auf die in
GetPNGW() bzw. GetPNGA() zurückgegebenen Pointer.
Der letzte Parameter in diesen beiden Funktionen enthält nach Aufruf der Funktion den Pointer bzw. die Referenz
Am allerbesten war immer (und die vermissen wir alle sehr) Freitag Morgens die "Bombi-Show" mit Jörg Bombach....wer noch nie um viertel vor Acht Frühgymnastik gemacht hat oder den großen Walatschek nicht kennt oder (mein Favorit) Manfred das Schaf, der hat echt was verpasst 
Von den Livebands in einem 10m²-Studio garnicht zu reden
HO HO HO HOOOOOO!
In der ach so besinnlichen Weihnachtszeit gibts im Radio reichlich die ewig langweiligen "Christmas"-Lieder....
Aber!
Im letzten Jahr auf der 5h langen Fahrt von Sachsen nach dem heimatlichen Rheinhessen lief im Autoradio auf unserem "Heimatsender" HR3 dann ein "Wunschkonzert". Und da haben sich einige Hörer echte akustische Schmuckstücke gewünscht!
Bis dann einer beim Sender anrief und sich ein vom HR vor einigen Jahren produziertes Weihnachtslied gewünscht hatte
Ich werde nie vergessen, wie wir (Andy, Frau und Kinder) in der Nähe von Butzbach auf der Autobahn im Stau headbangend im Auto saßen und volle Möhre mitgesungen hatten
Uff Hessisch nadierlisch
Die Personen in den benachbarten Autos müssen uns für völlig bekloppt gehalten haben 
Bestimmt habt ihr auch solch feine Versionen von bekannten Weihnachtsliedern!
Die Links bitte hier in den Thread rein und ab damit auf CD (bei Radiomitschnitten darf man das^^), damit es bei den langen weihnachtlichen Autofahrten mal was richtig auf die Ohren gibt!
Es ist völlig legitim, Scite auf deutsch haben zu wollen!
da die meisten mit der englischen Version arbeiten
wer sagt das?
und es so bei Scitespezifischen Fragen die du haben könntest zu Verständigungsproblemen kommen kann.
eben, die allermeisten können eben NICHT gut genug Englisch, genau deshalb kommt es oft zu Verständnisproblemen.
OT: Ich bin sicher, würden die meisten die (sehr gute) deutsche Hilfe benutzen, wären einige "Hilfe"-Posts hier im Forum überflüssig
Hi,
scheint so zu sein, dass RectRect den rechten und unteren Rand interpoliert
#include <GdiPlus.au3>
[/autoit] [autoit][/autoit] [autoit]$hDummy = GUICreate("",101,200)
[/autoit] [autoit][/autoit] [autoit]_GDIPlus_Startup()
[/autoit] [autoit][/autoit] [autoit]$hGraphics = _GDIPlus_GraphicsCreateFromHWND($hDummy)
[/autoit] [autoit][/autoit] [autoit]$hBitmap_20 = _GDIPlus_BitmapCreateFromGraphics(200,200,$hGraphics)
$hBitmap_16 = _GDIPlus_BitmapCreateFromGraphics(16,16,$hGraphics)
;~ $hRedBrush = _GDIPlus_BrushCreateSolid(0xFFFF0000)
[/autoit] [autoit][/autoit] [autoit]$hTileSet = _GDIPlus_ImageLoadFromFile("FFIOriginsMap9.png")
[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]$hclone=_GDIPlus_BitmapCloneArea($hTileset, 0, 0, 16,16,$GDIP_PXF32ARGB)
[/autoit] [autoit][/autoit] [autoit];_GDIPlus_GraphicsDrawImageRect(_GDIPlus_ImageGetGraphicsContext($hBitmap_20),$hTileSet,0,0,20,20)
_GDIPlus_GraphicsDrawImageRectRect(_GDIPlus_ImageGetGraphicsContext($hBitmap_20),$hclone,0,0,16,16,0,0,200,200)
_GDIPlus_GraphicsDrawImageRectRect(_GDIPlus_ImageGetGraphicsContext($hBitmap_16),$hTileSet,0,0,16,16,0,0,16,16)
_GDIPlus_ImageSaveToFile($hBitmap_16,"16.bmp")
_GDIPlus_ImageSaveToFile($hBitmap_20,"20.bmp")
_GDIPlus_ImageSaveToFile($hclone,"clone.bmp")
;shellexecute("16.bmp")
shellexecute("20.bmp")
[/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]_GDIPlus_BitmapDispose($hBitmap_20)
_GDIPlus_BitmapDispose($hBitmap_16)
;_GDIPlus_ImageDispose($hTileSet)
[/autoit] [autoit][/autoit] [autoit]_GDIPlus_Shutdown()
[/autoit]
$hclone ist definitiv einfarbig....