• Hi Community

    Das hier angehängte Skript bezieht sich auf folgenden YouTube Beitrag von CodeParade, welches das Funktionsprinzip auch gleich erklärt:

    Chaos Equations - Simple Mathematical Art

    Dieses video hat mich dazu inspiriert, eine Umsetzung in AutoIT zu versuchen.

    Das Resultat ist meiner Meinung nach mehr oder weniger zufriedenstellend.

    Jedoch möchte ich gerne bei den AutoIT Experten noch folgendes in Erfahrung bringen falls möglich:

    - 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?

    - 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? Wenn Assembler die einzige Lösung ist (habe ich btw. 0 Erfahrung), kann mir dann jemand etwas unter die Arme greifen, bzw. einen guten Link empfehlen, um sich in Assembler etwas einzuarbeiten?

    - Eine andere Möglichkeit wäre alles komplett durchrechnen zu lassen und dann erst zu visualisieren, bspw. mittels einem Gif? Gibt es da bereits etwas ähnliches?


    Info zu den Makros in meinem Skript:

    c --> Säubern

    h --> Verlauf ON/OFF

    r --> Neue zufällige Summanden (im Modus "Random" ersichtlich)

    m --> Moduswechsel

    t --> ToolTip ON/OFF

    a --> Animation ON/OFF

    f --> Animation schneller

    l --> Animation langsamer

    s --> Animationsbereich kleiner

    b --> Animationsbereich grösser

    i --> Info (oben links) ON/OFF

    Mauserad --> Zoom

    Mausposition in Horizontaler Richtung --> Zeitschritt-Update (wenn Animation OFF)

    Ansonsten wünsche ich viel Spass beim Ausprobieren und Entdecken von neuen Kombinationen :)

    LG

  • Hi,

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

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

    - 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.

    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!

  • Vielen Dank für diese Rückmeldungen!

    Das freut und motiviert mich natürlich umso mehr etwas daran rumzutüfteln :):thumbup:

    Andy Danke, dass Du mich vor grösserem "Schaden" im Bezug auf Assembler bewahrst ^^

    Auch die weiteren Ausführungen und Tipps von Dir werde ich bei Gelegenheit sehr gerne versuchen umzusetzen.

    Allem voran den Vorschlag, dies mit OpenCL kombiniert mit OpenGL zu realisieren.

    Zudem werde ich evtl. versuchen, etwas in Python zu coden (nur um Vergleiche ziehen zu können und just 4 Fun).

    UEZ Dies habe ich noch nicht getan, ist aber ein guter nächster Schritt

    (habe ich zuerst gemieden, da ich auch in C++ noch keine Erfahrung habe und ich zunächst mehr Zeit brauche, um diese Sprache zu lernen).


    LG

  • hmmmm,

    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

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (13. September 2019 um 22:06)