Infinite Image Zoom Flight build 2018-01-10

  • Hier zwei kleine Skripte zum Jahreswechsel! :)

    Zoomquilt:

    Arkadia:


    Quelle der Inspirationen / Bilder: http://zoomquilt.org/, http://arkadia.xyz


    Ist schon ziemlich krass, wie flüssig der Zoom im Browser läuft...


    PS: Zu Risiken und Nebenwirkungen lesen Sie die Packungsbeilage und fragen Sie Ihren Arzt oder Apotheker!

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

    13 Mal editiert, zuletzt von UEZ (10. Januar 2018 um 11:48) aus folgendem Grund: 1) Update 2) Bugfix in Arkadia Code 3) Code Cleaning 4) Zoom Routine geändert 5) Zoom nun per Mouse in beide Richtungen 6) Multi Monitor Code angepasst

  • Danke Oscar!

    Ich habe noch ein zweites Beispiel hinzugefügt. Beide Scripte laufen jetzt im Vollbildmodus ab.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Das Stretchblt() ist, GDI+-typisch SCH***-langsam:thumbdown:

    Bei mir ( i7-7500U CPU @ 2.70GHz FullHD) dauert der Stretchblt() sagenhafte 25-35ms. Das BitBlt() gerade mal 1 ms....

    Das wäre doch für Oscar ne schöne Übung für SSE-Befehle in ASM:rofl:

  • Das Stretchblt() ist, GDI+-typisch SCH***-langsam

    Stretchblt() ist GDI und nicht GDI+ (Klugshitting :P)

    Na dann schaue dir mal die GDI+ Variante an.

    Btw, ich habe die Source Codes ein bissl optimiert.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Kuhle Sache! :)

    Mir fällt auf, dass das Bild immer leicht unscharf wird beim Reinzoomen, bis das nächste Bild kommt.

    Ist bei der Homepage Version nicht so. :D

    Mein Prozessor packt gerade so 30-40 FPS.

    Mit Irrlicht würde das bestimmt mit paar 1000 FPS laufen.

  • Eine AlphaBlend Funktion mit Skalierungsmethode haben wir vor ca. 5 Jahren doch mal irgendwo in ASM gebastelt... Ich finde sie aber nicht mehr :(

  • Alphablend hatte ich u.a. gecoded, war SEHR schnell, aber Skalierung? Bestimmt hatte ich aber auch so eine Funktion irgendwo....schaumamal, ansonsten bietet sich SSE wirklich an, 4 (in 64-Bit wären es 8) Pixel gleichzeitig in einer Handvoll Takte zu berechnen hätte was.

    Mein Prozessor packt gerade so 30-40 FPS.

    Mit Irrlicht würde das bestimmt mit paar 1000 FPS laufen.

    OpenCL/OpenGL ftw.

  • Alpha Blend kann man auch mit GDI+ hinbekommen.

    Ich muss mal den JS Code genauer anschauen, wie dort die Implementierung ist.

    xSunLighTx3 du kannst die Zeile

    AutoIt
    _WinAPI_SetStretchBltMode($hDC, $STRETCH_HALFTONE)

    auskommentieren, dann wird's schneller.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Wer Lust hat den JS Code zu analysieren, um zu sehen, warum in JS die Animation jeweils beim nächsten Bild nicht so aussieht, wie es oben aussieht, kann hier reinschauen:

    https://codepen.io/Dunced/pen/ygNVeM

    Habe ich per Zufall entdeckt.

    Ich versuche gerade den Code zu verstehen...:/

    Edit: Krass, die zeichnen 3 Bilder parallel, sodass nicht beim Wechsel zum nächsten Bild dies sichtbar wird. Clever:!:Demnächst kommt das Update!

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

    Einmal editiert, zuletzt von UEZ (7. Januar 2018 um 22:42)

  • Ok, ich habe die Trippel Bilder Technik implementiert -> siehe Post #1.

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Genial! :):rock:

    Die neuen Versionen sind unglaublich schnell (auf meinem Rechner mit 2560x1440 px Auflösung, bei beiden ca. 120 fps).

    Und Deine Arkadia-Version gefällt mir besser als die JS-Version, weil sie nicht diesen Farbfilter darüberlegt. :klatschen:

    Du brauchst also nicht in die Hände spucken und eine schnelle ASM Version coden. ;)


    Sehr schön, aber das Angucken macht einen auf Dauer irgendwie wahnsinnig. :)

    Hmm, sollte noch einen Hinweis posten, dass das anschauen auf Dauer wahnsinnig machen kann, und ich dafür nicht haftbar gemacht werden kann. ;)

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯

  • Du brauchst also nicht in die Hände spucken und eine schnelle ASM Version coden.

    ...abwarten^^

    Bei mir ist auf 3 Rechnern trotz 80-120FPS bei der AutoItversion immer noch eine unterschiedliche Geschwindigkeit im Endloszoom festzustellen. Im Browser gibt es weder (Mikro-) Ruckler noch dieses "pumpen".

    Ich habe jetzt die schleife eingehend ausgestoppt und festgestellt, dass die Schleife

    Code
    For $e = 0 To 2
                $d = $v - $q / 2 * $c
                $f = $w - $r / 2 * $c
                $g = $q * $c
                $l = $r * $c
                $hObj = _WinAPI_SelectObject($hMemDC, $a[$e])
                _WinAPI_StretchBlt($hDC_backbuffer, $d, $f, $g, $l, $hMemDC, 0, 0, $iW, $iH, $SRCCOPY)
                $c *= 0.5
     Next

    massive Unterschiede bei den einzelnen Stretchblt-Zeiten hat! Massiv heisst, der jeweils erste Stretchblt dauert ca. 5-10x länger als die beiden folgenden?!

    Ich untersuche das mal genauer, inwieweit _WinAPI_SelectObject($hMemDC, $a[$e]) da einen Anteil dran hat. Ich vermute stark einen Zusammenhang mit dem darauffolgenden _GDIPlus_GraphicsDrawStringEx bzw. Bitblt.

  • Ich vermute, dass die Unterschiede in der Größe der Bilder entstehen:

    Btw, ich habe den Code aktualisiert. Nun kann man per Maus in beide Richtungen "fliegen".

    Auch am Arsch geht ein Weg vorbei...

    ¯\_(ツ)_/¯