Fractal-Visualisierung in Delphi

[everdream]

1.-3. OK
4. Werd ich mir ansehen, kann mir aber grade nich vorstellen wie du das meinst.

5.: Jau, da liegt ja mein Problem: Zu jedem neuen Frame müssen erst alle Pixel neu berechnet werden. D.h. ich muss für jeden Frame die Bitmap komplett überprüfen und jeden Pixel, der sich verändert hat (was meißtens sehr viele sind) neu "malen". Die Parameter in der Berechnung hab ich dafür auch schon variabel eingestellt (wie gesagt, es gibt schon ne version, bei der der user manuel zoomen und sich auf dem bild bewegen kann)
6.: Joa, das stimmt auf jeden fall. ich denk drüber nach.
7.: dachte erstmal an einen zufälligen/om programm gesteuerten zoom.

Kennst du fractint? nein...

[Muetze1]

Zitat:

Zitat von everdream

5.: Jau, da liegt ja mein Problem: Zu jedem neuen Frame müssen erst alle Pixel neu berechnet werden. D.h. ich muss für jeden Frame die Bitmap komplett überprüfen und jeden Pixel, der sich verändert hat (was meißtens sehr viele sind) neu "malen". Die Parameter in der Berechnung hab ich dafür auch schon variabel eingestellt (wie gesagt, es gibt schon ne version, bei der der user manuel zoomen und sich auf dem bild bewegen kann)

Wenn gezoomt wird, dann sind doch zu 98%-100% alle Pixel neu zu berechnen. Und das musst du doch so oder so machen - wie willst du sonst wissen, ob der Pixel eine neue Farbe hat? Du brauchst schliesslich einen Vergleichswert.

Und aus deiner Erklärung könnte man vermuten, dass du die Pixel berechnest und dann erstmal vergleichst, ob der Pixel sich geändert hat. Das ist doch egal und kostet nur mehr Zeit - einfach Pixel berechnen und auf das OffScreenBitmap malen - egal ob geändert oder nicht.

Zitat:

Zitat von everdream

Kennst du fractint? nein...

Naja, zu den guten DOS Zeiten war das ein wirklich gutes Programm für Fraktale und es war Open Source. Die Formeln und Parameter sind schön dargestellt, etc. Es ist immernoch gut verfügbar, z.B. hier. Du kannst die DOS Version soweit auch noch unter 32 Bit Windows < Vista nutzen.

Schnelleinstieg fractint:

- ENTF/DEL: Auflösung wählen. Auch virtuelle Auflösungen für reine Bildberechnungen möglich.
- t - wählt die Formel bzw. den Fraktaltypen

auf dem generierten Fraktal dann folgende:

- Bild Hoch/Page Up/Bild runter/Page Down um ein Zoomrechteck zu positionieren
- Cursortasten beim Zoomrechteck zur Positionierung (mit ALT &/| STRG zusätzlich gehts schneller, unproportionaler Zoom, etc)

um das Zoomrechteck zu bestätigen und dessen Inhalt auf dem Screen berechnen zu lassen: ENTER

[Namenloser]

Hi.
Guck dir mal Graphics32 an. Die sind verdammt schnell.

[Nuclear-Ping]

Ich hab sowas ähnliches mal angefangen zu machen. Allerdings keine Mandelbrot-Menge oder so, sondern ein "Müller Fraktal" aus dem "Global Scaling". Die grafische Darstellung hab ich in OpenGL gemacht. Ist aber noch total unoptimiert, unfertig und langsam. Aber die Ausgabe, um das Prinzip zu vermitteln, funktioniert schonmal.

Wenn du Interesse hast, kann ich dir den Source geben.

[edit]
[OT]
LoL :lol: NamenLozer, hab mir grad nochmal den Beitrag aus deinem ">O<" Link in deiner Sig durchgelesen. Mußte wieder herzlich lachen ... Was waren das für Zeiten. :mrgreen:
[/OT]
[/edit]

[turboPASCAL]

Da hab ich doch mal was Vorbereitetgehabt. :mrgreen:

TheMandelbrötchen

[Kroko1999]

Zitat:

Zitat von NamenLozer

Hi.
Guck dir mal Graphics32 an. Die sind verdammt schnell.

Lohnt sich nicht wirklich, habe ich neulich erst ausprobiert mit
PixelFormat := pf24Bit und Scanline bist Du genauso schnell.

[everdream]

erstmal: Nen Vergleich, ob der Pixel sich verändert hat oder nicht, hab ich in meinem aktuellen Programm nicht drin.

Hm, also wenn ich jetzt alles noch etwas optimiere, mit Scanline usw. arbeite und die OffScreenBitmap dann komprimiert speichere, dann müsste ich einfach x-frames im voraus berechnen und dann mit meinen vielen einzelbildern ne art diashow starten, nur halt schneller, um nen mehr oder weniger flüssigen zoom zu erzeugen. fractint ist ja leider auch nicht bedeutend schneller.

Sowas muss man doch irgendwie hinkriegen.

[Kroko1999]

Zitat:

Zitat von everdream

erstmal: Nen Vergleich, ob der Pixel sich verändert hat oder nicht, hab ich in meinem aktuellen Programm nicht drin.

Der dürfte imho auch wenig bringen, erst testen und dann setzen, dann kannst auch gleich setzen :!:

Zitat:

Hm, also wenn ich jetzt alles noch etwas optimiere, mit Scanline usw. arbeite und die OffScreenBitmap dann komprimiert speichere, dann müsste ich einfach x-frames im voraus berechnen und dann mit meinen vielen einzelbildern ne art diashow starten, nur halt schneller, um nen mehr oder weniger flüssigen zoom zu erzeugen.

Gute Idee, sollte machbar sein, aber warum komprimieren :?:

Zitat:

fractint ist ja leider auch nicht bedeutend schneller.

Ich glaube, da irrst Du wirklich, mach doch mal ein paar Tests!

Zitat:

Sowas muss man doch irgendwie hinkriegen.

Ob das wirklich live (CPU-Speed) ist :?:

[Muetze1]

Zitat:

Zitat von Kroko1999

Lohnt sich nicht wirklich, habe ich neulich erst ausprobiert mit PixelFormat := pf24Bit und Scanline bist Du genauso schnell.

Na dann setz dich gleich nochmal ran und ändere es ab auf pf32Bit, das sollte nochmal ein klein wenig schneller sein, da jeder Pixel an einer gerade Adresse liegt und der Prozessor somit keine zwei Schreibzyklen drehen muss.

Zitat:

Zitat von everdream

die OffScreenBitmap dann komprimiert speichere

So war das nicht gemeint. Du sollst abgespeicherte Screenshots bzw. berechnete Bilder komprimiert ablegen. Die berechneten Bilder können ruhig ein paar MB gross sein und sollen das auch bleiben, weil nur so kann man sie schnell malen. Sonst müsste er jedesmal zum einen komprimieren und beim zeichnen dekomprimieren. Grundsätzlich: wenn es um die Laufzeitbilder geht, dann lass sie unkomprimiert. Was stören dich vllt. 100 MB bei Bilddaten? Die brauchst du aktiv und so gesehen sind 100 MB nicht viel. Ich habe Anwendungen die mit riesigen Datenmengen umgehen und die kommen auf 600 MB Speicherverbrauch etc. Somit mach dir keine Sorge, 2 GB sind dir von Windows zugesichert...

[calculon]

Zitat:

Zitat von Kroko1999

Ob das wirklich live (CPU-Speed) ist

Das bezweifle ich auch stark. Für so eine Qualität muss mit gängigen Rechnern für jedes Bild 'n ganzes Weilchen gerechnet werden. Ich schätze mal da lief der Rechner schon mindestens 'ne Nacht durch...

PS: Auch sehr cool...