PureBoard

Hey, Leute hab schon lange nichts mehr reingestellt, weil ich wohl ziemlich mit dem Studieren beschäftigt bin.
Hier mal wieder ein kleines nettes Progrämmchen:

Ein Fraktal-Zoomer! Damit kann mal solch eigenartige Bilder erstellen:

Screebshot:


Download:
http://hosting.alexandernaehring.eu/=OD ... I4OTc3NzM=

Bitteschön!
wer Lust hat schaut auch mal auf meiner Facebookseite vorbei : https://www.facebook.com/MotoMotoGames und schenkt mir ein "like" (Ja ich hasse sie auch, diese "like"-Bettler...) . Dort gibt es auch eine schöne Fraktal-Gallerie die mit diesem Programm erstellt wurde.

Wer Interresse am Code hat, oder generell Interresse hat wie so etwas funktioniert braucht sich nur zu melden.

Ich würde niemals freiwillig auf Like-Buttons klicken.
Aber ich kann dir sagen, dass ich dein Fraktal-Zoomer gut finde.

Willkommen im Club ^^, hab ich mir auch schon progrmamiert.

Ich habe mir sogar eine eigene Include geschrieben, um mit Zahlen höherer genauigkeit als Double zu arbeiten, damit ich mir die interessanten Strukturen in hoher Tiefer ansehen kann.
Leider hat dass dann nicht mehr viel mit "Zoomer" zu tun, weil das Rendern doch schon erheblich länger dauert, ohne Double, sodass ich dann eine Berechung geschrieben hat, die mehrere PCs nutzt (bis heute leider nicht fertig).

Was mich bei dir etwas wundert ist, das dein Programm "recht langsam" (bitte nicht falsch verstehen) iteriert.
Hast du das Rendern in der Iterationsschleife?

PS: Hier mal ein nettes Bild von mir:
Re = -0.40635307849919222
Im = 0.60165241285534243
Auflösung = 1.5625*10^-16 / Pixel (also nahe am limit von Doubles)


Was bei deinem Programm noch fehlt wäre:

• Anzeige der Auflösung / Zoom
• manuelle Koordinateneingabe

Was mir gefällt ist, dass du beim zoomen die alten Pixel da lässt, werden diese eigentlich dann noch mal berechnet, oder nur noch die fehlenden?

Tolle Bilder, tolles Programm .

STARGÅTE hat geschrieben:Was mir gefällt ist, dass du beim zoomen die alten Pixel da lässt, werden diese eigentlich dann noch mal berechnet, oder nur noch die fehlenden?

Beim reinzoomen müssen diese zwangsweise neu berechnet werden, da ein Pixel des vorherigen Zustands mehrere Pixel des reingezoomten Zustands überdeckt. Aber so etwas kann man gut dadurch parallelisieren, dass man das Bild aufteilt und jeder Thread berechnet einen Teil.

DarkDragon hat geschrieben:Beim reinzoomen müssen diese zwangsweise neu berechnet werden, da ein Pixel des vorherigen Zustands mehrere Pixel des reingezoomten Zustands überdeckt.

Eben nicht. Der Pixel repräsentiert eine exakte position die erhalten bleibt wenn man ranzoomt (mit *2).
Beispiel:
Habe ich vorher: -4, -2, 0, 2, 4 berechnen lassen, und zoome nun mit Faktor 2 ran, so haben die vorher berechneten Werte immer noch gültigkeit und ich muss nur noch restlichen berechnen um auf -2, -1, 0, 1, 2 zu kommen.

Ich muss also beim x2 zoomen immer nur 3/4 der Pixel errechnen.
Bei einem 4-Kern-Prozessor, kann ich also sehr schön, 3 Kernen jeweils 1/4 geben und dem 4. Kern das Rendern der "fertigen" Pixel geben.

Hi,

es gibt aber auch die Möglichkeit die Berechnung über die Shader (minimalCPUs) der Grafikkarte durchzuführen. Ein Beispiel habe ich mal zu meinem Shadertutorial dazugepackt. Änderung der Berechnungstiefe und double statt float lassen sich auch mit einem Shader errreichen...

Gruß Michael

STARGÅTE hat geschrieben:

DarkDragon hat geschrieben:Beim reinzoomen müssen diese zwangsweise neu berechnet werden, da ein Pixel des vorherigen Zustands mehrere Pixel des reingezoomten Zustands überdeckt.

Eben nicht. Der Pixel repräsentiert eine exakte position die erhalten bleibt wenn man ranzoomt (mit *2).

Ok, ich war davon ausgegangen, dass man nicht mit Ganzzahlen zoomt (da du gleichzeitig ja auch vorgeschlagen hast, die Sichtgrenzen manuell eingeben zu können), wodurch die Pixelpositionen dann zwischen zwei anderen Pixeln liegen könnten.

mpz hat geschrieben:Hi,

es gibt aber auch die Möglichkeit die Berechnung über die Shader (minimalCPUs) der Grafikkarte durchzuführen. Ein Beispiel habe ich mal zu meinem Shadertutorial dazugepackt. Änderung der Berechnungstiefe und double statt float lassen sich auch mit einem Shader errreichen...

Gruß Michael

Ja, das ist im allgemeinen ganz gut möglich. Nur hast du selbst erkannt, dass es an den Fließkomma-Grenzen ohne komplexere GPGPU Anweisungen scheitert. Das einzige was man tun könnte wäre ein Framebuffer als "Big-Int" zu missbrauchen.

Man kann die Geschwindigkeit schon vervierfachen, wenn man einfach nur SSE2 oder SSE3 nutzt. Da PB selbst nicht dahingehend optimiert, muss da eben mit ASM ran. Das hatte ich teilweise bei meiner Raytracing-Engine damals schon gemacht.

Hey, Leute. Ich find cool was ihr schon so mit Fraktalen gemacht habt! Also mein Programm ist wohl desshalb noch ziemlich langsam und hängt manchmalm, weil ich bis jetzt noch absolut kein multi-threading benutzt hab. Nichtmal um Bedienung von Berrechnung zu trennen ...

STARGÅTE hat geschrieben:werden diese eigentlich dann noch mal berechnet, oder nur noch die fehlenden?

Es werden nur die fehlenden berechnet. Jedoch braucht das umrechnen der alten Pixel auf das neue Bild auch ein wenig Rechenleistung, desshalb hängt es kurtz wenn man rein oder rauszoomt.