Beiträge von Andy

Zitat von Musashi

Spaßvogel . Ausgerechnet mein Hauptkandidat dem ich das zutrauen würde stellt diese Frage.

Hehe, ich hatte einmal vor Jahren an einem Wochenende damit angefangen, einfachste Scripte auf Maschinenebene mittels Debugger zu "analysieren". Da sieht man auch schon nach einigen Minuten kein Land mehr...

Für mich am schlimmsten war, dass ich, infolge keinerlei Kenntnis des Quellcodes, auch keinerlei Rückschlüsse auf Programmabläufe schließen konnte. Ich hatte Anfang der 90er im vorherigen Jahrhundert selbst (einfache Basic-) Interpreter und auch lauffähige X86-Assembler geschrieben, daher war mir klar, auf was ich mich einlasse^^

Irgendein Cleverle könnte jetzt ja sagen:" Hey, der "Fehler" im Code kommt doch von der MsgBox-Funktion, du musst doch nur den Einsprung in die (user32.dll-) MessageBoxW-Funktion finden, um dort "in der Nähe" entsprechend zu suchen!"

Gute Idee, aber der Compiler kracht den Code zu mit unendlich vielen "Absicherungen", und packt dazu noch unendlich viele Funktionen in den Code, die das zu interpretierende Script irgendwann ggf. mal gebrauchen könnte(!). Der Compiler würfelt das dann auch noch fleissig durcheinander (aka optimiert) und fertig ist das Code-Chaos.

Letztendlich besteht eine AutoIt-EXE ja aus mehreren hundert Kilobytes Code, auch wenn nur ein einfachstes Script zu interpretieren ist!

Ein "reines", bspw. in C erstelltes Programm, welches letztendlich aus einer Handvoll Kilobytes Maschinencode besteht, ist in einigen Stunden komplett "zerpflückt".

Zitat von alpines

Hat jemand vielleicht ein System zur Hand auf dem er kurz verschiedene AutoIt-Versionen installieren kann? War das schon mit älteren (3.3.10.2, 3.3.8.1, 3.3.6.0 und co. so?)

Eben getestet, Win Server 2012 mit AutoIt 3.3.8.1 völlig unauffällig, die Schleife ist vor und nach der Msgbox gleich schnell. Morgen kann ich das Verhalten auch noch auf Win7 und XP testen.

Übrigens zeigt das kompilierte 3.3.8.1-Script unter Win10 auch das Verhalten, dass die erste Schleife ca. 8-10x schneller läuft wie die zweite nach der MsgBox.

Ergo: WIN10 ist das Problem.

Zitat von alpines

Solche "Benchmark"-zahlen sind ja schön und gut, aber kann das bitte jemand mal in einem realistischeren Szenario testen?

Wo liegt denn genau das Problem? Werden Befehle generell langsamer ausgeführt? Brauchen Zeilen länger zum interpretieren?

Ich quote mich dazu mal selbst...

Zitat von Andy

In diesem Jahr hatte ich schon etliche Infos von Usern bekommen, welche Probleme mit von mir erstellten Scripten hatten, die seit Jahren unverändert einwandfrei liefen und plötzlich (überwiegend Laufzeit-) Probleme machten.

WENN das ein Windows-Problem sein sollte, dann eines, dass einer Handvoll User in einem Scriptforum aufgefallen ist. Sehr unwahrscheinlich imho...

Da gibt es hunderttausende, wenn nicht Millionen Entwickler/User weltweit, die das letzte Quentchen Leistung aus ihrer Software rausholen (müssen) und keinem fällt etwas auf? Sehr unwahrscheinlich imho...

Was allerdings sein könnte, wären eine "Änderungen" am Windows-Code, welche nur speziel(lst)e Anwendungen, wie bspw. einen "bestimmten" Script-Interpreter, beeinflussen.

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages.

//EDIT

Zitat von Oscar

das _ArrayDisplay auskommentiert und stattdessen nur das About-Fenster von Windows öffnet (per DLL-Call), dann passiert dieser Performanceeinbruch trotzdem.

Das war in dem von mir geposteten Script zur AutoIt-Msgbox / user32dll-Messagebox ja identisch.

Ich denke schon, dass der "Fehler" in irgendeiner Art und Weise im AutoIt-Compilat liegt.

Zeit für ein Debugging des ausgeführten Codes zur Laufzeit....jemand fit in Assembler und Debugging?!

Zitat von Musashi

Na ja, das geht wohl z.T. auf meine Kappe. Ich habe die Aussage von Jos :

Ging ja nicht gegen dich :o)

Die Adresse ist ganz klar Jos! Es werden seit Jahren eigentlich "native" Funktionen so hingebogen, dass diejenigen Funktionen, welche gerne von den "Power-Usern" (das hat jetzt weniger mit dem Titel in unserem Forum zu tun^^ ) benutzt werden, gegenüber den "einfachen" Funktionen (wie sie das "gemeine Volk" benutzen) besser abschneiden!

Die künstliche Verlangsamung fast sämtlicher String-Funktionen war schon vor etlichen Jahren nachweisbar. Die kamen (damals) den (etwas komplexeren aka "langsamen") REGEXen Geschwindigkeitsmäßig wohl zu nahe. Da kamen im Forum immer wieder Dämpfer in Richtung der Regex-Verwender, dass das Problem des "einfachen" Users auch mit "einfachen", in diesem Fall String-Funktionen, zu lösen ist. Aber irgendwie muss man ja die sog. "Elite-Programmierer" bei der Stange halten....

Um jetzt beim Thema zu bleiben, die Baustelle(n) in AutoIt sind längstens bekannt.

Wobei auch bestimmt Windows einen dicken Anteil am "seltsamen" Verhalten einiger Scripte trägt.

In diesem Jahr hatte ich schon etliche Infos von Usern bekommen, welche Probleme mit von mir erstellten Scripten hatten, die seit Jahren unverändert einwandfrei liefen und plötzlich (überwiegend Laufzeit-) Probleme machten.

Ich habe das immer unseren (am Anschlag laufenden) Servern in die Schuhe geschoben. Wohl auch, weil VBA-Scripte in Excel ähnliche Probleme zeigten....

Hehe, da hat wohl einer der zehntausend Windows-Entwickler wohl im Compiler ein falsches Häkchen gesetzt....und das neue(ste) Update reißt bis dahin völlig einwandfrei laufende Systeme in den Abgrund...schaumamal, ob daraus noch irgendwann etwas Gutes wird

Zitat von Musashi

Da MsgBox lt. Jos nur ein Standardaufruf der Windowsfunktion MessageBox ist,

Wer schreibt denn diesen Scheiß?

Da geh ich wieder ab wie Schmitt´s Katze....

Definitiv ist nicht auch nur annähernd ein "Standardaufruf" abgebildet!

https://docs.microsoft.com/en-us/windows/…user-messagebox

DAS ist der Standardaufruf!

Bei der AutoIt-"Msgbox ist der 4. Parameter, also "timeout" hinzugefügt.....

Was allerdings absolut nichts am Ergebnis ändert!

Der DllCall der userdll32-MessageBox-Funktion führt bei mir zu identischem Zeitverhalten wie der Aufruf der AutoIt-Msgbox-Funktion...

wzbw....

ConsoleWrite("> ------------------------------------------" & @CRLF)
ConsoleWrite("> >>>>> Check 1.1 - Calc() vor MsgBox <<<<< " & @CRLF)
_Calc() ; vor Aufruf einer MsgBox
;~ MsgBox(0, "Testbox", "einfach OK klicken",1)
$aResult = DllCall("user32.dll", "int", "MessageBox", "hwnd", 0, "str", "A", "str","B","int",1)
ConsoleWrite("> >>>>> Check 1.2 - Calc() nach MsgBox <<<<<" & @CRLF)
_Calc() ; nach Aufruf einer MsgBox
ConsoleWrite("> ------------------------------------------" & @CRLF)

Func _Calc()
    Local $iTime, $iValue = 0
    $iTime = TimerInit()
    For $i = 1 to 5000000
        $iValue += 1
    Next
    $iTime = TimerDiff($iTime)
    ConsoleWrite("! " & StringFormat("% 15s: %4.3f ms", "Elapsed time = ", $iTime) & @CRLF)
EndFunc   ;==>_Calc

> ------------------------------------------

> >>>>> Check 1.1 - Calc() vor MsgBox <<<<<

! Elapsed time = : 1506.213 ms

> >>>>> Check 1.2 - Calc() nach MsgBox <<<<<

! Elapsed time = : 8359.865 ms

> ------------------------------------------

//EDIT

autoiter

seltsam, deine Schleife läuft vor der Msgbox viel schneller als bei mir, aber danach wesentlich langsamer!

Hi,

ich hatte vor Äonen (imho 2009, also vor 11 (ELF!) Jahren^^) mal etwas zu diesem Thema verfasst:

RE: Tutorial: Wie man Script-Fehler erfolgreich sucht/findet bzw. richtig debuggt

Musashi hatte mich 2016 darauf hingewiesen, das der Link aus meiner Sig nicht mehr funktioniert.....hiermit (nach immerhin 3 Jahren^^) behoben. Danke für den Hinweis!

//EDIT Ja leck! 13 Minuten zu spät

Btt:

Ich benutze in "anderen" Script- und auch Compilersprachen zum Debugging (fast) ausschließlich Msgboxen. Neulich sollte ich ein mir bis dato unbekanntes Javascript debuggen, und hatte dazu den in Opera (meinem Browser) integrierten Debugger benutzt. Feine Sache das....

Aber in AutoIt hätte ich die äquivalenten "Fehler" mit den hier benutzbaren Werkzeugen aus Scite ggf. schneller gefunden.

Im Großen und Ganzen ist zu diesem Thema nur eins zu sagen:

Ich zitiere mich aus dem o.g. Thread:

Zitat

Im Prinzip ist "Debugging" eine Erfahrungssache, sichtbar hier im Forum. 99% der hier mit "funktioniert nicht" geposteten Scripte sind durch simpelstes Debugging, wie im Startpost schon erwähnt, auch von Anfängern lös- und somit vermeidbar! Die "Cracks" machen definitiv nichts anderes, kaum jemand "fliegt die Lösung einfach so zu".

Man muss es einfach machen!

//EDIT Ich hatte für AssembleIt einen (32Bit-) Debugger geschrieben, so einen SCHEI** macht man nur ein Mal im Leben!

Ich hatte mir schon mehrfach überlegt, diesen Debugger auf 64Bit-ASM auszubauen, aber mir fehlen einfach die geschätzten 20 Monate permanente Zeit dafür!

Ich bin ja auch nur ein Hobby-Coder....vielleicht mal, wenn ich in Rente bin

Hi,

Zitat von Norman Bates

So wie es in Excel einfüge,

Excel bietet mindestens 2-3 Handvoll Möglichkeiten, etwas "Einzufügen".

https://support.office.com/de-de/article/kopieren-und-einfügen-spezifischer-zellinhalte-a956b1c3-cd5a-4245-852c-42e8f83ffe71

Rechtsklick auf die Zelle und "Einfügen" dann "Werte" fügt idR. den reinen kopierten Text in die Zelle/Bereich ein .

//EDIT

UEZ war schneller....so ist das, wenn man die Posts erst Stunden/Tage nach dem Editieren los schickt

Hi,

ich hatte die Idee, dein Programm auf "oldschool"-GDI umzuschreiben.

Sourcecode ist ca halb so lang, dafür doppelt so schnell^^

Es wird eine Bitmap in den DC des Fensters erstellt, die Funktion dazu liefert den Pointer auf die Pixel. Über eine DllStruct() an der Position dieser Bitmap kann man nun per DllStructSetData() direkt "Pixel" schreiben.

Leider gibt es keinen Datentyp "BIT" in der DllStruct(), um eine 1-Bit-Bitmap über die DllStruct() mit Daten füttern zu können, deshalb habe ich eine "normale" 32-Bit-Bitmap (die ist 32x so groß wie eigentlich benötigt wtf) verwendet.

Und ja, wer noch eine "sehr" (ca. 10 Jahre) alte AutoIt-Version hat, der kann sich über noch mehr Geschwindigkeit freuen, im Zuge der "Weiterentwicklung für PRO-Scripter" hat man nämlich damals sämtliche nativen String- und DllStruct-Funktionen in AutoIt verlangsamt, um die PRO-Funktionen (bspw. RegEx aka PCRE) Geschwindigkeitsmäßig besser aussehen zu lassen.....die entsprechenden Threads dazu hier im Forum sind wie so viele andere im Nirvana verschwunden...

#include <GDIPlus.au3>
#include <GUIConstantsEx.au3>
#include <StringConstants.au3>

Global Const $I_GUI_WIDTH = 1024
Global Const $I_GUI_HEIGHT = 768

Opt("GUIOnEventMode", 1)

#cs
    Interessante Rules

    Rule 126 = Sierpinski Dreieck
    Rule 122 = Schachbrett
    Rule 118 = Schattierte Pyramide

    Rule 137 = Invertiertes Rule 110
#ce




Global Const $I_RULE = 110
; max. 8 bit => 255

Global $oRule = ObjCreate("Scripting.Dictionary")

For $iBitA = 0 To 1
    For $iBitB = 0 To 1
        For $iBitC = 0 To 1
            Local $iCurrentBit = BitShift(1, -(BitShift($iBitA, -2) + BitShift($iBitB, -1) + BitShift($iBitC, -0)))
            $oRule.Add($iBitA & $iBitB & $iBitC, BitAND($I_RULE, $iCurrentBit) ? 1 : 0)
        Next
    Next
Next

Global $hGUI = GUICreate("Rule " & $I_RULE, $I_GUI_WIDTH, $I_GUI_HEIGHT)
GUISetOnEvent($GUI_EVENT_CLOSE, ExitApp)
GUISetState(@SW_SHOW, $hGUI)

$DC_gui = _WinAPI_GetDC($hGUI)             ;DeviceContext der GUI holen
Global $ptr, $hbmp                        ;pointer auf die pixel, handle bitmap
$DC_bitmap = _CreateNewBmp32($I_GUI_WIDTH, $I_GUI_HEIGHT, $ptr, $hbmp);bitmap erstellen

$pixels=dllstructcreate("int[" &  $I_GUI_WIDTH*$I_GUI_WIDTH &"]",$ptr)      ;dllstruct an der stelle der Bitmap erstellen


;Ausgangssituation! Für Rule 110 die letzte Spalte in der ersten Zeile 1 setzen.
;Es ist hier in die Mitte gesetzt um es nicht ständig umsetzen zu müssen.
;Interessante Muster kommen auch raus wenn man mehrere Startpunkte 1 setzt ;)

dllstructsetdata($pixels,1,0xFFFFFE,$I_GUI_WIDTH/2)

$t=TimerInit()
For $iColumn = 0 To $I_GUI_WIDTH - 1
    dllstructsetdata($pixels,1,dllstructgetdata($pixels,1,$iColumn),$iColumn)
Next

For $iRow = 1 To $I_GUI_HEIGHT - 1
    Local $tmrRow = TimerInit()

    For $iColumn = 0 To $I_GUI_WIDTH - 1

        $col=0xFFFFFE *GetNextGeneration($oRule, $iRow, $iColumn)
        dllstructsetdata($pixels,1,$col,$iRow*$I_GUI_WIDTH+$iColumn)

    Next
    _WinAPI_BitBlt($DC_gui, 0, 0, $I_GUI_WIDTH, $I_GUI_HEIGHT, $DC_bitmap, 0, 0, 0xCC0020);$srccopy

Next
    msgbox (0,0,timerdiff($t))
While Sleep(10)
WEnd

Func GetNextGeneration(ByRef $oRule, ByRef $iRow, ByRef $iColumn)
    Local $iLeft, $iCenter, $iRight

    $iLeft=($iColumn = 0) ? 0 : (dllstructgetdata($pixels,1,($iRow - 1)*$I_GUI_WIDTH+($iColumn - 1))/0xFFFFFE)
    $iCenter=dllstructgetdata($pixels,1,($iRow - 1)*$I_GUI_WIDTH+($iColumn))/0xFFFFFE
    $iRight=($iColumn = $I_GUI_WIDTH - 1)?0:dllstructgetdata($pixels,1,($iRow - 1)*$I_GUI_WIDTH+($iColumn+1))/0xFFFFFE

    Return $oRule.Item($iLeft & $iCenter & $iRight)
EndFunc

Func ExitApp()
    _WinAPI_DeleteDC($DC_gui)
    _WinAPI_DeleteObject($hbmp)
    $ptr = 0
    Exit
EndFunc



Func _CreateNewBmp32($iwidth, $iheight, ByRef $ptr, ByRef $hbmp) ;erstellt leere 32-bit-Bitmap; Rückgabe $HDC und $ptr und handle auf die Bitmapdaten
    $hcdc = _WinAPI_CreateCompatibleDC(0) ;Desktop-Kompatiblen DeviceContext erstellen lassen
    $tBMI = DllStructCreate($tagBITMAPINFO) ;Struktur der Bitmapinfo erstellen und Daten eintragen
    DllStructSetData($tBMI, 1, DllStructGetSize($tBMI) - 4);Structgröße abzüglich der Daten für die Palette
    DllStructSetData($tBMI, 2, $iwidth)
    DllStructSetData($tBMI, 3, -$iheight) ;minus =standard = bottomup
    DllStructSetData($tBMI, 4, 1)
    DllStructSetData($tBMI, 5, 32)        ;32 Bit = 4 Bytes => AABBGGRR
    $adib = DllCall('gdi32.dll', 'ptr', 'CreateDIBSection', 'hwnd', 0, 'ptr', DllStructGetPtr($tBMI), 'uint', 0, '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

Zitat von xSunLighTx3

Der Code ist hammerhart zu interpretieren.

Naja, ich dachte eigentlich, die Kommentare seien für einen Programmierer gut zu verstehen. Und exzessiv Zeilen eingespart habe ich auch nicht.

Zugegebenermaßen ist das nichts, was man auf Anhieb durchschaut. Wenn man die Idee dahinter versteht, ist es viel einfacher.

Zitat von autoiter

das ist ja kürzer als das Beispiel zu GUICtrlCreateButton.

...ich erinnere nur an den Sudoku-Solver in 62 Bytes. Leider sind die Beiträge dazu wohl für immer im Forums-Nirvana verschollen oder schon ins NUL-Device geschoben worden....

Hi,

Zitat von Racer

Nachdem ich nicht jünger werde und die Uhr von Windows recht klein

hehe, willkommen im Club.....

Meine Uhr ist ein bissl größer, kommt aber dafür mit weniger als 50 Zeilen Code aus. Und ja, die Erzeugung und Darstellung der Ziffern ist hardcore Scriptporn. Wer das Bitgeplänkel verstehen möchte, sollte sich einige Blätetr Papier und einen Bleistift besorgen und benutzen :o)

Digitaluhr.zip

Zitat von Mars

ch verstehe einfach nicht wie die Antivirenhersteller so unfassbar bescheuert sein können

Wie? Hab ich was verpasst? Antivirenhersteller bescheuert?!

Was ist denn mit den Leuten, für die diese Software überhaupt gemacht wird?! Wie Leute, die diesen Thread erstellen beispielsweise....und die, die darauf antworten mit derselben "Message":

*********************************************

"Na klar hab ich nen Antivirenprogramm, ÜBERALL lauern schliesslich Viren, Ich treib mich schliesslich auf sämtlichsten zwielichtigen Internetseiten rum, doppelklicke jedwegen Link in an mich gerichtete Emails, installiere Software, die ich "umsonst" runtergeladen habe, hab Flash und Javascript im Browser IMMER angeschaltet, weil sonst die schon von mir oben genannten "Alda ich schwör, die Website hier ist GARANTIERT Virenfrei!!!!!"-Programme "natürlich" nicht laufen.

Dass ich überall im Netz meine sämtlichen persönlichen Daten in alle verfügbaren Anmeldeformulare eintrage, weil es dort einen "Bonus" dafür gibt, ist doch selbstverständlich, machen die anderen doch auch...

Natürlich benutze ich auch einen Passwortsafe ("gesichert" durch eine 4-stellige PIN) damit ich nicht auf jeder Website irgendwelche esoterischen Passwörter eingeben muss. Für die 478 Websiten, in denen ich angemeldet bin, wäre das auch sonst ziemlich dumm gelaufen!

Vergessen darf man aber auch nicht die ganze Software auf dem "smarten" Phone, da ist mir auch völlig egal von wem die kommt und welche Rechte die haben darf. Zugriff auf Kamera und Mikrofon für jedwege App?! SELBSTVERSTÄNDLICH, denn passieren kann da sowieso nix, der Betreiber verschlüsselt doch die Daten auf seinem Server und gibt diese Daten sicher an keinen anderen weiter. Sagt er. In Rumänien ist das Pflicht für Hoster. Glaub ich jedenfalls.

Neulich hab ich sowieso den Hauptgewinn gezogen, ein afrikanischer Anwalt hat mich als den letzten lebenden Hinterbliebenen eines Stammesfürsten ausgemacht. Ich flieg jetzt nach Kenia und hol die Millionen dort ab. Ich soll auch sämtliche Ausweise, Stammbuch , die Rentenversicherungsnummer, Kredit- und Bankzugangskarten und auch sonst noch alles mitnehmen, was mich ausweisen kann. Angst hab ich keine, der Typ der mir die Email geschrieben hat ist schliesslich Anwalt. Steht so in der Mail....

Zuhause hab ich ja, dank SmartHome, alles gesichert. Die Zugangsdaten für die "smarten" Türschlösser hab ich derweil in einer KOSTENLOSEN rumänischen Sicherheitsapp gespeichert. Und den Schlüssel für die Türen vorsichtshalber unter den Stein neben der Haustür gelegt. Fotos davon sind natürlich in der Cloud.

Sicher ist schliesslich sicher....

***********************************************

Und ihr beschwert euch über "false positives", die man bei den gängigen Virenprogramm-Herstellern teilweise innerhalb von Stunden "freischalten" kann.

Zitat von Kev

kann ich gleich in die tonne treten wenn sowas einfaches schon als virus von ALLEM erkannt wird.

Warum machst du das nicht einfach?! AutoIt in die Tonne treten. Es gibt massig Alternativen. Hier rumquieken, weil du nachgewiesener Maßen nicht mal in der Lage bist, ein "virenfreies" Programm zu schreiben / zu compilieren / zu übersetzen, hilft nicht. Qualifizieren und weiterbilden hilft. Und virenfreie Programme schreiben. Was qualifiziert dich (und viele andere auch) eigentlich zu der Aussage, dass AutoIt per se KEINEN virulenten Code enthält/erstellt.

Weil ALLE Antivirenwebsites deinen Code als "sauber" kennzeichnen? Schon mal was von Zero-Day-Exploits gehört?

Google, Microsoft, Apple, Samsung und viele andere Softwarehersteller bezahlen mittlerweile Millionen dafür, "Exploits" in ihrer Software gemeldet zu bekommen. Diese Exploits werden dann weiterverkauft an die Antivirenprogramm-Hersteller. Für Milliarden. DAS ist ein Geschäftsmodell, mit dem man GELD verdient....

Da du beeindruckend viel Ahnung von dem hast, was du hier von dir gibst, solltest du ggf. in diesem Bereich tätig werden. Und nicht "..sowas einfaches schon als Virus.." programmieren...

Zitat von Oscar

Alternativ ginge es auch mit einem "Wemos D1 mini" (ESP8266). Dann könnte man das auch per Browser (HTML) im WLAN abrufen.

DAS wäre mein Vorschlag. Letztendlich geht es ja darum, was 1x pro Minute mit dem Messwert gemacht werden soll?! In Datei schreiben, in "irgendine" externe Software reinschreiben (per Autoit), Fragen über Fragen

Zitat von Oscar

Allerdings braucht der dann mehr Strom (in Spitzen bis 200mA).

Du hattest schon das "billigste" Handy-Netzteil vorgeschlagen...

Zitat von Oscar

Da müsste ich mich aber erstmal mit der Kommunikation zu AutoIt intensiver beschäftigen.

Hab da was....nicht nur über AutoIt, sondern auch per MIT App Inventor 2 https://de.wikipedia.org/wiki/App_Inventor

Damit frage ich Daten per Smartphone und WLAN vom ESP ab.

Alternativ direkt zum Einstecken in einen USB-Port am Rechner

https://www.amazon.de/kcTrade-Digispark-kompatibles-Development-ATtiny85/dp/B07S36D5L5/ref=sr_1_5?__mk_de_DE=ÅMÅŽÕÑ&crid=SGRCPUJRZ43M&keywords=digispark+attiny85&qid=1573061497&sprefix=digispark%2Caps%2C168&sr=8-5

BugFix , ich würde dir ja nen ESP oder DigiSpark schenken, aber das wäre wirklich der wirtschaftliche Totalschaden. Porto und Verpackung und selbst wenn du den abholen würdest, kostet mehr als der Brocken selbst....

Hi,

die Hilfe hat einen Browser im Hintergrund, man kann also sehr einfach im Quellcode der Seite bspw nach "Dieses Script öffnen" suchen und sehen, was da passieren soll.

Ein Klick auf diesen Link führt zur Ausführung einer *.au3-Datei.

Ändere also im Kontextmenü einer au3-Datei im Explorer bei "öffnen mit" und dann "Andere App auswählen" auf deinen Editor (Haken bei "immer diese datei mit blablub-Editor öffnen" nicht vergessen"), und beim nächsten Klick in der Hilfe wird die (Hilfe-)Datei in diesem Editor geöffnet.

hmmmm,

Zitat von UEZ

Du kannst ja mal in der Original C++ Source reinschauen

ich bin anhand des Codes in o2cando´s Link davon ausgegangen, dass ebendieser C(++)-Code die Vorlage vom AutoIt-Script war!?

OpenCL hatte ich bereits nach AutoIt transformiert, es ist lediglich der in C (ohne ++) geschriebene Kernel notwendig.

Imho "reicht" dann auch GDI um die Pixel mit reichlich FPS auf den Schirm zu bringen.

btw. AMD-CPU-Besitzer (NICHT GPU!!!) sollten die aktuellen INTEL-CPU-Treiber für OpenCL installieren GetUniqueColors

Hi mainline,

bevor du rennst, solltest du erst mal laufen lernen!

Dein Code ist verbuggt, und als Anmerkung schreibst du dann "... <= klappt wunderbar und sieht gut aus". Was mal deutlich fett gelogen ist, da reihenweise fehler fliegen....

Neben den Syntaxfehlern ignorierst du auch alpines Hinweise bzgl. der Indizierung von Arrays.

Hier übrigens das "wunderbar klappende" Script nach Änderungen:

#include "array.au3"

Func Test()
    Local $_array[5][2]
    For $i = 0 To 4
        Local $_subarray = otherFunction() ; gibt ein Array mit 4 Elementen zurück
        $_array[$i][0] = $_subarray
        $_array[$i][1] = 'Lorem'
    Next
    Return $_array
EndFunc                    ;==>Test

Func otherFunction()

    Local $_test = ["eins", _
            "zwei", _
            "drei", _
            "vier"]
    Return $_test
EndFunc                    ;==>otherFunction


Local $_checkArray = Test()
; funktioniert
_ArrayDisplay($_checkArray) ; <= klappt wunderbar und sieht gut aus
; funktioniert nicht
$bla = $_checkArray[0][0]
_ArrayDisplay($bla)        ; <= bleibt komplett leer

//EDIT

...so ist das, wenn man vor dem abschicken von Posts Kaffee kochen geht^^

Hi,

SEHR schön umgesetzt, sowohl die Idee, als auch der Code!

Ich für meinen Teil halte die erreichte Geschwindigkeit mit AutoIt für TOP!

Zitat von o2candoo

- Im Video sieht man so etwas ähnliches wie einen "Pfad" der einzelnen Punkte, was einen coolen Effekt hervorbringt. Dies habe ich auch versucht, indem ich alle Punkte des vorherigen Schrittes in einem Array gespeichert habe, und lediglich Verbindungslinien von "alten" zu "neuen" punkten gezeichnet habe. Jedoch sieht das ziemlich blöd aus und ist ziemlich ineffizient denke ich. Ist der Ansatz mit einem transparenten clearing besser? Wenn ja, wie?

ja, der Ansatz mit "transparentem clearing" ist besser und frisst (wenn überhaupt) nur unmerklich Performance.

Zitat von o2candoo

Im Video sieht es ziemlich flüssig aus. Ich denke dass dies nur mit Assembler möglich ist, oder gibt es da noch einen anderen Weg mein Skript zu beschleunigen?

Als jemand, der (ich hab gerade festgestellt 40 Jahre) Erfahrung mit Assembler hat kann ich dir nur sagen, LASS ES!

Abgesehen davon, dass es süchtig macht, wenn man die ersten Ergebnisse erzielt, dauert die Einarbeitung imho heutzutage zu lange.

Du solltest also zuerst deinen Code profilen um herauszufinden "wo es hängt".

Im vorliegenden Script hast du leider mehrere "Baustellen".

Die erste ist die " Berechnung", ja die kann man extrem beschleunigen, allerdings geht das wesentlich "billiger" aka einfacher mit einer per HLL erstellten DLL.

Da stellt sich dann natürlich die Frage, wieso nicht das komplette Programm in bspw. FreeBasic oder einem beliebigen anderen Compiler schreiben.

Was direkt zum zweiten "Problem" führt, GDI(+).

Dessen Langsamkeit kann nur mit einer anderen Grafikbibliothek kompensiert werden. Ob das jetzt OpenGL oder etwas anderes sein muss, ist ehrlich gesagt Geschmacksache.

"Modern" programmiert man im und für den Browser, also WebGL, letztendlich läuft das auf Webasm (WebAssembly hat wenig zu tun mit Assembler) raus...

Alternativ bliebe das Schreiben der "Pixel" direkt in den GDI(+) Grafikbuffer, dann sind auch mit GDI locker 300-400FPS drin.

Dann stellt sich natürlich die Frage, was bedeutet "schnell".

In einem deiner Links bzw. weiterführender Links wird beschrieben, dass 400.000 "Punkte" berechnet werden, ich gehe davon aus, pro Frame. Das hört sich auf den ersten Blick "viel" an, aber auf einer 4Ghz-Maschine würde bei Verwendung von nur einem Thread der Prozessor 1000 Takte für die Berechnung von EINEM Punkt benötigen. Prozessorlast bei 0,1%. "Schnell" ist also relativ....

Multithreading wäre eine Lösung, aber der Prozessor ist imho sowieso nur noch Verwaltungswerkzeug, wenn es um Grafik geht, Direkt die Shader programmieren ist State of the Art.

Du siehst also, Optimierungspotenzial ist reichlich vorhanden.

Wobei, und das möchte ich ausdrücklich betonen, für mich ist das Programm ausreichend schnell! Und auch sehr schön in AutoIt programmiert!

Um jetzt in AutoIt weiter zu rocken würde ich direkt auf OpenGL setzen, oder auf OpenCL. Per OpenCL würde der Berechnungsteil direkt auf der Grafikkarte passieren und in einem OpenGL-Fenster dargestellt.

Aus dem Bauch raus würde ich für diese Kombination eine Beschleunigung um Faktor 100 annehmen (sehr defensiv geschätzt :o) )

Ja, in etwa auch so läge die erreichbare Geschwindigkeit per Assembler, allerdings mit wesentlich mehr Aufwand!

Hi,

Zitat von Banana_2_Day

Gibt es ein Skript, welches ältere Skripte automatisch auf Zeilen überprüft, die bei Verwendung der aktuellen AutoIt Version entfernt oder umbenannt werden müssen?

ein Script nicht, das wäre auch unsinnig...

Aber in Scite hilft die F5-Taste! Die ggf. im Ausgabefenster angezeigten Fehlermeldungen durchlesen, verstehen, die Fehlerzeile im Ausgabefensterdoppelklicken springt zur Fehlerzeile im Script, dort Script lt. beschriebener Fehlermeldung ändern. Nochmal F5 drücken uswusf.

Dauert bei den allermeisten Fällen nicht mal 2 Minuten, bei hartnäckigeren Problemen vielleicht 5.

Hi,

zwei Scripte "nebeneinander" an einer Aufgabe arbeiten zu lassen, führt genau zu dem in deinem Beispiel gezeigten Ergebnis.

Frag dich mal selbst, ob du irgendein Programm kennst, das auf diese (deine) Art und Weise arbeitet....

Damit sollte die Frage schon beantwortet sein!

Zitat von Serveranfrage

Also während das Hauptskript läuft und das Nebenskript nachträglich zusätzlich aktiviert wird, warten auf Popup Fenster vom Nebenskript. Wenns erscheint, sofort schließen, da es nur ne Infobox ist.

Genau so wird das "richtig" gemacht!

Also los!

Btw. ist es wesentlich einfacher zu helfen, wenn man die Scripte auch lesen kann! Glaskugeln ist heutzutage absolut nicht mehr "hip".

Wenn du demnächst eine Frage hast, häng die Scripte an...

Hi,

Stringtobinary() ist dein Freund....

btw., Hex() wandelt Integer um, ist also in diesem Fall falsch.

#include <Crypt.au3>
#include <File.au3>
$Text = "Test"
$Text_crypt = _Crypt_EncryptData($Text,"1234", $CALG_RC2)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $Text_crypt = ' & $Text_crypt & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

    _FileCreate("data.txt")
    $fo = FileOpen("data.txt")
    FileWrite("data.txt",stringtobinary($Text_crypt))
    FileClose($Fo)

    msgbox(0,"Dateiinhalt",fileread("data.txt"))

Hi,

das hängt an der Abfrage der Struct in der Funktion _FD_Detect()

Füge

$_tFD_Bmp=0

$_tFD_BmpG=0

vor dem Return $aFaces ein.

Naja, wenn ich mir ab und zu die Bundesliga ansehe, dann frag ich mich schon, wer da mehr "Mädchen"-Fußball spielt :o)

Ich schaue gerne Damenfuß- und in letzter Zeit auch Handball. Technisch ist da nicht mehr viel unterschied. Imho hängen sich die Mädels auch wesentlich mehr rein als die Jungs, die dann obendrein für ein 0:0 rumgekicke noch 20x so viel Kohle abstauben.

Ich wäre sowieso dafür, bei einem 0:0 BEIDEN Teams mindestens 5 Punkte abzuziehen, besser 10. Dann würde definitiv wieder Fußball gespielt, und nicht "taktisch" ein Punkt nachhausegeeiert....