Revision Demoparty 2014 Streams'n'Tools (und allgemeine Demoparty Diskussion)

  • Nur braucht man dafür eine "richtige" Programmiersprache (wie es gestern jemand formuliert hat): AutoIt kannst du nicht kompilieren und die Geschwindigkeit reicht auch nicht aus (wobei es dafür auch noch ASM gibt, aber dann am besten gleich richtig).

  • Zitat

    wobei es dafür auch noch ASM gibt, aber dann am besten gleich richtig).

    eben....da nämlich sowieso nur Shader bzw die GPU über deren Treiber bzw. Direct3D/OpenGL/CL programmiert werden, fällt eine "normale" Programmiersprache imho raus, da selbst für einfachste float-Berechnungen (sin, cos, sqrt usw.) nicht die nativen und schnellen CPU-Befehle benutzt werden, sondern die "sicheren" Bibliotheken.

    Und wenn einer sagt, _intrinsic-functions wäre die Lösung, ja dann muss ich lachen....eine "Hochsprache" zu verwenden, in der dann Prozessorbefehle gewrappert werden...DAS ist der echte Fortschritt!!! Die Frage bleibt, warum ich als Programmierer solche Krücken benutzen muss, und der Compiler das nicht von sich aus hinbekommt 8)
    Für 1K bis 4k ist Assembler imho eine sehr gute Wahl, darüber wird es dann wieder aufwändiger und spezielle Bibliotheken für "Hochsprachen" gibts ja mittlerweile auch schon 8o

  • eben....da nämlich sowieso nur Shader bzw die GPU über deren Treiber bzw. Direct3D/OpenGL/CL programmiert werden, fällt eine "normale" Programmiersprache imho raus

    700 Byte Demos sind selbst in Microsofts VC++ möglich - obwohl voller Unsinn. Für 1k/4k/8k ist selbst Perseus noch geeignet. Ab 64k ist jede kompilierte Sprache benutzbar ;)

    AutoIt Einsendungen können trotzdem noch in "Wild" oder wenn sie gut sind in "PC Demo" teilnehmen.

  • AutoIt wäre natürlich der Knaller :rock:
    Man müsste nur die Demo von der Idee her so gestalten, dass sie problemlos in AutoIt machbar wäre. Beispielsweise eine kleine Geschichte mit sich bewegenden/tanzenden Strichmännchen, die während der Demo eine sich im Hintergrund aufbauende prozedurale Landschaft kommentieren....ein "umpft umpft umpft-Sound" in einer Handvoll Bytes,der im Hintergrund dudelt, sollte dabei auch noch machbar sein.

  • Wenn sich dazu wirklich ein paar Interessierte finden, könnte man vielleicht über ein separates Subforum nachdenken um die Arbeiten zu managen. Möglicherweise auch mit einem abgesperrten Bereich damit das Release nicht zu früh an's Tageslicht kommt.

  • Hier die Portierung des Diamond-Square Algorithmuses von C#.

    Spoiler anzeigen
    [autoit]


    ;http://en.wikipedia.org/wiki/Diamond-square_algorithm
    ;converted from http://www.smokycogs.com/blog/plasma-fractals/
    #include <GDIPlus.au3>

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

    _GDIPlus_Startup()
    Global $iW = 512, $iH = 512, $bPreview = False, $f = ($iW > $iH) ? $iW / $iH : $iH / $iW, $iRecursion = 0, $fPerc
    Global $hGUI = GUICreate("Cloud Generator using Diamond-Square Algorithm", $iW, $iH, -1, -1)
    Global $iPic = GUICtrlCreatePic("", 0, 0, $iW, $iH)
    Global $iLabel = GUICtrlCreateLabel("Please wait...", 1, $iH - 12, $iW, 12)
    GUICtrlSetBkColor(-1, -2)
    GUISetState()

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

    Global $hBitmap = _GDIPlus_BitmapCreateFromScan0($iW, $iH), $hBmp_GDI
    AdlibRegister("Show_Perc", 250)
    Local $s, $t = TimerInit()
    Generate($iW, $iH, 3)
    $s = TimerDiff($t)
    AdlibUnRegister("Show_Perc")
    ConsoleWrite($s & " ms / Recursion calls: " & $iRecursion & " / Pixels set: " & $iW * $iH & " / Speed: ~" & Round($iW * $iH / $s * 1000, 2) & " px/s" & @CRLF)
    $hBmp_GDI = _GDIPlus_BitmapCreateHBITMAPFromBitmap($hBitmap)
    _WinAPI_DeleteObject(GUICtrlSendMsg($iPic, 0x0172, 0x0000, $hBmp_GDI))
    _WinAPI_DeleteObject($hBmp_GDI)
    _GDIPlus_BitmapDispose($hBitmap)
    _GDIPlus_Shutdown()

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

    Do
    Until GUIGetMsg() = -3

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

    Func Show_Perc()
    GUICtrlSetData($iLabel, "Please wait..." & (StringFormat("%.2f %", $iRecursion / ($f * ($iW * $iH) / 3) * 100)))
    EndFunc

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

    Func DivideGrid($x, $y, $width, $height, $c1, $c2, $c3, $c4, $gBigSize, $gRoughness)
    Local $Edge1, $Edge2, $Edge3, $Edge4, $Middle
    Local $newWidth = $width / 2
    Local $newHeight = $height / 2
    If ($width > 1) Or ($height > 1) Then
    $iRecursion += 1
    $Middle = (($c1 + $c2 + $c3 + $c4) / 4) + Displace($newWidth + $newHeight, $gBigSize, $gRoughness); Randomly displace the midpoint!
    $Edge1 = (($c1 + $c2) / 2) ; Calculate the edges by averaging the two corners of each edge.
    $Edge2 = (($c2 + $c3) / 2) ;
    $Edge3 = (($c3 + $c4) / 2) ;
    $Edge4 = (($c4 + $c1) / 2) ;
    ;Make sure that the midpoint doesn't accidentally "randomly displaced" past the boundaries!
    $Middle= Rectify($Middle) ;
    $Edge1 = Rectify($Edge1) ;
    $Edge2 = Rectify($Edge2) ;
    $Edge3 = Rectify($Edge3) ;
    $Edge4 = Rectify($Edge4) ;
    ;Do the operation over again for each of the four new grids.
    DivideGrid($x, $y, $newWidth, $newHeight, $c1, $Edge1, $Middle, $Edge4, $gBigSize, $gRoughness);
    DivideGrid($x + $newWidth, $y, $width - $newWidth, $newHeight, $Edge1, $c2, $Edge2, $Middle, $gBigSize, $gRoughness);
    DivideGrid($x + $newWidth, $y + $newHeight, $width - $newWidth, $height - $newHeight, $Middle, $Edge2, $c3, $Edge3, $gBigSize, $gRoughness);
    DivideGrid($x, $y + $newHeight, $newWidth, $height - $newHeight, $Edge4, $Middle, $Edge3, $c4, $gBigSize, $gRoughness);
    Else ; This is the "base case," where each grid piece is less than the size of a pixel.
    ; The four corners of the grid piece will be averaged and drawn as a single pixel.
    Local $c = ($c1 + $c2 + $c3 + $c4) / 4
    Local $r = Int(0xFF - 0xFF * $c), $g = Int(0xFF - 0xFF * $c), $b = Int(0xFF - 0xFF * $c / 2)
    Local $color = "0xFF" & Hex($r, 2) & Hex($g, 2) & Hex($b, 2)
    DllCall($ghGDIPDll, "int", "GdipBitmapSetPixel", "handle", $hBitmap, "int", $x, "int", $y, "uint", $color)
    ;~ _GDIPlus_BitmapSetPixel($hBitmap, $x, $y, $color)
    If ($width = 2) Then
    DllCall($ghGDIPDll, "int", "GdipBitmapSetPixel", "handle", $hBitmap, "int", $x + 1, "int", $y, "uint", $color)
    ;~ _GDIPlus_BitmapSetPixel($hBitmap, $x + 1, $y, $color)
    ElseIf ($height = 2) Then
    DllCall($ghGDIPDll, "int", "GdipBitmapSetPixel", "handle", $hBitmap, "int", $x, "int", $y + 1, "uint", $color)
    ;~ _GDIPlus_BitmapSetPixel($hBitmap, $x, $y + 1, $color)
    ElseIf ($width = 2) And ($height = 2) Then
    DllCall($ghGDIPDll, "int", "GdipBitmapSetPixel", "handle", $hBitmap, "int", $x + 1, "int", $y + 1, "uint", $color)
    ;~ _GDIPlus_BitmapSetPixel($hBitmap, $x + 1, $y + 1, $color)
    EndIf
    If $bPreview Then
    $hBmp_GDI = _GDIPlus_BitmapCreateHBITMAPFromBitmap($hBitmap)
    _WinAPI_DeleteObject(GUICtrlSendMsg($iPic, 0x0172, 0x0000, $hBmp_GDI))
    _WinAPI_DeleteObject($hBmp_GDI)
    EndIf
    EndIf
    EndFunc

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

    Func Generate($iWidth, $iHeight, $iRoughness)
    DivideGrid(0, 0, $iWidth, $iHeight, Random(0, 0.99999), Random(0, 0.99999), Random(0, 0.99999), Random(0, 0.99999), $iWidth + $iHeight, $iRoughness)
    Return True
    EndFunc

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

    Func Rectify($iNum)
    If $iNum < 0 Then Return $iNum = 0
    If $iNum > 1 Then Return $iNum = 1
    ;~ $iNum = ($iNum < 0) ? 0 : $iNum
    ;~ $iNum = ($iNum > 1.0) ? 1 : $iNum
    Return $iNum
    EndFunc

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

    Func Displace($SmallSize, $gBigSize, $gRoughness)
    Return (Random(0, 1) - 0.5) * $SmallSize / $gBigSize * $gRoughness
    EndFunc

    [/autoit]

    Hier kann man schön die Grenzen von AutoIt sehen, was die Geschwindigkeit angeht. Mein Notebook schaft ca. 15000 Pixels pro Sekunde.

    Gruß,
    UEZ

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

    4 Mal editiert, zuletzt von UEZ (27. April 2014 um 11:05)

  • Durch Andys Verlinkung habe ich mich gerade wieder an etwas erinnert...
    Vor einiger Zeit habe ich mal eine ziemlich umfangreiche Version in Bezug auf Prozedurale Grafiken in AutoIt gebastelt. Die bietet wesentlich mehr als die verlinkte Version. Wenn ich mich recht erinnere z.B.
    - Eigene Funktionen IN der Prozedur (man kann der Prozedur also eigene Funktionen verpassen, sodass man mit einem einheitlichen Interpreter arbeiten kann der von Haus aus nur wenige Funktionen besitzt).
    - Erzeugen von Objekten (Brush/Pen/Bitmap/usw) IN der Prozedur und anschließendes verwenden.
    - Echte Parameter zum Rendern (man kann ein Bild mit verschiedenen Parametern ausstatten, sodass es z.B. Animiert werden kann, oder Seeds für Zufallsfunktionen gesetzt werden).
    - Animationen (werden allerdings gepuffert, da eine Echtzeitanzeige zu langsam wäre), es ist möglich Die gleiche Animation in unterschiedlichen Frameraten und Auflösungen zu rendern.

    Das wirkliche Schmuckstück ist aber leider noch unvollendet: Prozeduren in Prozeduren. So kann man z.B. eine Animation erzeugen die eine Animation enthält, die eine Animation enthält, ..., usw. Mit dieser Funktionalität ließen sich komplette simple Animationsfilmchen erzeugen. (je nach Schachtelung kann das Rendern aber mal 5Minuten dauern^^).
    Ton wird nicht unterstützt, da ich mich damit nicht auskenne.
    Ich werde das Skript morgen mal suchen und schauen ob ich es Benutzerfreundlicher und Forentauglich zurechtbiegen kann.

  • Habs gefunden.
    Wer reinschauen möchte darf gerne die Test.au3 zünden, sollte mit der aktuellen Stable laufen. Habe aber jetzt noch nichts daran verändert, das ist noch sehr unfertig :)
    Bitte die Kommentare in der Test.au3 beachten, sonst werden die Bilder falsch geladen...

  • Hi,
    die Konzepte sind (soweit ich das beurteilen kann) durchaus fähig, eine Demo zu erstellen. Ich habe bei "Demo" aber maximal das 4K-Format im Auge.
    Das was definitiv fehlt, ist ein COMPILER!
    Und das nicht mal für sämtliche API-Funktionen, sondern lediglich für die Berechnungen.
    Denn das, was die Zeit kostet, ist der von mir auch bei der Entwicklung von AssembleIt()/OpenCL-Wrapper angepeilte "inner Loop". Was GDI(+)/OpenGL/Direct3D können, sollte man damit auch machen. AutoIt ist ideal, die "Umgebung" bereitzustellen, d.h. Darstellung der Fenster usw.
    Auch die Syntax ist simpel.
    Klar könnte man als Zwischenschritt die Berechnungs-Funktionen in Assembler/C(++)/FreeBasic-Dll´s auslagern, aber das ist, ehrlich gesagt, eine Krücke!
    Viel schöner wäre doch, wirklich EINFACHE Schleifen und Berechnungen im AutoIt-Code direkt in den Speicher zu compilieren und dort auszuführen, ein "Mini-Compiler" sozusagen. Aber das ist wohl etwas viel verlangt, aber was meint ihr?
    Wobei ein Compiler, welcher CPU-Code erzeugt, um Grafiken darzustellen, imho völlig daneben ist.... ;(

    Also doch OpenCL/GL in C++?

  • Ich habe bei "Demo" aber maximal das 4K-Format im Auge.
    AutoIt ist ideal, die "Umgebung" bereitzustellen, d.h. Darstellung der Fenster usw.

    Aber da wir ja dann anscheinend trotzdem noch AutoIt verwenden wie es uns momentan zur Verfügung steht, wie willst du dann die 4K Grenze erreichen?

    Viel schöner wäre doch, wirklich EINFACHE Schleifen und Berechnungen im AutoIt-Code direkt in den Speicher zu compilieren und dort auszuführen, ein "Mini-Compiler" sozusagen. Aber das ist wohl etwas viel verlangt, aber was meint ihr?

    Wir haben doch schon mehrere Projekte die Assembler in AutoIt einbinden und zur Laufzeit benutzen, ist es dann wirklich so schwer das ganze mit einem geeigneten Compiler zu machen? Oder willst du Teile des AutoIt Codes kompilieren und nicht nur einen String mit z.B. C Code?

  • Ja, natürlich ist die 4K-Grenze nur mit einem compilierten und ggf. auch noch gepacktem Code möglich.
    Die Frage ist, wie man dort hin kommt....

    Natürlich haben wir einige AutoIt/ASM-Varianten am Start, welche davon letztendlich benutzt wird, bliebe jedem natürlch selbst überlassen!
    Diese AutoIt/ASM-Umgebung würde ich allerdings fürs Testen der Funktionen verwenden, einfach aufgrund der problemlosen Entwicklung.
    Genausogut könnte man Blitz/Power/Free-Basic oder C++ / Pascal usw. verwenden.
    Zur Not die HLL-Entwicklung mit diesen Programmen durchführen, und den vom Compiler erstellten Code handoptimieren! Wobei DAS natürlich eine Möglichkeit wäre :D

    Das letztendliche Programm müsste dann sowieso als "Standalone" durch den Assembler gejagt werden!
    Mir geht es in erster Linie darum, möglichst viele Leute mit unterschiedlichsten Vorlieben einer Entwicklungsumgebung/Sprache zusammen EIN Programm erstellen zu lassen!
    Gerade die Erstellung prozeduraler Grafiken kann in VIELE kleinere Funktionen (Filter usw) aufgeteilt werden.
    Jede diese Funktionen könnte von jedem Mitglied des Teams verändert/optimiert werden, ohne dass die anderen in ihrer Arbeit eingeschränkt werden.
    So könnte derjenige, der gerade eine tolle Idee für "Nebel" hat, diese Funktion abändern/erweitern, mit seiner individuellen Umgebung bearbeiten und diese Funktion allen anderen zur Verfügung stellen.
    Alle Funktionen liegen online und werden einzeln geladen und vom fertigen Programm zusammengefügt und ausgeführt.
    Zur Not kann man natürlich auch AutoIt native für die Programmierung einer Funktion verwenden, dann dauert der Aufbau der Grafiken etwas länger ;)

    minx, stell doch mal bitte diese tolle Grafik (Sonnenuntergang) online, damit klar wird, wie ich mir das mit den "vielen Funktionen" so vorstelle^^. Ich denke, dieses Beispiel ist als AHA-Effekt geeignet..

  • Danke!

    Die einzelnen Funktionen nun per Wasweisich-Compilersprache als bspw. DLL-Funktion zur Verfügung gestellt (dort kann man den ASM-Code am einfachsten extrahieren), erweitert durch "bewegtes" Wasser :P , dazu noch ein aus der Sonne auf den Betrachter zukommendes, drehendes 3D-Autoitlogo, und fertig ist die erste 1k-Demo :D

    Los gehts :rock:

  • Das ganze mal in einer kompilierten Sprache umgesetzt und durch kodek gejagt. Raus kam eine 8k (6,5k). Neues Feature: Geschwindigkeit, ESC beenden, SPACE neues Bild. Allerdings habe ich die seitliche Begrenzung der Sonne entfernt, d.h. es kann auch mal ein unsinniges Bild rauskommen :D

    Achja, beim Testen Antivirus abschalten, sonst gibts ne Kernschmelze (VirusTotal 20/51) ;) .

  • minx: hast du gerreg.au3 auch in einer leserlichen Version da?

    Cooles Ding. 8o:thumbup:

    Jetzt würde mich noch die Erklärungen der einzelnen "Chapters" interessieren.

    Und was ist Kodek?

    Gruß,
    UEZ

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Ich habe nur noch mehrere noch unleserliche Versionen.

    Das ist aber schade, denn es ist die Hölle eine kleinere Auflösung zu wählen und den puristischen Code anzupassen, ohne Hintergrundwissen. :(

    Gruß,
    UEZ

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯