Beiträge von Andy

Ich seh schon, wird Zeit, dass ich mir mal ein 64Bit BS besorge....thx fürs Testen jedenfalls!

Danke Oscar, liegt wohl daran, dass es bei 64Bit zwei der "user.dll" gibt....und ich die "falsche" benutze

eine Steilvorlage für Assemblerprogrammierer (oder die, die es werden wollen^^)
Invertieren heisst auf Bitmapbearbeiterisch nämlich XOR 0xFFFFFF
Das geht natürlich auch Pixel für Pixel in AutoIt, oder aber in Assembler
per XOR kann man nämlich direkt Speicherzellen bearbeiten (in diesem Fall invertieren)
XOR [Speicher],0xFFFFFF
invertiert somit das Pixel. Mit das einfachste, was man in Assembler machen kann

Geht auch bissl kürzer, aber so ist es verständlicher

/EDIT/ Funktioniert das so eigentlich auch in 64Bit BS?

@sprenger, bei weißem Hintergrund hast du Recht, wenn man allerdings ein Bild als Hintergrund hat, dann kopiert man nur die entsprechenden Bildteile, um die von den Ellipsen überdeckten Bereiche zu "löschen". Da sämtliche durch die GDI-Funktionen bearbeiteten Daten komplett über den Bus zur Graka geschoben werden, ist es schon ein Unterschied, ob man 1920x1080 Pixel über den Bus jagt, oder nur 50x50. Pro Frame natürlich.

Zitat

und wie?

Du weisst, an welcher Position die "alte" Ellipse gezeichnet wurde. Diese bedeckt nur einen kleinen Teil des Hintergrundes. Anstatt nun den kompletten Hintergrund (Backbuffer) mit dem Hintergrund zu überschreiben um die winzige Ellipse zu "löschen", überschreibt man nur den Teil des Hintergrundes, der von der Ellipse bedeckt wird.
Wenn deine Ellipse 30x30 Pixel gross ist, kopiere aus dem Hintergund die Fläche an der Position der Ellipse (30x30 Pixel) in den Backbuffer und danach die "neue" Ellipse.

In AutoIt könnte es damit irgendwann kritisch werden, da der Verwaltungsaufwand bzw der Overhead der GDI-Funktionsaufrufe bei vielen kleinen Sprites die Geschichte eher verlangsamt. Aber wer "richtig schnell" Grafiken darstellen möchte, dem bleibt nur übrig, so wenige Pixel wie möglich zu bearbeiten.

Zitat

Ich bräuchte eine asm-Funktion die WinApi_StretchBlt ersetzen kann, aber schneller ist

ja, das wäre sicher machbar, allein durch SSE wäre da einiges rauszuholen. Wozu brauchst du etwas derart schnelles? Stretchblt() hat jedenfalls bei mir noch nie für Verzögerungen gesorgt, da hängts grösstenteils an ganz anderen Punkten
Ich muss erstmal die anderen Baustellen fertigbekommen...

hi,
wie du schon bemerkt hast, überschreibt _GDIPlus_GraphicsClear nur den bestehenden Graphic-context mit einer Farbe.
Du musst dein Bild benutzen, um darauf die Ellipsen zu zeichnen.
Bild in Backbuffer, Ellipsen in Backbuffer, aklles weitere in Backbuffer, zum Schluss Backbuffer in GUI kopieren.

/edit/ wenn es zu langsam ist, immer das komplette Bild in den Backbuffer zu zeichnen, erstelle eine Kopie des Bildes und kopiere immer nur den kleinen Teil, der durch die Ellippsen überschrieben wurde.

Zitat

Mit der linearen Funktionsgleichung ist es gut umsetzbar für den linken Strahl aber nicht für den rechten
weil der bei ($Width|$Height) anfängt und auf ($Mouse[0]|$Mouse[1]) geht.

wieso?
Der Geradengleichung y=mx+b ist es völlig schnurz, welche Koordinaten gewählt werden. Bis auf den Fall, dass delta x = 0 ist (Gerade senkrecht zur x-Achse) sollte es kein Problem geben!

Hi zusammen,
dass der Lock/Unlock ziemlich viel Zeit verbraucht, hatte ich schon bei anderen Aufgaben bemerkt. Leider ist mir bisher keine andere Variante untergekommen, um den Pointer auf die Bitmapdaten zu bekommen. Ich hatte schon daran gedacht, das "Handle" auseinanderzuklabustern. Ein Handle ist ja nichts weiter als ein Zeiger auf einen Speicherbereich mit Informationen. Irgendwo in diesem Speicherbereich muss zwangsläufig auch die Adresse der Bitmap stehen. Wenn da jemand bissl Zeit in reverse engeneering investieren würde, wäre das sehr zu begrüssen
name22
hast du schon versucht, die Bitmaps zu blitten? Das ist idR ziemlich schnell, mit etwas Glück unterstützt der Treiber der Graka das Blitten.

naja, die beiden verwendeten Prospeed-Funktionen sind derart simpel, die kann ich bei Bedarf in 10-20 Zeilen Asm unterbringen.
Ggf sogar in eine mini-Dll packen. Da geht was
Wobei die Geschwindigkeit auch mit "native" AutoItcode ausreichend sein sollte, jedenfalls für "normale" Anwendungen

Zitat

au man, was ist denn mit euch los ? oder macht ihr alles späße ?

Völliger Ernst das alles ist, junger Padawan!

Zitat

und entdecke dass es einen "echten" kompiler für AutoIt Skripte gibt der automatisch alle Variablen richtig deklariert und castet und eine richtig "echte" asm-Exe daraus macht. xD

Naja, eine "richtige" Exe hat man doch heute schon. Das Argument der Größe lasse ich nur in absoluten Ausnahmefällen gelten, wenn das so wichtig wäre, gäbe es wesentlich mehr *.COM-Dateien

Zitat

C++ Code.
Der wird dann Kompiliert.

Kompilieren kann man jeden Code, das ist nicht das Ding! Aber so zu kompilieren, dass es JEDER Anforderung gerecht wird, ist das Problem! Genaue Berechnung oder schnelle Berechnung bissl schnell oder ungenaue Berechnung und ganz schnell?
C++ ist da ein hervorragendes Beispiel! Da wird lauthals die Portabilität hervorgehoben, aber wenn es "wirklich" mal drauf ankommt, kommt man nicht drumherum vom "Standard" abzuweichen, und auf für die jeweilige Plattform optimierte Libs einzusetzen. Und/oder hunderte Compilerschalter vorzusehen, die auch noch grösstenteils voneinander abhängig sind und jeweils andere Ergebnisse produzieren...

Da bleibe ich lieber bei meinem AutoIt-Spaghetticode, undeklarierten Variablen unbestimmten Typs und "eingeschränkter" Geschwindigkeit, die übrigens in 99% aller Fälle völlig ausreiched ist. Ich bin Techniker, kein Programmierer. Das Ergebnis zählt. Und Leistung = Arbeit pro Zeit. In 15 Minuten ein "Script" incl benutzbarer Oberfläche erstellen zu können, welches mir und meinen Mitarbeitern die Arbeit erleichtert, ist m.E. mehr Wert als "Portabilität".

Zitat

Was auch gehen müsste was Java (auch wenn ich es persönlich nicht mag ) uns vorgemacht hat:
Einen Installierbaren Interpreter der wesentlich schneller interpretieren kann als der Jetzige von AutoIt.

Zieh mal 2000 Programmierer von Sun ab, in ca 10-15 Jahren hast du dann auch ein "schnelles" AutoIt
Nein, mal im Ernst, Java ist der Weg, und auch an der Idee von .Net ist was dran. Anders ist wirkliche Portabilität nicht machbar. Und das ist gut so! Aber Moment, irgendeiner hat doch was von Dateigrösse gesagt ....

Zitat

Andy: Man, jetzt hast du die ganze Verschwörungstheorie widerlegt.

nöööö, das war doch nur ein kleiner Stupser in die Richtung, wie man dieses Logo aus dem "Memory" (sic) extrahieren und anzeigen könnte.
Kürzestes Script gewinnt!

....oder einfach nur das(die) Logo-Icons in einem 16(32)-Bit-Farbformat....
Irgendwo müssen diese Dinger ja herkommen, oder hat sich bisher noch keiner gefragt, woher das Icon kommt, dass nach einem herzhaften Hieb auf F5 unten in der Taskleiste steht?

Bitmap-Format FTW

Hallo,
wahrscheinlich gibt es ein mir nicht bekanntes Problem mit der Prospeed.dll (welches System?).Ggf funktioniert diese nicht auf 64Bitsystemen.
Du kannst aber auch mit etwas Verzicht auf Geschwindigkeit die prospeed.dll im Verzeichnis löschen. Dann läuft reiner AutoItcode, auch unter 64Bit.

Hi,

Zitat

Hast du schon das Scrollen innerhalb von Browsern realisiert?!?

In den ersten hier geposteten Versionen war es noch enthalten, ich hatte es rausgenommen weil ich es a) den Browsergame-Fernsteuerungen nicht allzuleicht machen wollte , und b) die Abfrage "Seitenende" nicht besonders zuverlässig in allen Fällen funktionierte (bei allen Browsern).

Zitat

Weil bei meiner XP Maschiene muss ich immer manuell innberhalb der Seite einen Scroller nach unten verschieben bevor der zu klickende Button sichtbar wird.

Simple Lösung: ein SEND pgdn, nachdem das Browserfenster mit der neuen Seite geöffnet wurde
Ich hatte schon mit div. Scroll-udf´s herumexperimentiert, wie gesagt, Browser sind da manchmal bissl eigen...besonders mit der Rückmeldung, ob das pgdn ausgeführt wurde. Man könnte natürlich abfragen, ob sich der Seiteninhalt geändert hat .

Allerdings sind meine Anwendungen noch nicht zeitkritisch, solange das Programm schneller ist als jeder Mensch der im 3-Schichtbetrieb 8h lang auf den Monitor stiert, habe ich keinen Handlungsbedarf.

Zitat

Und ist es so richtig das ich immer '_GDIPlus_Startup' und '_GDIPlus_Shutdown' Manuell ausführen muss,

Die Beispiele sollten alle laufen, ich habe hier schon lange nicht mehr geupdatet, der "Bedarf" scheint nicht sehr gross zu sein, wenn man nicht die gängigen "bösen" Begriffe in den Postings hier im Forum spammt

Hallo Webfish,

Zitat

Umsatz Januar war 12.000

ist es richtig, dass du den fetten Teil des Textes suchst?
Wenn das so sein sollte, gibt es maximal 12 mögliche Suchstrings, nämlich die Monatsnamen.
Schau dir für diesen Fall mal das Programm PushTheButton an. Damit wäre es z.B.möglich, die 12 Texte "Umsatz war Januar","Umsatz war Februar" usw. von der Website einmalig "abzufotografieren", und diese gespeicherten Bilder dann automatisch auf der Website suchen zu lassen.
Die Suche gestaltet sich relativ zügig, die 12 Monatanamen sind auf einer Website incl. automatischem Scrollen im Browser in weniger als einer Sekunde gefunden.

/EDIT/ sry, hatte überlesen, dass der Text schon vorliegt

kurzes Beispiel, in der Console werden die Millisekunden ausgegeben

Hallo!

Zitat

Ich versuche so eine Uhr wo immer 1000 mikrosekunden dazu gerechnet werden.
Genau das ist das wo für ich hilfe brauch. Ich verstehe nicht wie man die Aktuellezeit in Mikrosekunden umrechnet.

Um die Mikrosekunden zu errechnen, teilt man einfach die ermittelten Sekunden durch 1000000.
Die Frage ist allerdings, ob du es schaffst, jede Mikrosekunde auch anzeigen zu lassen!
Also einen Timer, der jede Sekunde in 1000000 Teile teilt und diese dann innerhalb dieser Sekunde hochzählt.
Viel Spass dabei!
Das Problem dabei ist, dass das Betriebssystem dir dein Programm regelmäßig unterbricht, um auch andere Programme "gleichzeitig" laufen zu lassen. Diese Unterbrechung wirft natürlich alles an genauer Berechnung im Mikrosekundenbereich über den Haufen.
Eine weitere Möglichkeit wäre, die Prozessor-Takte seit dem Rechnerstart abzufragen. Mit einer (internen) Umrechnung ist das genau das, was

Timerinit() Timerdiff()

machen. Aber einzelne Mikrosekunden einzufangen wirst du nicht schaffen....

1000 Mikrosekunden sind 1 Millisekunde, da sollte das wenigstens Ansatzweise möglich sein....

Um das abschliessend auch meinerseits mal klarzustellen, die Frage lautete:"Kann man bei ImageSearch auch Bilder mit unsichtbarem Background benutzen?"
Genau diese Frage wurde bereits gefühlte 12 Millionen Mal sowohl in diesem Forum, als auch im "bösen" Botforum, im englischen und im französischen Forum gestellt und dort auch beantwortet.
Aus diesem Grund auch mein Hinweis mit der erlesenen Gesellschaft in der du dich befindest. Anderen geht es genauso!
Natürlich ist mir klar, dass jemand bevor er hier einen Thread erstellt, zunächst die Suchfunktion der Foren und auch die Tante Google bemüht. Ich gehe also davon aus, dass du geflissentlich sämtliche dort gefundenen Hinweise und Lösungsvorschläge einfach ignorierst.

Somit wäre eigentlich die passende Antwort auf "Kann man bei ImageSearch auch Bilder mit unsichtbarem Background benutzen?", ein einfaches "JA!" gewesen. Wäre damit dein Problem gelöst gewesen?! Offensichtlich nicht.

Kurzes Beispiel, wie exterm SSE die Geschwindigkeit beeinflussen kann!

Leider gibt es einen kleinen Pferdefuss, den ich bisher noch nicht lokalisieren konnte.
Die hex-Ziffern werden leider nur bis zur ca. 550. Stelle richtig berechnet. Ab der 550. Stelle schleicht sich ein minimaler Fehler ein, der dazu führt, dass die folgenden Ergebnisse falsch werden.
Ob das schon mit dem einfachen float-Format (32bit) zu tun hat, werde ich untersuchen.

Jedenfalls ist die Geschwindigkeit sagenhaft, da ein komplettes $Array[4] in einem XMM-Register Platz hat und so alle Berechnungen für jeden Teilnehmer im Array durchgeführt werden.
bsp Multiplikation zweier Arrays $a[4] und $b[4]:
$a[0]=$a[0]*$b[0]
$a[1]=$a[1]*$b[1]
$a[2]=$a[2]*$b[2]
$a[3]=$a[3]*$b[3]
wird zu
mulps xmm0,xmm1 ;jeweils gefüllt mit 4 floats
und das wird in einer Handvoll Takte berechnet.

Die millionste Stelle wird vom Script so in weit unter einer Sekunde ermittelt! Wobei man fairerweise zugeben muss, dass ab der ca. 5000. Stelle die Genauigkeit der floats sowieso nicht mehr ausreichend ist. Vielleicht weite ich das Script ja noch auf 64Bit Genauigkeit aus.....schaumamal^^

Man merkt mal wieder deutlich das geistige Defizit bei der Problembeschreibung! Aber tröste dich, du befindest dich in erlesenster Gesellschaft!

Um mal den "Apparat", der sich idR zwischen den Ohren befinden sollte, bissl anzutreiben:
Wer zwingt dich denn, mehr an Daten (Pixel) abzufragen, als du eigentlich brauchst?

Um mal bei deinem Beispielicon Trashbin mit transparentem "Hintergrund" zu bleiben, wo ist das Problem nur die Pixel zu suchen, die NICHT transparent sind?
Bei mehrteiligen, weil durch transparente Flächen unterbrochenen Suchmasken, macht man halt mehrere "kleine" Abfragen!
Das bedeutet natürlich Aufwand und vor allem Knowhow!

Mit PushTheButton (such mal danach hier im Forum) finde ich im täglichen Einsatz sogar bewegte Bilder mit transparentem Hintergrund. Imagesearch kann das mit Sicherheit auch!
Auf eine C&P-"Lösung" musst du allerdings lange warten....