1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. Andy

Beiträge von Andy

  • FOR-Schleife in IF-Abfrage

    • Andy
    • 3. Juni 2012 um 21:49

    Hi,

    Zitat von Name mit vielen Neunen

    Naja vielleicht versteh ich dich ja falsch

    da bin ich sicher :rolleyes:
    Aber da kommst du gleich selbst drauf, nachdem du folgende Fragen beantwortest:

    Nach ca. 2 Jahren gräbst du einen Thread aus, ohne eigenen Lösungsvorschlag, warum?

    In welcher Art und Weise hat der Threadersteller auch nur EINEN Ansatz zur Lösung seines Problems gepostet?

    Was hat der Threadersteller getan, um herauszufinden WARUM sein Script nicht funktioniert?

    Hätte der Threadersteller sein Problem mit Abfragen der von ihm benutzten Variablen z.B. so

    Spoiler anzeigen
    [autoit]

    Func _winmove()
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $up = ' & $up & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
    If $up = 0 Then
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : @DesktopHeight - $guiheigth - 30 = ' & @DesktopHeight - $guiheigth - 30 & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : @DesktopHeight - 20 - 30 = ' & @DesktopHeight - 20 - 30 & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
    For $pos = @DesktopHeight - 20 - 30 To @DesktopHeight - $guiheigth - 30 Step 5
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $pos = ' & $pos & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
    WinMove($guiname, "", @DesktopWidth - $guiwidth, $pos)
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : @DesktopWidth - $guiwidth = ' & @DesktopWidth - $guiwidth & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
    Next
    $up = 1
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $up = ' & $up & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
    ElseIf $up = 1 Then
    For $pos = @DesktopHeight - $guiheigth - 30 To @DesktopHeight - 20 - 30 Step 5
    WinMove($guiname, "", @DesktopWidth - $guiwidth, @DesktopHeight - 20 - 30)
    Next
    $up = 0
    EndIf
    EndFunc

    [/autoit]

    lösen können, bzw wäre ihm dann aufgefallen dass sich die Variablen ausserhalb des Wertebereichs bewegen?


    Ich persönlich stelle mir die o.g Fragen immer beim Lesen eines "Hilfe"-Threads, und dementsprechend fällt die Antwort aus :rolleyes:

    Zitat von Alizame

    ok es war vllt etwas schwierig rauszulesen,

    hehe, leider gibt´s in diesem Forum kein Ironie-Tag, und wenn es eins gäbe, wüssten die meisten Aufgrund Ihres Alters nicht, warum und wieso es benutzt wird :D

  • GDI+ Bitmap.SetPixel

    • Andy
    • 1. Juni 2012 um 18:04

    Hi,

    Zitat

    Andy: Wie sieht denn die Assemblerfunktion aus?
    Du hattest auch mal in einem anderen Thread gesagt, dass du Verbindung hast zu einem aus dem engl. Forum, der will Spiralfedern messen. Weißt du was daraus geworden ist?

    Ja, das ist ein Franzose gewesen, der in seiner Firma Spiralfedern nachmessen musste, bzw die korrekte Wicklung, Durchmesser usw.
    Ich muss mal suchen, ob ich das Script finde :D
    Jedenfalls wurde ein Foto gemacht, in Graustufen und dann in Schwarzweiss umgewandelt, und per Kantendetektion die Spirale auf dem Foto gefunden.
    Egal wie die Spirale in der Bitmap liegt, wurden die Maße bestimmt, anhand einer Referenzmessung. Ich glaube, die Genauigkeit lag bei 2-3 Zehntel Millimeter, also in seinem Fall reichlich ausreichend.

    Die Assemblerfunktion (RGB2HSL und die Sobeloperatoren) wird bald in einer Sammlung von ASM- Bildbearbeitungsfunktionen auftauchen. Verwendbar mit den gängigen GDI(+)-Befehlen. 8o

  • wie ODBC-Datenquelle (System-DSN) nutzen

    • Andy
    • 30. Mai 2012 um 20:13

    Hi,
    habe zwar keinen SQL-Server im momentanen Zugriff, aber ggf helfen dir folgende Scripte weiter.
    Übrigens wurden die Scripte automatisch erstellt von "AutoIt Scriptomatic Tool" (das erstellt zum Thema ODBC noch mehr )

    Spoiler anzeigen
    [autoit]

    ; Generated by AutoIt Scriptomatic

    [/autoit] [autoit][/autoit] [autoit]

    $wbemFlagReturnImmediately = 0x10
    $wbemFlagForwardOnly = 0x20
    $colItems = ""
    $strComputer = "localhost"

    [/autoit] [autoit][/autoit] [autoit]

    $Output=""
    $Output = $Output & "Computer: " & $strComputer & @CRLF
    $Output = $Output & "==========================================" & @CRLF
    $objWMIService = ObjGet("winmgmts:\\" & $strComputer & "\root\CIMV2")
    $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_ODBCAttribute", "WQL", _
    $wbemFlagReturnImmediately + $wbemFlagForwardOnly)

    [/autoit] [autoit][/autoit] [autoit]

    If IsObj($colItems) then
    For $objItem In $colItems
    $Output = $Output & "Attribute: " & $objItem.Attribute & @CRLF
    $Output = $Output & "Caption: " & $objItem.Caption & @CRLF
    $Output = $Output & "Description: " & $objItem.Description & @CRLF
    $Output = $Output & "Driver: " & $objItem.Driver & @CRLF
    $Output = $Output & "SettingID: " & $objItem.SettingID & @CRLF
    $Output = $Output & "Value: " & $objItem.Value & @CRLF
    if Msgbox(1,"WMI Output",$Output) = 2 then ExitLoop
    $Output=""
    Next
    Else
    Msgbox(0,"WMI Output","No WMI Objects Found for class: " & "Win32_ODBCAttribute" )
    Endif

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit][/autoit]
    Spoiler anzeigen
    [autoit]

    ; Generated by AutoIt Scriptomatic

    [/autoit] [autoit][/autoit] [autoit]

    $wbemFlagReturnImmediately = 0x10
    $wbemFlagForwardOnly = 0x20
    $colItems = ""
    $strComputer = "localhost"

    [/autoit] [autoit][/autoit] [autoit]

    $Output=""
    $Output = $Output & "Computer: " & $strComputer & @CRLF
    $Output = $Output & "==========================================" & @CRLF
    $objWMIService = ObjGet("winmgmts:\\" & $strComputer & "\root\CIMV2")
    $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_ODBCDataSourceAttribute", "WQL", _
    $wbemFlagReturnImmediately + $wbemFlagForwardOnly)

    [/autoit] [autoit][/autoit] [autoit]

    If IsObj($colItems) then
    For $objItem In $colItems
    $Output = $Output & "Check: " & $objItem.Check & @CRLF
    $Output = $Output & "Setting: " & $objItem.Setting & @CRLF
    if Msgbox(1,"WMI Output",$Output) = 2 then ExitLoop
    $Output=""
    Next
    Else
    Msgbox(0,"WMI Output","No WMI Objects Found for class: " & "Win32_ODBCDataSourceAttribute" )
    Endif

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit][/autoit]
    Spoiler anzeigen
    [autoit]

    ; Generated by AutoIt Scriptomatic

    [/autoit] [autoit][/autoit] [autoit]

    $wbemFlagReturnImmediately = 0x10
    $wbemFlagForwardOnly = 0x20
    $colItems = ""
    $strComputer = "localhost"

    [/autoit] [autoit][/autoit] [autoit]

    $Output=""
    $Output = $Output & "Computer: " & $strComputer & @CRLF
    $Output = $Output & "==========================================" & @CRLF
    $objWMIService = ObjGet("winmgmts:\\" & $strComputer & "\root\CIMV2")
    $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_ODBCDataSourceSpecification", "WQL", _
    $wbemFlagReturnImmediately + $wbemFlagForwardOnly)

    [/autoit] [autoit][/autoit] [autoit]

    If IsObj($colItems) then
    For $objItem In $colItems
    $Output = $Output & "Caption: " & $objItem.Caption & @CRLF
    $Output = $Output & "CheckID: " & $objItem.CheckID & @CRLF
    $Output = $Output & "CheckMode: " & $objItem.CheckMode & @CRLF
    $Output = $Output & "DataSource: " & $objItem.DataSource & @CRLF
    $Output = $Output & "Description: " & $objItem.Description & @CRLF
    $Output = $Output & "DriverDescription: " & $objItem.DriverDescription & @CRLF
    $Output = $Output & "Name: " & $objItem.Name & @CRLF
    $Output = $Output & "Registration: " & $objItem.Registration & @CRLF
    $Output = $Output & "SoftwareElementID: " & $objItem.SoftwareElementID & @CRLF
    $Output = $Output & "SoftwareElementState: " & $objItem.SoftwareElementState & @CRLF
    $Output = $Output & "TargetOperatingSystem: " & $objItem.TargetOperatingSystem & @CRLF
    $Output = $Output & "Version: " & $objItem.Version & @CRLF
    if Msgbox(1,"WMI Output",$Output) = 2 then ExitLoop
    $Output=""
    Next
    Else
    Msgbox(0,"WMI Output","No WMI Objects Found for class: " & "Win32_ODBCDataSourceSpecification" )
    Endif

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit][/autoit]
  • Pixel Checksumme von einem Bild als Hex-String

    • Andy
    • 27. Mai 2012 um 13:22
    Zitat

    Andy: danke. Wenn das schneller, als mit Checksum ist....

    Checksum lohnt sich nur, wenn du direkt 2 Bilder miteinander vergleichen willst
    PtB benutzt diverse Methoden, um Bilder schnellstmöglich zu finden.
    Zunächst wird das "Suchbild" analysiert und anhand der darin enthaltenen Farben bezüglich zum gesamten Screen die Suchmethode festgelegt.
    Da sowohl die AutoItfunktion stringinstr() sauschnell ist, als auch die (alternative) Assemblerfunktion aus der prospeed.dll dauert die Suche uber den gesamten Screen nur einige Millisekunden.

    Darauf zu achten ist, dass die oberste Zeile des zu suchenden Bildes möglichst unterschiedliche Farben enthält!
    Dadurch beschleunigt sich die Suche enorm.

  • Pixel Checksumme von einem Bild als Hex-String

    • Andy
    • 27. Mai 2012 um 06:34

    PushTheButton sucht Bilder auf dem Screen und hat eine Gebrauchsanleitung eingebaut :rofl:

  • Happy Birthday SEuBo und anno2008

    • Andy
    • 27. Mai 2012 um 06:20

    Glücklichen Herzwunsch und alles Gute!
    Möge der Saft immer mit euch sein :thumbup:

  • Assembler UDF ?

    • Andy
    • 23. Mai 2012 um 06:55

    Hi,
    @Marsi
    bei Win7-64 stürzt das Script ab und zu ab, manchmal läuft es 10 Sekunden, manchmal nur eine....
    Fehler ist, dass das ESI-Register mit Null bzw. einer Adresse in der Nähe von Null gefüllt ist und der Memcopy daraufhin natürlich nicht funktioniert.

    Ich würde die ganze Sache auch nicht so kompliziert machen!
    Das Script liest die Anzahl der zur Verfügung stehenden Prozessor-Kerne aus, erstellt diese Anzahl Threads (oder einen weniger) und lässt sie loslaufen.
    Gleichzeitiges Schreiben in denselben Speicherbereich würde ich persönlich nicht machen. Das führt zu flackern bei bewegten Objekten.
    Bei einem Bildbearbeitungsfilter auf Pixelebene macht Multithreading Sinn, da teilt man die Grafik in "Stücke pro Thread" und lässt die Einzelteile gleichzeitig bearbeiten.
    Das lohnt sich performancetechnisch imho aber auch nur bei komplizierten Filtern....

  • Assembler UDF ?

    • Andy
    • 21. Mai 2012 um 21:42

    Hi,
    das Prefetch muss in den loop.
    Da es immer etwas dauert bis die Daten vom RAM im Cache sind, lädt man "vorrausschauend".
    Dabei ist unbedingt zu verhindern, dass die Daten aus dem Cache "rausgedrückt" werden von Daten die bereits garnicht mehr gebraucht werden, das ist dann der Supergau!

    Leider gibt es keine Daumenregel, ein sehr interessanter Bericht findet sich (ganz unten auf der Seite) HIER! Übrigens eine meiner TOP-Favoriten bzgl.ASM-Optimierung 8o

  • Assembler UDF ?

    • Andy
    • 20. Mai 2012 um 21:41
    Zitat von Marsi

    Da ist es wahrscheinlich sinnvoll eine ASM func zu haben die die Liste durchgeht, statt jedes Mal in AutoIt einen Call zu machen.

    daher vorher eine DIB erstellen und mit ASM-Funktionen bearbeiten und wie gehabt blitten. Allerdings fallen dann die "schönen" GDI+-Funktionen wie z.B. Path- und Matrixfunktionen hinten runter :huh: Denn der Weg von einer DIB zu einer DDB ist genauso langsam wie umgekehrt!

    Daher stellt sich immer mehr die Frage, WAS in einem GDI+-Programm eigendlich die Performance frisst! Das ist der Ansatzpunkt!

    Zitat

    SSE konnte da natürlich abhilfe schaffen, weil man dann direkt 32Px gleichzeig liest und schreibt. Also muss man nur alle 32Px im Ram Springen. Das ist aber immernoch zu viel. Kann man vllt iwie größere Mengen Daten (schnell) in den Stack stopfen ? So z.B. 128 Px (512 Byte).

    AVX bringt da nicht viel, da nur Speicherbewegungen stattfinden. Prefetching (Daten vorrausschauend in den Cache laden) hilft am meisten! Wenn der Cache voll mit den Daten ist, die bald benötigt werden, dann dauert ein MemMove statt 10-15 nur noch 2-3 Takte....
    In einer Schleife bringt das ca. 50% mehr Speed.

  • Assembler UDF ?

    • Andy
    • 20. Mai 2012 um 17:58
    Zitat

    Die Frage ist nun, gibt es auch in ASM ein möglichkeit direkt den Grafikspeicherbereich zu benutzen!

    Genau das ist der Knackpunkt!
    GDI+ "zaubert" ja nicht irgendwie die Bitmap in den Grafikkartenspeicher, das passiert ja auch über eine Art Bitblt...ergo MUSS die GDI+Bitmap (DDB) irgendwo im Speicher stehen. Leider lässt uns Windows nicht in diesen extra geschützten Speicherbereich :thumbdown:
    Man muss also diesen gesicherten Speicherbereich zugänglich machen (das passiert per BitmapLockBits) oder eine Kopie dieses Speicherbereichs anlegen (GetDIBits), leider ist beides schnarchlangsam .....GetDIBits/SetDIBits wg _GDIPlus_BitmapCreateHBITMAPFromBitmap()/_GDIPlus_BitmapCreateFromHBITMAP() braucht ca 1,5x länger als LockBits/UnLockBits

    Das Problem dabei ist, für JEDE Pixel-Manipulation ausserhalb der GDI+(DDB)-Funktionen jedes Mal die Bitmap zu kopieren, zu manipulieren und nachher wieder zurückzukopieren.
    Das alles hat man sich mit der Verwendung einer DIB gespart. Allerdings mit dem zugegebenermaßen bestehenden Nachteil, auf bestimmten Devices (Monochrom, 16Bit-Color, Plotter usw.) die 32Bit ARGB-Manipulation nicht immer mit dem gewünschten Ergebnis zu bekommen

  • Assembler UDF ?

    • Andy
    • 20. Mai 2012 um 09:03

    Hi,
    das Ziel sollte sein, bestehende GDI/GDI+-Scripte, welche an Performanceproblemen leiden, durch einfaches Ersetzen von ASM-UDF-Funktionen zu beschleunigen.
    Dazu ist es immens wichtig, zuerst den Grund der niedrigen Geschwindigkeit herauszufinden, d.h. die "langsame" Funktion zu suchen (profiling).
    Es nützt nichts, einen Bitblt, der nur eine Millisekunde benötigt, durch einen zu ersetzen, der dreimal so schnell ist! Jedenfalls nicht in 99% aller Fälle :D

    Reine GDI-Programme sind idR. unkritisch, es gibt verschiedenste Möglichkeiten, an den Pointer der Bitmapdaten (Pixel) zu kommen.
    Ich plädiere dafür, im Vorfeld nur Bitmaps zu erstellen, die bereits einen Pointer auf die "Pixel" enthalten.
    Die von mir in _CreateNewBmp32() gewrapperte Funktion CreateDIBSection() ist die eierlegende Wollmilchsau! Es wird eine leere Bitmap erstellt und HDC, Pointer auf die "Pixel" und ein per GDI(+ ?) -verwendbares "Handle" zurückgegeben.
    Dann die ASM-Funktion aufrufen, blitten, fertig.
    Da die gesammelten Asm-Funktionen in eine gemeinsame DLL sollen, sehe ich kein Problem.


    Bei GDI+ sieht die Sache schon anders aus!
    Greenhorn, UEZ und ich haben sich schon Nächte um die Ohren gehauen, um einen Weg zu finden um die Pointer auf die Bitmapdaten ("Pixel" RGBA) im Speicher zu lokalisieren bzw aus den bestehenden GDI(+)-Funktionen zu extrahieren.
    Ich habe dann eingeworfen, dass die Funktion BitmapLockBits() verhältnismässig langsam sei. Diese Aussage ist aber wohl nur auf nicht performanten Rechnern zu halten (wzbw).
    /EDIT/ Wobei ganz klar zu sagen ist, dass der "Lock" immer noch Faktor 20-30x langsamer ist (bzw. mehr Zeit kostet) als diverse ASM-Funktionen, welche die komplette Bitmap bearbeiten!

    Zzt. würde ich also dafür plädieren, dass die Assemblerfunktionen ihren Pointer aus der BitmapLockBits() erhalten.
    Somit wäre folgende Vorgehensweise bzw. Grundgerüst für die _GDIplus_Funktionsname_ASM() praktikabel:

    • Aus der Orginalfunktion das benötigte "Handle" identifizieren und in ein für BitmapLockBits() verwendbares Handle umwandeln
      BitmapLockBits()
      ASM-Code
      BitmapUnLockBits()


    Dann geht´s nun los^^
    Sammelt fleissig (schnellen) ASM-Code und/oder auch neue Ideen für zzt nicht oder nur langsam implementierte Funktionen, damit wir gemeinsam eine "richtige" UDF aufbauen können :thumbup:

    Zitat

    sodass sie (nach einigen Tests) fehlerfrei laufen. (asm stürzt ja idr öfters ab als alles andere).

    Bei Fehlern im Asm-Code gebe ich dir Recht da muss dann Gebugfixt werden!
    Fehler in der "Ansteuerung" allerdings würde ich gerne auf den Anwender (Programmierer) abwälzen wollen.
    Imho bringt es nichts (denn daran krankt u.a. die gesamte Win-API), eigendlich schnelle Funktionen mit einem "Ich fange jede fehlerhafte Eingabe ab"-Header zu versehen, um dann Code aus 1998 zu verwenden (ist in erheblichen Teilen in Win7 enthalten), nur weil sich damals jemand die Mühe gemacht hat, DAU-resistenten Code zu schreiben!

  • AssembleIt incl. Laufzeit-"Debugger" [Update12/04/2012]

    • Andy
    • 13. Mai 2012 um 10:23

    Update 12/05/2012
    Debugger zeigt nun SSE-Register "richtig" an, bitweise von rechts nach links
    neue Beispieldatei mit Erklärung von _ASSEMBLEIT_FLAG

  • Burning Keyboard - Wie schnell kannst du tippen?

    • Andy
    • 12. Mai 2012 um 21:31
    Zitat

    Das Ding hat echt Stil, kannte ich vorher noch gar nicht. Außerdem geil, dass man die Pixel einzeln steuern kann.

    meine ersten Schritte in Maschinensprache, das Buch hab ich heute noch^^, ohne Assembler, den Code hat man direkt byteweise ins RAM "gepoked"
    Auch die Schnittstelle konnte man per Maschinensprache ansprechen, mit dem Rechner und selbstgelöteten Treibern hab ich u.a. Werkzeugmaschinen (Fräsmaschine) gesteuert,

    Der "Bildschirm" war auch klasse, 5x7 Punktmatrix pro Feld, da haben wir sogar ein Basketballspiel für 2 Spieler hinbekommen

  • Burning Keyboard - Wie schnell kannst du tippen?

    • Andy
    • 12. Mai 2012 um 09:48

    hi,
    schöne Umsetzung....

    Mein Ergebnis: 8o
    Correct chars: 142
    Chars/second: 2.37
    Correct words: 22

    als "Nicht-10-Fingerschreiber" profitiere ich natürlich von vielen relativ langen Wörtern :D
    So ein Programm hatte ich schon auf dem PC1401 geschrieben, man beachte die gigantische Speicherkapazität von 3534 BYTES! Diesen "Taschenrechner" habe ich übrigens heute noch täglich in Gebrauch!

  • Alle Dateien auslesen

    • Andy
    • 9. Mai 2012 um 21:16

    Sehr nice :thumbup:
    aber per DeviceIOControl() gehts noch ca. 10x schneller über direktes Lesen aus der MFT. Ich finde leider das Script nicht mehr :(...muss in irgendeinem Backup verschollen sein...
    Die MFT auszulesen bzw zu verändern führt bei unsachgemässem Gebrauch schnell mal zu einer komplett zu formatierenden Platte :D , daher hab ich das Script damals nicht gepostet.

  • Alle Dateien auslesen

    • Andy
    • 9. Mai 2012 um 19:42
    Zitat

    Gerade bei vielen Daten relativ langsam im Vergleich zu anderen Methoden.

    relativ ist relativ :rolleyes:
    In dem von mir geposteten Link werden die gängigen Methoden verglichen.
    BugFix benutzt dabei das Scripting.FileSystemObject und ist nur halb so schnell wie Oscars Lösung

    $path=@windowsdir

    Code
    BugFix	                      33.1 Sekunden                  71420
    Oscar	                      14.8 Sekunden                  71420
    _FileListToArrayEx	      14.8 Sekunden                  71420
  • ImageSearch [x- und y-Koordinaten in ein Array] --> ERROR

    • Andy
    • 9. Mai 2012 um 19:11

    Imagesearchdll.dll im Verzeichnis?

  • Alle Dateien auslesen

    • Andy
    • 8. Mai 2012 um 21:36

    Klick mich, ich bin ein Link!
    und noch einer....

    Wenn dir das nicht reicht, hast du jedenfalls genug Vorlagen, um dir was eigenes zu stricken....

  • Grafik Engine Erstellen

    • Andy
    • 6. Mai 2012 um 21:29

    Hi,

    Zitat von smincke

    Andy: Wann hast du Meinen Code disassembliert?

    sofort nach deinem ersten Posting^^
    Hab mir, bevor ich den Debugger ins AssembleIt integriert hatte eine Funktion gemacht, die den von Fasm generierten Bytecode an IDA übergibt, wenn man will kann man auch den Ollydbg benutzen, wobei der kein SSE und 64Bit-code kann, deshalb fällt Olly für mich als Debugger flach :thumbdown:
    Dein asm-Code hat definitives Beschleunigungspotenzial, schau dir mal die diversen Seiten von Agner Fog oder Mark Larson an zum Thema "Optimization". Generell lohnt ASM- code nur dann, wenn man wirklich Speed rausholen kann, zzt habe ich ein Alphablend in der Mache, dass 3 bis 4x schneller ist als die API-Funktion. Auf einem Tablett sogar sehr viel schneller!

    Daher sollte man so weit es geht die API-Funktionen (in deinem Script eben TransparentBlt() ) nutzen und das AutoIt-Script "profilen" und die Zeiten der einzelnen Funktionen ausstoppen um den wirklich langsamen Teil (im inner loop) zu finden.
    Eher selten hängt es dabei erfahrungsgemäß an den API-Funktionen :rolleyes:

    Zitat von progandy

    Edit: Über einen Timer-Interrupt (_Timer_SetTimer, evtl. auch Adlib) lässt sich das aber schon akzeptabel lösen denke ich.

    so mache ich das idR.
    Btw, da die kurzen ASM-Codes so gut wie immer Threadsicher sind, ist "echtes" Multithreating in AutoIt machbar, jedenfalls hab ich hier einige Beispiele, bei denen Bildbearbeitung (da hab ich die meisten Funktionen^^ ) auf mehreren Cores gleichzeitig abläuft. Ich glaub, da ist bald mal wieder ein TUT fällig^^

  • Grafik Engine Erstellen

    • Andy
    • 6. Mai 2012 um 20:32

    Hi,

    Zitat

    Wenn du ein schnelleres Script hast, dann immer her damit


    hab mir den asm-Code mal disassembliert, ich glaube absolut nicht, dass dieser Code schneller ist als die GDI-Funktion TransparentBlt(), die genau dafür gemacht ist. Den ASM- Code zu beschleunigen, z.b per SSE (SIMD) 4 Pixel gleichzeitig zu berechnen, sollte das Problem nicht sein

    Aber ich stimme Ealendil zu, die "pro Frame Bewegung" funktioniert nicht. Eine "alle XX Millisekunden Bewegung" allerdings schon. Flüssige Bewegung völlig unabhängig von der aktuellen Framerate ist das Ziel. Dann ist auch völlig schnuppe, ob der Server oder die Übertragung mal "hustet", denn dann kann der Client anhand der "nächsten" Position die Zwischenbilder berechnen. So machen das sämtliche MMORPG´s.....nicht ohne Grund.

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™