Hi,
Pixelsearch ist idR eigendlich schnell genug. Bei mir (2.5ghz 1680x1050) wird ein zu suchendes Pixel im Fullscreen in einigen Millisekunden gefunden. Was ist daran langsam?
Bist du sicher, dass du die richtige Farbe suchst? Ein Bild einer Webcam hat ziemlich viel "noise" (Rauschen), da hats Pixelsearch natürlich schwer, wenn du mit 20% Abweichung bei allen Farben suchst^^
Stell doch mal das Bild incl GUI hier in den Thread, incl deinem Script.
jaaaaaaaaa 
/edit/ als "alter" WC3-TDler habe ich immer die ALT-Taste gedrückt, um über den köpfen der monster den balken mit den verbleibenden lebenspunkten angezeigt zu bekommen....auf das drücken der taste kann ich aber verzichten, wenn ein permanenter Balken da wäre, würde es mir reichen^^
Hi,
ich muss mich mal reinknien, aber bei der Erstellung dieses Scriptes war mir ein Memory-leak in einer der GDI-Funktionen aufgefallen, imho _GDIPlus_BitmapLockBits(). Das wurde auch irgendwann gefixt...
Techmix,
ich habe auch einige Popupcloser erstellt, die hatten aber immer den Vorteil, dass ein eigenes FENSTER aufgemacht wurde! Also frage ich alle 100ms das Fensterhandle des obersten Fensters ab, und wenn dieses das "Popup" ist, startet erst PtB.
/EDIT/ Du hast recht, im Beispiel zu PtB fehlt ein dispose....
guck mal im PtB-Script Zeile 920/921. Da sind 2 Zeilen auskommentiert
; _GDIPlus_BitmapUnlockBits($pbitmap, $BitmapData)
;_GDIPlus_ImageDispose($pBitmap) zerstört die pixeldatastruct, daher erst später!!!
die gehören ans Ende des Beispiels-Scripts!
du solltest dir auch DeskStream 2 (Assembler Tune) anschauen,
und das Wochenende abwarten, denn wir haben eine massive Beschleunigung in der Pipeline 
und ich versteh ehrlich gesagt auch nicht, wieso Windows zu "Windoof" abgewandelt wird
die Frage war auch bestimmt nicht als Startpost für einen flamewar gedacht 
Da die Killerapplikation AutoIt auf absehbare Zeit sowieso nur Desktop-Windows vorbehalten bleibt, habe alle anderen BS ergo ein (für mich) auswahlentscheidendes Defizit
DOS 5.0 bzw das darauf aufbauende Novell-DOS 7 (netzwerkfähig) weil man ein stabiles Anwender-System hatte, ohne mehrere Bluescreens täglich
Solaris (müsste Version 2.0 oder 2.1 gewesen sein), weil es mehrere JAHRE lang ohne Eingreifen auf einer Kellermaschine lief und zuverlässig das System selbst nach längeren Stromausfällen hochfuhr und die Sripte weiterabarbeitete! Nach 7 Jahren bei mir starb die 1.Platte (nachdem die Kiste 5 Jahre als Server in einer Firma gestanden hatte), und mit ihr das gesamte System RIP
OS/400, weil es auf einer AS/400 lief, die so laut war wie ein Kampfjet und somit alle Einbrecher vertrieb, und soviel Strom verbrauchte wie 2 Tiefkühltruhen, was auch im Winter zu molliger Wärme im Computerraum führte. Starb den Heldentod, weil meine Frau sprach:"Das Ding kommt raus, SOFORT!", obwohl die Rauchschwaden aus dem Netzteil und Mainboard garnicht so dick waren.....
Win95, weil man es noch auf einer Diskette unterbringen konnte
WinXP , weil es keinen Grund zum Ärgern gibt, jedenfalls nicht aus Anwendersicht. Macht alles was es soll!
Div. Linuxe verschiedenster Distributionen, weil neue Kernel mittlerweile noch öfter als die Windows-Patch-Days erscheinen (obwohl die kein Mensch braucht, sowohl die Kernel, als auch die Windowspatches)
Das beste BS ist eins, von dem man nicht merkt, dass es da ist. Ein BS ist für den BETRIEB eines Systems da, und sonst für nichts. Anwendersoftware starten und x Tage/Wochen problemlos laufen lassen. Mal sehen, was die Zukunft bringt^^
Solange du weißt was du tust kannst du auch statt normaler Variablennamen $1, $2, $3 usw. verwenden.
Solange du weißt was du tust kannst du auch alles ohne Einrückung schreiben.
Solange du weißt was du tust kannst du deinen Code auch komplett schreiben ohne ihn in Funktionen zu modularisieren.
Kannst du alles machen - wenn du weißt was du tust.
Ab einem gewissen Code-Umfang und wenn Teile des Codes woanders her kommen wirst du es dann aber nicht mehr wissen.
Und nur darum geht es bei dieser Empfehlung.
Jedes, aber auch das noch so kleinste Windows-Programm verwendet reihenweise globale Variablen. Jede Funktion in der Windows-API benutzt globale Variablen. Globale Variablen schwirren reihenweise durch jedes Programm.
Jetzt ist es in der Verantwortung des Programmierers, diese Variablen (für andere als die gedachten Zwecke) nicht zu verwenden!
Wie will man einem AutoIt-Anfänger klar machen, dass man "keine globalen Variablen verwenden sollte", wenn allein im AutoIt-#Include-Verzeichnis tausende globale Variablen deklariert sind? Das hört sich für mich so an:
Globale Variablen sind den "Pro´s" und UDF-Erstellern vorbehalten, alle anderen sollen gefälligst kein "Global" verwenden, um Fehlern vorzubeugen....Entschuldigung, dass ich lache....das impliziert, dass im Fehlerfall der "dumme User" schuld ist..
hi,
Sie werden aber auch leicht zur Fehlerquelle, wenn man zum Beispiel eine globale Variable versehentlich oder sogar bewusst für verschiedene Zwecke benutzt....
Mumpitz!
Solange ich weiss was ich tue, kann ich globale Variablen für ALLES verwenden. Punkt.
NUR wenn man Scheiße baut, gehts in die Hose!
Etwas anderes steht auch nicht in Valiks Post! Übrigens auch nicht in allen anderen Artikeln zu diesem Thema.
Mit AutoIt hat das überhaupt nichts zu tun.
Deshalb ist auch die Empfehlung auf globale Variablen zu verzichten ehrlich gesagt nur dann sinnvoll, wenn man NICHT weiss, was man tut...jedenfalls als Einzelprogrammierer.
Anders siehts natürlich aus, wenn man im Team arbeitet.
Da siehts aber idR so aus, dass Schnittstellen definiert sind und ergo auch die zu benutzenden (globalen) Variablen AUSSERHALB von Funktionen. Diese globalen Variablen sollte man dann natürlich tunlichst NICHT als interne Variablen innerhalb von Funktionen verwenden.
Das kennt man von Assembler, da steht in der Funktionsbeschreibung, welche Register zerstört werden und welche NICHT beeinflusst werden. Stimmt diese Beschreibung allerdings nicht, ist man auch in den Hintern gekniffen . Daher retten vorsichtige Programmierer ALLE Register, bevor sie fremde Funktionen aufrufen 
Sischäärr is sischäärr
Und somit ist auch in HLL´s das Verfahren klar: in UDF´s möglichst auf globale Variablen (ausser natürlich Systemvariablen) verzichten. Sischäärr is sischäärr
@sprenger, die maximale Structgrösse steht ja Aufgrund der Auflösung fest!
Und die Länge der zu komprimierenden Daten wird ja vom Assembler in $bytes zurückgegeben.
Also reiss trancexxens Funktion in kleine Stücke und bau was passendes!
/Edit/ hatte dir ein Update der Server-ASM geschickt....
Hi,
Das heißt, ich mache mich strafbar, wenn ich meine Programme im Nachhinein mit z.B. Themida oder Softwarepassport schütze? Was ist denn das für ein Schwachsinn?
Was "Schwachsinn" ist und was nicht, ist jedem selbst überlassen! Das hat NICHTS, und absolut garnichts mit geltendem Recht zu tun.
Wenn du am Geisteszustand der versammelten Judikative in diesem Land interessiert bist, empfehle ich dir , wahllos einige Urteile aus den verschiedensten Bereichen des gesellschaftlichen Lebens im letzten Jahr herauszusuchen, und diese von unabhängigen Leuten, z.B. älteren Grundschülern, auf "Schwachsinn" bewerten zu lassen. Du würdest dich wundern....
Aber zum Thema:
Es gibt gefühlte 12 Millionen Threads zu diesem Thema, da wurde alles gesagt, und etwas neues hat sich seitdem nicht ergeben....
Allein die Fragestellung
Wo steht dass das verboten ist
zeigt, dass die Generation "Geiz ist geil!" und "Filesharing FTW!" nicht ansatzweise in der Lage ist, das System zu verstehen! Genau für diese Leute wird mittlerweile auf die Verpackung von Tiefkühlpizzen draufgeschrieben, dass man vor dem Backen bitte doch die Plastikfolie um die Pizza entfernen sollte....Und das ist trauriger Ernst! Diejenigen, die es betrifft, lesen es doch sowieso nicht....genau deshalb wird es ja auf Pizzaverpackungen aufgedruckt, bzw. unter anderem bei Software in die AGB´s geschrieben! Schizophren, oder?
Willkommen im Leben!
Das AssembleIt-include kannst du auskommentieren, die brauchst du nur, wenn du am Assemblercode etwas ändern willst, ansonsten auch einfach die Funktion SetInfo() komplett auskommentieren, aber wenns dich interessiert, HIER der Link...
funktioniert der server nun nichtmehr da mir ein include file fehlt
welches include fehlt?
ggf. Sollte man noch Pixel die sich ähnlich sind einfach mitzählen.
das wird ja automatisch erledigt, wenn die 16Bit- statt 32Bit-Darstellung des Pixels verwendet wird!
Eine weitere Idee, die du relativ einfach umsetzen kannst! Bei der Betätigung vom Mausrad im Clientfenster wäre es schön, wenn sich der Fensterinhalt bis auf die Orginal-Auflösung vergrösser würde, man hätte so zwar nur einen Bildausschnitt, aber der wäre dafür 1:1
/Edit/ weiterhin wäre es sinnvoll, wenn der Server bei einer verlorenen Clientverbindung aktiv bleibt und auf den nächsten connect wartet
Hi,
bissl was zur Technik bzgl "Kompression".
Zur Zeit ist nur eine SEHR einfache, und demnach kurze Kompression implementiert.
Die Bandbreite der Netzwerkverbindung ist wie üblich, der massgebliche Faktor! Je weniger Bytes übertragen werden müssen, desto besser!
Angefangen hatte es mit einem Vergleich zweier aufeinander folgender Screenshots Pixel für Pixel.
Die Farbe des geänderten Pixels wurde zusammen mit der Position (Adresse) des Pixels einfach aneinandergehängt, und vom Server zum Client geschickt. Dort wurde das geänderte Pixel einfach an die übertragene Adresse geschrieben. Das Datenaufkommen war daher pro geändertem Pixel 32 Bit für die Farbe und 32 Bit für die Adresse, also insgesamt 64 Bit. Wurden mehr als 50% der Pixel geändert, wurde die komplette Bitmap gepackt und verschickt.
Die 64 Bit pro geändertem Pixel habe ich folgendermassen reduziert:
Angenommen, die maximale Grösse für einen Bildschirmscreen ist 2048x2048 Pixel, das wären 2^11 mal 2^11 = 2^22 Pixel.
Die grösste Adresse wäre also 2^22, also in 22 Bit darstellbar. Die Farbe besteht aus 4 Byte AARRGGBB. Der Alphakanal ist unnötig, klasse, schon mal ein Byte weniger! Durch den "Steganographie"-Thread inpiriert, habe ich die niederwertigsten Bits pro Farbe einfach gestrichen. Das führt dazu, dass Rot=5 Bit, Grün=6 Bit und Blau=5 Bit gross ist. Insgesamt also 16 Bit für RGB.
22Bit Adresse und 16Bit für die Farbe sind 38 zu übertragende Bits/Pixel, gegenüber den 64Bit pro Pixel am Anfang eine Einsparung von 40%!
Das ist zzt. der Stand der Dinge, allerdings ist, da jedes geänderte Pixel für sich übertragen wird, seitens der Pixel noch garkeine Kompression vorhanden.
Die einfachste Methode ist, aufeinanderfolgende gleichfarbige Pixel zusammenzufassen:
100 gleichfarbige aufeinanderfolgende Pixeln benötigen jetzt 100x5Byte, also 500 Byte.
Wenn man nun die Anzahl der Pixel in einem Byte zählt, und zusammen mit den 5 Bytes Farbe und Adresse verschickt, reduziert sich so die Datenübertragung von 500 Byte auf 6 Byte....nicht schlecht für den Anfang.
Besser wird es, wenn man 2 Pixel betrachtet, und zählt, wie oft diese Kombination nacheinander vorkommt. Dann bekommt man mit einem Byte als Zähler nicht nur 255, sondern 510 aufeinanderfolgende Pixel übertragen, mit dem Vorteil, dass auch 2 unterschiedliche Pixel (und Pixelfolgen) erkannt werden. Das macht u.a. bei den Scrollbars von Fenstern Sinn, denn diese sind "gerastert" aus einem Dunklen und einem Hellen Pixel.
Die Geschwindigkeit bzw die Kompression ist noch gewaltig zu erhöhen, jedenfalls bei "normalen" Fensterinhalten. Wenn allerdings ein extrem schnell geschnittenes Video übertragen werden soll, bieten sich andere Verfahren an....wir bleiben dran!
Hi!
Und an alle die jetzt schreien wollen: BOT
Lasst es bitte bleiben.
Wieso, wenn du der erste bist, der von BOT spricht....
@TheSchadowAE, Anwendungen gibt es auch ausserhalb von Spielen, aber erstens hat JEDE halbwegs vernünftige Software (auch Spiele) diese Funktion bereits implementiert, und zweitens finde ich die Frage ansich schon lustig, ob ein INTERPRETER, der per se schon (im Vergleich) EXTREM viele Ressourcen veranschlagt, für dieses Vorhaben geeignet ist
Hi,
diese Diskussion hatten wir schon einmal , oder jedenfalls ähnlich...
abber sischäärr^^
#include <Array.au3>
$a = _Schnittpunkt_Kreis_Gerade(0, 6, 18, 12, 9, 7, 5)
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
$a = _Schnittpunkt_Kreis_Gerade(4, 0, 4, 12, 9, 7, 5) ;senkrecht, tangente
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
$a = _Schnittpunkt_Kreis_Gerade(3, 0, 3, 12, 9, 7, 5) ;kein schnittpunkt
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
$a = _Schnittpunkt_Kreis_Gerade(1, 0, 3, 0, 9, 7, 5) ;kein schnittpunkt
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
$a = _Schnittpunkt_Kreis_Gerade(0, 2, 18, 2, 9, 7, 5) ;waagrecht, tangente
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
$a = _Schnittpunkt_Kreis_Gerade(9, 0, 9, 12, 9, 7, 5) ;senkrecht
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
$a = _Schnittpunkt_Kreis_Gerade(0, 7, 18, 7, 9, 7, 5) ;waagrecht
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
$a = _Schnittpunkt_Kreis_Gerade(0, 0, 1, 1, 0, 0, 1) ;einheitskreis, 45°gerade
ConsoleWrite("Schnittpunkte = " & @extended & @CRLF) ;### Debug Console
_ArrayDisplay($a)
;liefert in @extended die Anzahl der schnittpunkte und im array die koordinaten+schnittpunkte
;wenn kein schnittpunkt, sind die Koordinaten LEER!
Func _Schnittpunkt_Kreis_Gerade($gx1, $gy1, $gx2, $gy2, $xm, $ym, $r) ;2 Punkte auf gerade, mittelpunkt, radius
Dim $a[5] ;x1,y1,x2,y2,schnittpunkte
If ($gx2 - $gx1) = 0 Then ;senkrechte gerade, sonderfall da steigung unendlich
$p = -2 * $ym ;pq-formel: y²+py+q=0
$q = ($ym ^ 2 + ($gx1 - $xm) ^ 2 - $r ^ 2) ;Lösungen y1/2=-p/2+-sqrt(p^2/4-q)
$s = $p ^ 2 / 4 - $q ;steht unter der wurzel
If $s >= 0 Then ;wurzel >=0 reell
$a[0] = $gx1 ;x1
$a[2] = $gx1 ;x2=x1
$a[1] = -$p / 2 + Sqrt($s) ;pq-formel liefert y1
$a[3] = -$p / 2 - Sqrt($s) ;pq-formel liefert y2
$a[4] = 2 ;angenommen 2 schnittpunkte
If $a[1] = $a[2] Then $a[4] = 1 ;ein schnittpunkt, tangente
Else ;wurzel<0
$a[4] = 0 ;kein schnittpunkt
EndIf
Else ;steigung gerade nicht unendlich
$m = ($gy2 - $gy1) / ($gx2 - $gx1) ;steigung
$b = $gy1 - $m * $gx1 ;y-achsenabschitt
$p = (2 * $m * ($b - $ym) - 2 * $xm) / (1 + $m ^ 2)
$q = (($b - $ym) ^ 2 - $r ^ 2 + $xm ^ 2) / (1 + $m ^ 2)
$s = $p ^ 2 / 4 - $q ;$x12=-$p/2+-sqrt($s)
If $s >= 0 Then ;wurzel >0 = reell
$a[0] = -$p / 2 + Sqrt($s) ;pq-formel liefert x1
$a[2] = -$p / 2 - Sqrt($s) ;pq-formel liefert x2
$a[1] = $m * $a[0] + $b ;y1=m*x1+b
$a[3] = $m * $a[2] + $b ;y2=m*x2+b
$a[4] = 2 ;angenommen 2 schnittpunkte
If $a[0] = $a[2] Then $a[4] = 1 ;ein schnittpunkt, tangente
Else ;wurzel <0
$a[4] = 0 ;kein schnittpunkt
EndIf
EndIf
Return SetError(0, $a[4], $a) ;@error, @extended, array
EndFunc ;==>_Schnittpunkt_Kreis_Gerade
Du Fuchs!
Lässt den Fall m=unendlich => Gerade parallel zur y-Achse einfach wegfallen 
Aber dein udf-Header ist wirklich viel schöner als meiner 
Hi,
Nach Bernds berechtigter Anfrage kam bisher nix und solange will ich da nun auch noch warten da ich sonst halt immer zu schnell Code raushaue statt dem User wirklich zu helfen in dem er es nachher selbst erstellen kann anstatt fertige Kost zu kauen.
genau wie du, hab ich natürlich auch schon eine Funktion gebastelt *man kennt doch seine Pappenheimer*
UEZ müsste nur noch ne schöne grafische Anwendung hinstellen 
;liefert in @extended die Anzahl der schnittpunkte und im array die koordinaten+schnittpunkte
Func _Schnittpunkt_Kreis_Gerade($gx1, $gy1, $gx2, $gy2, $xm, $ym, $r) ;2 Punkte auf gerade, mittelpunkt, radius
Dim $a[5] ;rückgabe x1,y1,x2,y2,anzahl schnittpunkte
Rest gibts später 
Da diskutieren die Spezialisten hier im Forum über Spezialfälle, anstatt mal eine ne universelle
_Schnittpunkt_Kreis_Gerade()-Funktion zu erstellen!
Habt ihr heute noch keinem den Arm aus der Sonne gelegt?
