Ultragenauer Mandelbrot-Renderer

[zeckensack]

Und sonst? Gib' mal mehr Feedback.
Maus-Lock brauchbar?
Mööönsch, lob' mich zumindest mal für den Performanceschub :bäh:
Originally posted by aths
Bei mir produziert diese Version an den schwierigen Stellen die besseren Bilder. Außerdem sind in der Boundary-Tracing-Version noch immer Optimierungs-Artefakte zu sehen, die nicht durch das eigentliche Tracing-Verfahren zustande kommen, sondern durch das voreilige Festlegen was nicht mehr berechnet wird.Also ich weiß nicht was du meinst ... daß da Fehler entstehen, darüber sind wir uns einig. Über die Gründe anscheinend nicht. Ich sage, es ist Aliasing, und es ist zu erwarten, daß der Algorithums daran scheitert. Schließlich reißt die Kontur dort tatsächlich ab.
... was nicht heißen soll, daß ich nicht versuchen werde das zu verbessern.

Aber was meinst du mit 'voreilig'? Da ist nichts voreilig, im Gegenteil: mit dem Füllen wird erst dann angefangen, wenn die Kontursuche bis zum Ursprungspunkt zurückgekommen ist, also lückenlos die Kontur bestimmt wurde. Daß innerhalb der bestimmten Kontur durch Aliasing weitere Details liegen, das hat mit dem Tracing nichts zu tun. Das kann auch mit der Rechteckmethode passieren, allerdings hilft hier idR der Zufall.

Schau dir oben die 'Glitch'-Skizze noch mal an. Auch eine Rechteckserkennung kann den gleichen Fehler machen.

Kannst du noch eine Datei mit "echten" Rechtecken machen? Inwiefern echt?

Bisheriger Algorithmus funktioniert so:
0)Ein Bildschirmfüllendes Rechteck auf den Stack schmeißen

Einsprung in refine_image:
1)Wenn der Stack leer ist, Abbruch. Das Bild ist fertig.
2)Rechteck vom Stack abgreifen
3)in der oberen linken Ecke einen Referenzwert ausrechnen
4)Horizontale Kanten untersuchen und mit dem Referenzwert vergleichen. Bei der ersten Ungleichheit Sprung zu 7
5)Vertikale Kanten untersuchen. Bei der ersten Ungleichheit Sprung zu 7
6)Rechteck mit der Referenzfarbe füllen, 'goto' 1

7)Rechteck in zwei annähernd gleich große Hälften zerteilen
8)beide Hälften auf den Stack schmeißen
9)'goto' 1
_________________________

Was meinst du nun mit 'echten' Rechtecken???

[aths]

Originally posted by zeckensack
Und sonst? Gib' mal mehr Feedback.
Maus-Lock brauchbar?Jopp. Jetzt hätte ich noch gerne eine Reaktion (ein Bild) während der Preview-Berechnung.
Originally posted by zeckensack
Aber was meinst du mit 'voreilig'? Da ist nichts voreilig, im Gegenteil: mit dem Füllen wird erst dann angefangen, wenn die Kontursuche bis zum Ursprungspunkt zurückgekommen ist, also lückenlos die Kontur bestimmt wurde. Daß innerhalb der bestimmten Kontur durch Aliasing weitere Details liegen, das hat mit dem Tracing nichts zu tun. Das kann auch mit der Rechteckmethode passieren, allerdings hilft hier idR der Zufall.Du nutzt doch nach wie vor das Preview, um die Rand-"Tiles" zu bestimmen?
Originally posted by zeckensack
Was meinst du nun mit 'echten' Rechtecken??? Dass er immer die Kanten malt, egal ob die Farbe gleich ist oder nicht und bei gleicher Farbe das Rechteck dann füllt. Das ganze ist wie gesagt auch adaptiv möglich: Verfeinerung immer in 2-er Schritten. Wenn man z.B. mit der Auflösung X/32 x Y/32 beginnt, gibts rechts und unten einen Rand. Dieser könnte dann zur Not per Brute Force berechnet werden, oder noch besser ebenfalls mit der Rechteck-Methode, nur dass der Rand nicht adaptiv verfeinert wird, sondern stur mit "echten Rechtecken" gerendert.

[aths]

Außerdem melde ich gleich mal die Frage an, ob du eine Paletten-Stretch-Funktion einfügen könntest. Problem: 256 Farben sind "zu schnell" durchgelaufen. Folge: Aliasing.

Idee: Interpolation um Faktor 16. Sollte mindestens 2x hintereinander möglich sein, so dass man im ersten Schritt eine Palette von effektiv 255 x 256 = 4080 Farben hat, und im 2. Schritt von 65280 Farben. Es gäbe auch Situationen wo man wirklich ganz ganz allmähliche Farbverläufe gebrauchen könnte, z.B. einen dritten Stretch zu dann insgesamt 1044480 Farben.

[Lost Prophet]

Also ich hätt so den vorschlag,
mit einer art Abfrage mit 4 versch Komponenten
1. x-koordinate
2. y-koordinate
3. radius
4. max_iterations

damit könnte man leicht kewle Stellen im Fraktal mit anderen austauschen (zb für user ohne webspace wie MICH)

weiters

ein Rückfunktion
die muss einfach nur die letzten koordinaten (in der Dos-box)aufrufen, falls fehlklick, schlechte stelle erwischt, etc


Für jede palette ein "places"


IRGENDETWAS (pop-up, ton, irgendwas)wenn die berechnung fertig ist (to-do-list leer ist)


und mehr farben


danke

axel

[Unregistered]

// Nicht ganz bei der Sache //

Könnte man sowas theoretisch auch in 3D ausgeben, also quasi ein 3D Modell erstellen anstatt des 2D Bitmaps ?
Oder lässt mit diesem MandelBrot, nur 2D machen ?

Ich glaub das würde zwar mehr als enorme Resourcen fressen,
nur aus Interesse halber frag ich mal nach.

btw. Respekt für deinen bisherigen MandelBrot Bäcker ^^ !

[ethrandil]

ehm, darf ich fragen wie das aussehen soll? ;)
Das sind doch alles Farbschichten ... was genau soll den in dem 3d-model transparent sein, damit man überhaupt strukturen erkennen kann :eyes: ?

Man könnte natürlich nur den schwarzen teil darstelllen.
Das wäre evtl. möglich, wenngleih ich nicht weiß, ob das so ohne weiteres möglich wäre!
Man msste mal schaun, was dabei rauskommt. Andererseits sind Kompleze Zahlen ja nur '2D' ! Also wird das schon schwierig ... frag nen Mathematiker :P

[aths]

Originally posted by ethrandil
ehm, darf ich fragen wie das aussehen soll? ;)
Das sind doch alles Farbschichten ...Genauer gesagt, Höhenstufen.

Es gibt auch eine Mandelbrot-Variante deren Dimension zwischen 3 und 4 liegt, was man dann darstellt sind Schnitte in diese Menge. Man kann auch das normale 2,x-D-Mandelbrotset sozusagen als Displacement Map interpretieren, aber dabei gehen in der Regel zu viele Details verloren.

[Ganon]

Hi,

hier mal ein Bild eines Pseudo 3D Apfelmännchens:

http://home.t-online.de/home/M.Hami/mand.jpg

P.S. Sieht zwar so aus aber noch habe ich keinen MAC! Ist nur ein KDE-Theme!

[aths]

Jo, nur wie gesagt sieht man dort kaum Details. Für einen auf Deep Zoom spezialisierten Renderer halte ich 3D-Darstellungen für nicht sinnvoll.

[Crazytype]

Kann der Staat nichtmal Leute wie euch Sponsorn? Ihr werdet mal bestimmt ganz große ;) Mann sollte euch mal nen 8-way Opteron mit 8 GB schencken.

[aths]

Originally posted by aths
Außerdem melde ich gleich mal die Frage an, ob du eine Paletten-Stretch-Funktion einfügen könntest. Problem: 256 Farben sind "zu schnell" durchgelaufen. Folge: Aliasing.

Idee: Interpolation um Faktor 16. Sollte mindestens 2x hintereinander möglich sein, so dass man im ersten Schritt eine Palette von effektiv 255 x 256 = 4080 Farben hat, und im 2. Schritt von 65280 Farben. Es gäbe auch Situationen wo man wirklich ganz ganz allmähliche Farbverläufe gebrauchen könnte, z.B. einen dritten Stretch zu dann insgesamt 1044480 Farben. Hm, das ist Unsinn. Man sollte immer volle 2-er Potenzen nehmen, also die 255 Farben lieber auf 65536 strecken.

Zum AA: Boundary Tracing würde wunderbar mit OGSS zusammenarbeiten :)

[MeLLe]

Originally posted by Crazytype
[...]
Mann sollte euch mal nen 8-way Opteron mit 8 GB schencken.
<aths-mode>
Dir tät ein Duden ganz gut. Sollte man Dir schenken.
</aths-mode>

j/k ;)

[zeckensack]

Originally posted by aths
Zum AA: Boundary Tracing würde wunderbar mit OGSS zusammenarbeiten :) Es würde auch mit Sparse Supersampling funktionieren, wenn sich alle Subsamples logisch in einer Zeile befinden. Siehe Attachment. Ein grau/weiß-Übergang sei hierbei ein Wechsel der logischen (=intern Vergrößerten) x/y-Koordinate. Das schwarze seien die Subpixel. Das Raster ist bei weitem nicht perfekt, dient nur zu Demo-Zwecken.

Wenn's noch nicht geklingelt hat, das heißt daß zB 4xSparse SS bei 600x600 Zielauflösung intern mit einem 2400x600er Koordinatenraum arbeiten würde.

Ich frage mich nur gerade, ob EER (der Vorteil von Sparse SS) überhaupt wichtig ist???

[zeckensack]

Originally posted by Crazytype
Kann der Staat nichtmal Leute wie euch Sponsorn? Ihr werdet mal bestimmt ganz große ;) Mann sollte euch mal nen 8-way Opteron mit 8 GB schencken. Das finde ich eigentlich auch :naughty:

[Xmas]

Originally posted by zeckensack
Ich frage mich nur gerade, ob EER (der Vorteil von Sparse SS) überhaupt wichtig ist???
Nicht wirklich, da "Kanten" ja nur in den großflächig einfarbigen Teilen vorkommen und dort ist je nach Palette minimale Glättung oftmals schon ausreichend. OG hat aber den Vorteil dass die Samples "optimale", gleichmäßige Abstände haben, also auch zu den Nachbarsamples.

[aths]

Originally posted by aths
Beim Mandelbrot ist OGSS gar nicht mal so nachteilhaft. Es geht weniger darum, Kanten zu glätten (da man ohnehin lieber Paletten nehmen sollte, die sanfte Farbübergänge haben) sondern vor allem darum, im "Gegrissel" noch so gut es geht Strukturen ausmachen zu können.

[aths]

*Bump* und Ergänzung: FSAA macht erst bei einer "gestreckten" Palette richtig sind, sonst bleibts bei "Gegrissel".

[zeckensack]

Ja doch, bitte etwas Geduld =)

[Piffan]

Nun bin ich doch mal neugierig: Hat das irgendeinen Nährwert oder ist das brotlose Kunst? :D

Kann man damit prüfen, ob die FPU- Genauigkeit einer Graka tatsächlich so hoch ist wie angegeben? Habe natürlich keine besondere dabei im Augen.... iwo...

Irgendein Wissenshunger muß sich doch mit diesem Mandelbrot- Zeugs stillen lassen. Oder isses Spaß an der Freud, eine Herausforderung?

Falls ich Eure Kreise störe; no Problem, bin auch schon wieder wech...

[ethrandil]

Originally posted by Piffan
Nun bin ich doch mal neugierig: Hat das irgendeinen Nährwert oder ist das brotlose Kunst? :D

Kann man damit prüfen, ob die FPU- Genauigkeit einer Graka tatsächlich so hoch ist wie angegeben? Habe natürlich keine besondere dabei im Augen.... iwo...

Irgendein Wissenshunger muß sich doch mit diesem Mandelbrot- Zeugs stillen lassen. Oder isses Spaß an der Freud, eine Herausforderung?
Ein Ungläubiger !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

;) Also, ich habe gehört es wird an organischen Displays gearbeitet. Dann kannst du das Brot selbstverständlich essen :D Ansonsten erfreue dich einfach an der hübschen mathematik :)

Die FPU-Genauigkeit könnte man wahrscheinlich schon prüfen, dazu müsste das ganze aber auf der Grafikkarte laufen, was hier nicht der fall ist. Außerdem bräuchtest du gute Augen :P

[Piffan]

Aha, also doch Spaß und Spiel -äh- geistige Wissenschaft...;)

Wenn das mal angeht mit den organischen Displays, dann wüsste ich ganz genau, was ich mir von denen darstellen lassen würde....jedenfalls anfangs nix essbares, danach vielleicht :naughty:

[zeckensack]

Originally posted by Piffan
Nun bin ich doch mal neugierig: Hat das irgendeinen Nährwert oder ist das brotlose Kunst? :D
Nujo, ich könnte mich auch hinstellen und behaupten, daß ich Grundlagenforschung im Bereich Numerik betreibe, aber das wäre wohl etwas dick aufgetragen :)

Kann man damit prüfen, ob die FPU- Genauigkeit einer Graka tatsächlich so hoch ist wie angegeben? Habe natürlich keine besondere dabei im Augen.... iwo...Die Graka hat damit nichts zu tun. Das Bild wird komplett in Software erzeugt.
Btw, das besondere daran ist die Präzision des verwendeten Fließkommaformats. 192bittige Mantissen gibt es nicht in PC-Hardware, weder in CPUs noch auf Grakas. CPUs kommen intern bis 65 Bit (Standard-FPU ab Pentium I), Grakas bis
24 Bit (NV30).
Eine komplette Fließkommazahl (Mantisse+Exponent+Vorzeichen) belegt sogar schlappe 256 Bit, davon werden allerdings 'nur' 224 Bit wirklich genutzt.

Irgendein Wissenshunger muß sich doch mit diesem Mandelbrot- Zeugs stillen lassen. Oder isses Spaß an der Freud, eine Herausforderung?Fingerübung.
Zerstreuung.
Herausforderung. Auf jeden Fall. Das Mandelbrot-Fraktal ist darüberhinaus in gewisser Weise sogar interessant anzuschauen :)
Schau dir mal den Prototypencode auf Seite 2 an. Ist es nicht erstaunlich, daß eine unendlich detaillierte Struktur aus so einfacher Mathematik entstehen kann?
Naja, die Faszination stellt sich natürlich nicht bei jedem ein, nichts für ungut also, wenn du nichts damit anfangen kannst.

[aths]

Wenn man es nicht mal selbst programmiert hat, kann man die Faszination nicht so richtig erahnen.

[Lost Prophet]

mein mathe lehrer hat bezgl brot was von chaosforschung gesprochen

weiß da jemand mehr?

cya axel

[Piffan]

Ich habe mal programmiert. Und zwar meinen Casio FX tralala, der hatte 10 Adressen, bedingte Sprünge und fette 256 Programmschritte :D

Da habe ich vor 20 Jahren vor dem Abi ein Programm gebastelt, welches mir eine komplette Kurvendiskussion durchführte: Ich konnte nacheinander die Variablen eintippen und dann das Ding starten... Nach einiger Zeit spuckte es dann die Nullpunkte, Extremwerte und Wendepunkte aus....

WAr für mich damals enorm befriedigend und verblüffte sogar meinen Mathelehrer, dass der sich erstmal die Idee dazu erklären ließ.... der glaubte mir anfangs nicht...WAr dabei recht schlicht, so mit Riesenschritten die Kurve ablatschen und dann bei Vorzeichenwechsel die Schrittgröße halbiert usw. per Iteration konnte das Teil beliebig genau rechnen... naja, bis zum Überlauf....

Um ein Haar hätte ich E- Technik studiert, also auch mit Mahte mehr zu tun bekommen.....aber wie so oft im Leben kommt alles anders ;)

Dann frohes Gelingen mit dem Brot!

[loewe]

Originally posted by Purple_Stain
mein mathe lehrer hat bezgl brot was von chaosforschung gesprochen

weiß da jemand mehr?

cya axel

"Wo das Chaos auf die Ordnung trifft, gewinnt meist das Chaos,
weil es besser organisiert ist."

Lies doch mal ein bischen im Netz. Ein guter Startpunkt wäre z.b.:

http://www.fraktalwelt.de/

[aths]

*vorsichtig anfrag*

zecki, wann dürfen wir die nächste Version bewundern? Ich nutze dein Programm, da wäre mir eine neue Version mit FSAA gerade recht :)

[zeckensack]

Sorry, aber am Freitag muß ich ein paar Sachen abgeben, und das hat jetzt erstmal Vorrang.
Irgendwann am Freitag abend oder am Samstag nehme ich die Arbeit wieder auf, kein Sorge :)

[aths]

Ich warte jedenfalls schon gespannt :)

[Lost Prophet]

Originally posted by aths
*vorsichtig anfrag*

zecki, wann dürfen wir die nächste Version bewundern? Ich nutze dein Programm, da wäre mir eine neue Version mit FSAA gerade recht :)

ich will dir nicht zu nahe treten, es würde mich aber sehr interesieren, WIE du das NÜTZT, bzw was du damit machst


danke

cya axel

[aths]

Originally posted by Purple_Stain
ich will dir nicht zu nahe treten, es würde mich aber sehr interesieren, WIE du das NÜTZT, bzw was du damit machst Ich lasse es meine CPU quälen :)

Mit Zeckis Programm habe ich in den letzten Tagen Strukturen entdeckt, die für mich völlig neu waren - und ich beschäftige mich mit diesem Fraktal nunmehr seit über 12 Jahren :naughty:

Also, zuerst das Apfelmännchen im Überblick. Dann an eine interessant scheinende Stelle zoomen usw. - Mit der Zeit gewinnt man durchaus etwas Wissen, was einen wo erwartet bzw. wo man suchen muss, damit es sich auch lohnt. Denn es gibt eine gewisse Zahl an "Grund-Strukturen", die allerdings je nach dem, wo man sie sucht, sehr, sehr unterschiedlich aussehen.

Finde ich nun eine Stelle mit mir bislang unbekannten Mustern, suche ich dort z.B. mir bereits bekannte Grund-Strukturen um zu gucken, wie diese nun in dieser "Gegend" genau aussehen.

Mit das wichtigste ist eine gute Farbpalette. Ich habe die DEF.PAL längst durch RAINBOW.PAL ersetzt.

[zeckensack]

*bump*
Ätsch, aths, reingefallen ;D

Naja nicht ganz, ich wollte nur ankündigen, daß es morgen in aller Frühe wieder weitergeht. Mit etwas Glück kriegt ihr mittags schon eine neue Version :)

[Unregistered]

mach mal bisserl schnelelr zeckke
so gehts ja nicht. alle hier im stich zu lassen was bist du denn für einer :D

[Che]

@zeckensack:

Bitte wieder den Sourcecode mithochladen, erstens lerne ich immer gerne dazu und zweitens kann ich ohne meine Screenshotfunktion (->stört euch der Rahmen vom Fenster nicht?) nicht einbasteln...

[aths]

Originally posted by zeckensack
*bump*
Ätsch, aths, reingefallen ;D

Naja nicht ganz, ich wollte nur ankündigen, daß es morgen in aller Frühe wieder weitergeht. Mit etwas Glück kriegt ihr mittags schon eine neue Version :) Last Appleman* standing...

* Begriff wird imo nur auf Webseiten benutzt, die zwar in englisch verfasst sind, aber nicht von einem native speaker.

Formular zur Anmeldung eines Extra-Wunsches:

Ich hätte gerne nach wie vor gerne die Option erst mal in geringerer Auflösung zu rendern. Das geht auch mit Boundary Tracing. Er rechnet erst grob und malt dementsprechend grobe Blöcke, dann rechnet er auf beiden Achsen verfeinert und liest die schon bekannten Werte aus. Somit ließe sich das Generieren des Vorschaubildes ermöglichen, und so ist auch AA drin. Du müsstest "nur" die Ausgabe so anpassen, dass sie sowohl hoch- als auch herunterskalieren kann. (Warum die Hochskalierung nicht auch mit bilinearem Filter?)

Zum AA muss dann auf beiden Achsen die Auflösung verdoppelt werden (für einfaches Herunterskalieren, Vermeidung eines Quincunx-Effekts), während das Bild im Aufbau durchaus "krumm" skaliert sein kann. Wenn das auch auf die Speicherbandbreite geht, Pech gehabt! Ich halte es für wichtig, dass die Auflösung nach und nach verfeinert wird. Und ein Boundary Tracing mit Verfeinerung wäre imo mal was ganz neues, was noch keiner hat.

[zeckensack]

Originally posted by aths
Last Appleman* standing...

* Begriff wird imo nur auf Webseiten benutzt, die zwar in englisch verfasst sind, aber nicht von einem native speaker.Etwas ähnliches habe ich vorgestern auf einer deutschen Seite zum Thema Master Of Orion 3 gelesen. Da hieß es doch tatsächlich, daß das Entwicklerteam, Zitat "rosa Unterhosen" erhalten habe.
*kopfschüttel*
Anmerkung: pink slip ist ein rosa Zettel, den man bekommt wenn man entlassen wird

Formular zur Anmeldung eines Extra-Wunsches:

Ich hätte gerne nach wie vor gerne die Option erst mal in geringerer Auflösung zu rendern. Das geht auch mit Boundary Tracing. Er rechnet erst grob und malt dementsprechend grobe Blöcke, dann rechnet er auf beiden Achsen verfeinert und liest die schon bekannten Werte aus. Somit ließe sich das Generieren des Vorschaubildes ermöglichen, und so ist auch AA drin. Du müsstest "nur" die Ausgabe so anpassen, dass sie sowohl hoch- als auch herunterskalieren kann. (Warum die Hochskalierung nicht auch mit bilinearem Filter?)Skalieren mit Filter wäre nett. Das kollidiert im Moment noch etwas mit meiner 'Gewaltentrennnung' zwischen Berechnung und Anzeige.
*grübel* :|

Zum AA muss dann auf beiden Achsen die Auflösung verdoppelt werden (für einfaches Herunterskalieren, Vermeidung eines Quincunx-Effekts), während das Bild im Aufbau durchaus "krumm" skaliert sein kann. Wenn das auch auf die Speicherbandbreite geht, Pech gehabt! Ich halte es für wichtig, dass die Auflösung nach und nach verfeinert wird. Und ein Boundary Tracing mit Verfeinerung wäre imo mal was ganz neues, was noch keiner hat. Boundary Tracing mit sukzessiver Verfeinerung bringt nichts. Die Stärke des Algos ist, bei einfarbigen Flächen nur den Rand durchzurechnen, und kein einziges Sample mehr.
Wenn man nacheinander das ganze mit schrittweise erhöhter Auflösung neu startet, dann wären alle Durchgänge bis auf den letzten Verschwendung.

Das Preview ist okay, weil es nur sehr wenige Samples benötigt. Das wird auch noch besser werden (Preview mit optimierter Rechtecks-Methode und ab und an Usereingaben).

Was du vorschlägst, würde dazu führen daß das Bild zwar früher ansehnlich wird, aber viel später fertig.
Um zu sehen, ob du das Bild wirklich haben willst, sollte das Preview reichen.

[zeckensack]

Ich bin's wirklich gewesen.

[aths]

Originally posted by zeckensack
Was du vorschlägst, würde dazu führen daß das Bild zwar früher ansehnlich wird, aber viel später fertig.
Um zu sehen, ob du das Bild wirklich haben willst, sollte das Preview reichen. Dass es viel später fertig wird, wage ich im Moment fast zu bezweifeln. Dass es Leistung kostet, und inkauf nimmt, unnötige Samples zu berechnen, liegt auf der Hand, da die Stärke von BT darin liegt, höhere Auflösungen mit weniger Aufwand zu berechnen, als es ein Mehr an Pixeln gibt.

Tatsache ist allerdings auch, dass ich heute noch öfters die alte Blockfill-Version von dir nutze (die du ja mal netterweise auf den neusten Stand gebracht hattest.)

Idee: Eine extra "Render to File"-Funktion. Man speichert das Set in einem Slot, und eine extra Exe, der Filerenderer, kann die Slots wieder laden. Dort sucht man sich die Auflösung* und die AA-Stufe aus, gibt den Dateinamen ein und er rendert das gleich ohne grafische Ausgabe, nur mit Fortschrittsanzeige, in eine Datei. Hier wird je nach AA-Stufe in entsprechender Auflösung reines BT gemacht.

* Edit-Felder für X und Y, sowie eine Combobox mit ein paar vordefinierten Auflösungen, wo eine Auswahl dann die entsprechenden Werte in die Edit-Felder für X und Y bringt. Wenn du kein Bock auf sowas hast, mach es mit Kommandozeile (kann dann ja auch das gleiche EXE-file sein) das Frontend schreibe ich dann :)

Der grafische Zoomer sollte imo einen stufenweisen Aufbau anbieten. (Wobei imo ca. ein Bild-Refresh pro Sekunde ausreichen sollte.)

[zeckensack]

Hnkey (http://home.t-online.de/~zsack/brot.zip)
Antialiasing (zwo drücken für 2x2, eins drücken für nix)
Die Optimierungsstrategie kann jetzt on the fly geändert werden. Ich nenne das intern 'Generator', daher ist G die Taste die es zu drücken gilt.
da war bestimmt noch mehr, aber ich hab's vergessen :|
edit: Aha, genau. Das Preview ist jetzt sowohl optimiert (Rechteck, :P @aths), als auch 'reaktiv'
Die Rechtecksoptimierung arbeitet jetzt wie von aths gewünscht mit 'echten' Rechtecken. Das Preview nicht. Begründung: 'Echte' Rechtecke verzögern das User-Interface, weil sie vergleichsweise spät abbrechen. Beim Preview von schwierigen Bildern nervt das IMO ziemlich.


War 'ne ziemlich fette Architektur-Änderung, ich habe das Fraktal jetzt komplett vom 'Optimierer' getrennt, Ausgabe war ja sowieso schon was eigenes. Darum hat's auch so lange gedauert. Jetzt bin ich aber ganz gut für weiteres gerüstet.

Next up: Paletten laden
Vorwärts und rückwärts-Knöppe (ala Opera-Mausgesten wäre cool)
Places-Exporter/Importer für menschenlesbares und forumtaugliches Format

aths, noch 'ne Frage:
Ist das mit dem Palettenstretch dein Ernst? Das AA erzeugt selbst schon Zwischenstufen. Willst du noch mehr?

[aths]

*big testing*

edit: Ersteindruck: Die neue Preview-Generierung ist eine tolle Sache! Vor allem, dass man schon weiterzoomen kann.

Zweiteindruck: Die Rechteck-Methode ist in der Tat oftmal spürbar langsamer als Boundary-Tracing. Dafür gibts praktisch keine Artefakte. Sehr gut, dass man nun in einer Exe beide Möglichkeiten hat!

[aths]

Originally posted by zeckensack
aths, noch 'ne Frage:
Ist das mit dem Palettenstretch dein Ernst? Das AA erzeugt selbst schon Zwischenstufen. Willst du noch mehr? Ja, voller Ernst. Es gibt bereiche, da hat man einen heftigen Iterations-Anstieg auf engstem Raum.

Neue Wünsche:

- Zeitmess-Funktion. Nach jedem fertigen Bild gibt er auf der Konsole aus, wie lange die Berechnung gedauert hat. (Vergleich der Effizienz, Vergleich mit / ohne AA)

- Tasten 3 und 4 für 3x3 und 4x4 FSAA :)

- Wenns geht: Wahlweises abschalten des Previews, Rendering vor schwarzem Hintergrund (damit man den Aufbau besser verfolgen kann.)

- Unbedingt: Reaktionsmöglichkeit auch dann, wenn er den Rand vom Kern tract.

- Last but not least: Fix doch mal den Zähl-Fehler. Die Farbe der "Schalen" indizierst du um 1 zu hoch.

- Very last but also not least: "R" für "Recalculate".



Btw, hast du da noch irgendwelche Speed-Ups drin? Das Ding kommt mir schneller vor als die früheren Versionen?! - Die Bild-Refreshrate kannst du btw imo beträchtlich senken, falls ich das noch nicht erwähnte :naughy:

Gerade bei Deep Zooms ändert sich pro Refresh kaum was. Du könntest z.B. alle 20 Pixel nachgucken, ob schon eine Sekunde seit dem letzten Refresh um ist. Verlangsamt die Berechnung etwas, imo aber nicht wesentlich.

[aths]

Btw, deine AA-Methode enthält eine Wanze. Das sieht bei mir übermäßig verwaschen aus. Genauer gesagt, vor allem in Y-Richtung. Ein Screenshot und Zoom ergab, dass du auf der Y-Achse tatsächlich blurrst (falsche Subpixel-Positionierung?)

[zeckensack]

Originally posted by aths
Btw, deine AA-Methode enthält eine Wanze. Das sieht bei mir übermäßig verwaschen aus. Genauer gesagt, vor allem in Y-Richtung. Ein Screenshot und Zoom ergab, dass du auf der Y-Achse tatsächlich blurrst (falsche Subpixel-Positionierung?) Nein, das glaube ich nicht. Woran machst du das fest?
Das Supersampling tendiert 'nach oben links', aber es werden keine Samples mehrfach verwertet.

O...
....
....
....

O = Fraktal-Koordinate des Bildschirmpixels
. = Fraktal-Koordinate der Subsamples


Btw, gleich isses wieder so weit ...

[zeckensack]

Murzel-Purzel (http://home.t-online.de/~zsack/brot.zip)
Antialiasing jetzt bis 8x8 OGSS (Zahlen 1-8) :naughty:
Paletten laden mit P
Der Wechsel der Optimierungsmethode ist jetzt angeblich mit M zu machen. Tja, steht so im Readme, aber ich habe irgendwie vergessen, den Code zu ändern ?-)
Ach so, jetzt gibt's ein Readme
'Zählfehler' tatsächlich gefunden und sogleich gefixt
Contour Tracing bricht jetzt ab, wenn's zu schlimm für den Rechner wurde, und nimmt die Arbeit dann später wieder auf. Soll heißen: weniger 'Hänger', User-Eingaben werden schneller berücksichtigt ...
... oder auch nicht. Jetzt bei mir nur noch ~1,5fps statt ~5. Sollte auch noch so gerade reichen.
D knipst das Preview aus, und wieder an. Mir gehen so langsam die Buchstaben aus ...
R setzt die aktuelle Ansicht zurück und startet die Berechnung komplett neu. Wegen der hmmm ... exzessiven Optimierungen war das bisher nicht möglich.
Ist zwar schon ewig drin, ich weiß aber nicht ob ich's schon dokumentiert hatte: mit der Leertaste kann man zurück auf die Startposition gehen


*bäh*, bzw :bäh:

Jetzt mach' ich erstmal Pause ;)

[aths]

Originally posted by zeckensack
Nein, das glaube ich nicht. Woran machst du das fest?Am Screenshot. Aber in der neuen Version ist's gefixt :)

Das mit der Space-Taste hättes du auch mal früher sagen können :naughty:

*Mit dem Testen beginn*

edit: Riesenlob!! Das "Palette laden" wagte ich gar nicht zu fordern, und nun ist es doch drin (Träne aus dem Auge wisch...)

[zeckensack]

Originally posted by aths
Am Screenshot. Aber in der neuen Version ist's gefixt :)Huch!
Dann habe ich das wohl aus Versehen gefixt ;D

Schon komisch, sowas =)

Originally posted by aths
edit: Riesenlob!! Das "Palette laden" wagte ich gar nicht zu fordern, und nun ist es doch drin (Träne aus dem Auge wisch...) Ich HAAAASSSÄÄÄÄ Win32-Programmierung.
Da wird mir immer speiübel.
Lies meine Gedanken:

if ('P'==key)
{
char new_pfile[1024];
new_pfile[0]=0;
OPENFILENAME crap_stuff;
memset(&crap_stuff,0,sizeof(crap_stuff));
crap_stuff.lStructSize=sizeof(crap_stuff);
crap_stuff.lpstrFilter="Palettes\0*.PAL\0All files\0*.*\0";
crap_stuff.lpstrFile=new_pfile;
crap_stuff.nMaxFile=1024;
crap_stuff.lpstrInitialDir=base_path;
crap_stuff.lpstrTitle="Select a new palette, baby";
if (GetOpenFileName(&crap_stuff))
{
output_image->load_palette(new_pfile);
glutPostRedisplay();
}
}

[aths]

Testergebnis: Total geil!

Nee, echt. Dass du z.B. beim Tracing nicht wartest bis der aktuelle Trace abgeschlossen ist (so wie Xaos das tut) ist verdammt nützlich, das AA natürlich sehr gut (Xaos beherrscht es nicht, während Boundary Tracing mit AA den Bildschirm anzuzeigen, und ist auf 2x2 limitiert.)

[aths]

Ein Bild:
http://www.aths.net/files/mb01.jpg

Das ganze mit Anti-Aliasing: Die Strukturen sind viel "weiter" zu erkennen. Die Effizienz ist drastisch gestiegen, so dass der Rechenaufwand nicht mit der internen Auflösung mit ansteigt, sondern geringer.
http://www.aths.net/files/mb02.jpg

Genau das gleiche Bild, aber mit anderer Palette. Nun scheinen nicht mehr die "Schlangen" ("Bärentatzen") als das dominierende Muster, sondern eher Korallenartige Strukturen.
http://www.aths.net/files/mb03.jpg

[aths]

zs,

wenn ich das Fenster minimiere, wird die Berechnung gestoppt? (Die CPU-Last bleibt, aber irgendwie kommt die Berechnung nicht mehr so recht voran.)

[zeckensack]

Originally posted by aths
zs,

wenn ich das Fenster minimiere, wird die Berechnung gestoppt? (Die CPU-Last bleibt, aber irgendwie kommt die Berechnung nicht mehr so recht voran.) Japp.
Bestätigt :|

[zeckensack]

Fix (http://home.t-online.de/~zsack/brot.zip)
Jetzt geht's wieder
Umschaltung der Optimierungsmethode jetzt mit M, statt mit G (jetzt stimmt also auch was im readme steht)
Bugfix: Speicherleck beim Wechsel von contour tracing zu box matching gestopft (falscher Destruktor 'dank' ADTs)
Bugfix: Beim Wechsel auf box matching bei ausgeschaltetem Preview bleibt dieses jetzt auch aus
Ein bisschen reproduzierbarere Schritte beim Iterationstiefen-Fummeln mit W/S (die Feinabstimmung)
Copy constructor/assignment operator für ein paar Sachen eingebastelt -> demnächst vorwärts/rückwärts

Btw,
ist dir mal aufgefallen, wieviel Zeit das Preview in hohen AA-Stufen frißt?
Das hat mit Rechenpower nichts mehr zu tun, nur noch mit dusseligem 'dicke Punkte malen' :naughty:

[aths]

Sleepless in 3DCenter Forum...

Originally posted by zeckensack
Japp.
Bestätigt :| Wie geht das? (CPU-Leistung verballern, aber nix berechnen...?)
Originally posted by zeckensack
Btw,
ist dir mal aufgefallen, wieviel Zeit das Preview in hohen AA-Stufen frißt?
Das hat mit Rechenpower nichts mehr zu tun, nur noch mit dusseligem 'dicke Punkte malen' :naughty: Hm, ist doch klar, dass AA mächtig an der Power nuckelt, oder? Bei 8x8 AA muss er ja effektiv ein sehr, sehr viel größeres Preview berechnen (oder täuscht das?) Jedenfalls finde ich 3x3 AA richtig klasse :) (Ich lass ihn gerade schuften, um 3x3 mit 8x8 AA zu vergleichen =))

Wunschzettel:

Kurztasten (jaja) für einige Auflösungen (clientheight und width des Fensters), z.B

150x150 ("Kleines Vorschau-Bild")
300x300 ("Vorschau-Bild")
600x600 ("ZS-Size™ Original")
1024x768 ("Hintergrund-Bild")
...

Welche Tasten? z.B. Alt und F1-F10 :P :)

[david]

Hallo,

ich würde gern wissen was meine Hercules 4500 macht, wenn ich das aktuelle Bild mit 8x8 AA glätten lasse?

Imho, ist der Kyrochip doch dazu gar nicht in der Lage und beschränkt sich auf FSAA mit 2x2.

Die Kanten werden 'irgendwie' geglättet, das kann ich erkennen :)


david. // gefährliches Halbwissen?

[Ganon]

Originally posted by david
Hallo,

ich würde gern wissen was meine Hercules 4500 macht, wenn ich das aktuelle Bild mit 8x8 AA glätten lasse?

Imho, ist der Kyrochip doch dazu gar nicht in der Lage und beschränkt sich auf FSAA mit 2x2.

Die Kanten werden 'irgendwie' geglättet, das kann ich erkennen :)


david. // gefährliches Halbwissen?

Die Grafikkarte hat damit nix zu tun, soweit ich weiß! Das macht alles der Prozessor!

[zeckensack]

Originally posted by aths
Sleepless in 3DCenter Forum...

Wie geht das? (CPU-Leistung verballern, aber nix berechnen...?)Hängt mit der UI-Architektur zusammen.
Ich hatte irgendwie in einem kurzzeitigen Anfall von Genialität die Berechnung des Fraktals in die Display-Funktion verlegt. Das ist die Funktion, die das Fenster neumalt (kennt man eventuell von Delphi-Forms oder von der MFC als OnPaint).
In der Zwischenzeit sorgte die Idle-Funktion (die aufgerufen wird, solange das Programm nix zu tun hat) dafür, immer wieder ein Neuzeichnen des Bildes zu veranlassen, sonst machte sie nichts mehr.
Sobald das Bild fertig ist, wird die Idle-Funktion selbstverständlich ausgehängt, sodaß nur noch der Fenstermanager das Bild neuzeichnen kann (wenn's vorher von anderen Fenstern verdeckt war oä).
Der doofe Fehler war, daß GLUT die Fenster-Mal-Funktion nicht aufruft, solange das Fenster vollständig verdeckt oder minimiert ist. Das kann man so oft anfordern wie man will, es passiert einfach nicht. Eigentlich ist das eine gute Idee, der Fehler lag also bei mir. Die CPU-Last entstand btw durch das ewige Kreisen in der Idle-Funktion.

Jetzt wird die Berechnung des Fraktals in der Idle-Funktion selbst vorangetrieben, und die Anzeige-Funktion macht nur noch das, wofür sie gedacht ist: den Fensterinhalt darstellen.

Hm, ist doch klar, dass AA mächtig an der Power nuckelt, oder?Jopp. Nur ist das Preview bei hohen Auflösungen/AA-Stufen so extrem bandbreitenhungrig, daß Usereingaben sehr stark verzögert werden. Das bisherige Kriterium zur vorübergehenden Rückgabe ans Interface zur Bearbeitung von Input basiert auf der verbratenen Rechenleistung für's Fraktal. Das funktioniert während der Vollbild-Berechnung auch zufriedenstellend, weil dort die Fraktal-Berechnung in 99% der Fälle der limitierende Faktor ist, auch bei sehr hohen Auflösungen. Das Preview verhält sich zumindest bei geringeren Iterationstiefen ( < 1000) anders, weil zB bei 8x8 AA pro berechnetem Sample >5kiB Speichertraffic anfallen :naughty:
Plus Overdraw, der beim Preview auch erheblich ist.

Bei 8x8 AA muss er ja effektiv ein sehr, sehr viel größeres Preview berechnen (oder täuscht das?) Jedenfalls finde ich 3x3 AA richtig klasse :) (Ich lass ihn gerade schuften, um 3x3 mit 8x8 AA zu vergleichen =))Ich finde auch, daß 3x3 der beste Kompromiß ist. Die Qualität ist bereits sehr hoch.

Wunschzettel:

Kurztasten (jaja) für einige Auflösungen (clientheight und width des Fensters), z.B

150x150 ("Kleines Vorschau-Bild")
300x300 ("Vorschau-Bild")
600x600 ("ZS-Size™ Original")
1024x768 ("Hintergrund-Bild")
...

Welche Tasten? z.B. Alt und F1-F10 Contra: nicht intuitiv, weil F-Tasten für gespeicherte Position dienen sollen.
Pro: viel mehr Knöppe gibt's kaum ;)

Erstmal soll aber die 'History' funzen, dann sehen wir weiter.

[zeckensack]

Originally posted by david
Hallo,

ich würde gern wissen was meine Hercules 4500 macht, wenn ich das aktuelle Bild mit 8x8 AA glätten lasse?

Imho, ist der Kyrochip doch dazu gar nicht in der Lage und beschränkt sich auf FSAA mit 2x2.

Die Kanten werden 'irgendwie' geglättet, das kann ich erkennen :)


david. // gefährliches Halbwissen? Ganon hat Recht, das ist reines Software-Rendering.
Auch das Runterskalieren beim AA erfolgt rein in Software. Aber gut zu wissen, daß es auch auf der Kyro funzt :)

Btw, Downsampling in Hardware würde bei 1024x768 mit 8xAA 150MB Graka-Speicher benötigen (1024x768*64 Samples*3 Bytes für R/G/B). Das wäre der IMO eindeutig falsche Weg ;)

Beim Downsampling in Software brauche ich 'nur' 50MB für das intern hochaufgelöste Bild (nur ein Byte pro Sample) + 2,3MB für die Ausgabe (1024*768*3 Bytes). Nur diese 2,3MB müssen dabei auf die Graka passen (Framebuffer).

[aths]

Originally posted by zeckensack
Das Preview verhält sich zumindest bei geringeren Iterationstiefen ( < 1000) anders, weil zB bei 8x8 AA pro berechnetem Sample >5kiB Speichertraffic anfallen :naughty:Ich hab DDR-RAM @153 MHz und 512 Kb L2-Cache - das ficht mich ergo nicht an :)

Wie baust du eigentlich das Bild auf? Jedes mal (bei jedem Refresh) komplett neu?

[aths]

Das musste ja so kommen! Gnarf!
Ich bin sicher, du hast von Anfang an geahnt, dass ich danach fragen würde.

Ich bin sicher, du schaffst es auch.

Gamma-Korrektes Downfiltering!!

Yeah, Baby

J0ar! Man stellt mit den Cursor-Tasten Gamma hoch/runter (Standard ist 1.0, klar) und dem entsprechend filterst du dann. Natürlich bitte mit 16-Bit-Integer-Präzision.

Das meine ich ernst, um das AA-Bild noch verbessern zu können! Denn mit AA erscheint es im "Gegrissel" dunkler als ohne. Da könnte ich zwar (z.B. mit dem aTuner :naughty: ) Gamma aufreißen, dadurch werden die Farben aber "verwaschen".

(Also nur das Filtering entsprechend gegen-korrigieren, nicht die Palette selbst mit der Gamma-Kurve verzerren)

[zeckensack]

Originally posted by aths
Ich hab DDR-RAM @153 MHz und 512 Kb L2-Cache - das ficht mich ergo nicht an :)

Wie baust du eigentlich das Bild auf? Jedes mal (bei jedem Refresh) komplett neu? Du meinst das Downsampling, gell?
Das passiert in der Tat bei jedem Neuzeichnen des Fensters. Verbesserungswürdig ...

[zeckensack]

Originally posted by aths
Das musste ja so kommen! Gnarf!
Ich bin sicher, du hast von Anfang an geahnt, dass ich danach fragen würde.

Ich bin sicher, du schaffst es auch.Ja, es ging mir durch den Kopf ... Schleimer ;)
Gamma-Korrektes Downfiltering!!

Yeah, Baby

J0ar! Man stellt mit den Cursor-Tasten Gamma hoch/runter (Standard ist 1.0, klar) und dem entsprechend filterst du dann. Natürlich bitte mit 16-Bit-Integer-Präzision.

Das meine ich ernst, um das AA-Bild noch verbessern zu können! Denn mit AA erscheint es im "Gegrissel" dunkler als ohne. Da könnte ich zwar (z.B. mit dem aTuner :naughty: ) Gamma aufreißen, dadurch werden die Farben aber "verwaschen".

(Also nur das Filtering entsprechend gegen-korrigieren, nicht die Palette selbst mit der Gamma-Kurve verzerren) Öööhrm, dann wollen wir doch mal die Theorie ausgraben.

*Tada* nicht-lineares Blending *Tada*

Man appliziere eine Korrekturfunktion k auf jedes Sample, um es in einen linearen Farbraum zu hieven
Man addiere
Jetzt die Umkerfunktion 1/k druff

*hust*

Wie du siehst, ist 'die Palette verzerren' genau der richtige Weg =)
(zumindest ist es der erste Schritt)

[aths]

Ja, es ging mir durch den Kopf ... Schleimer ;)Naja, ich dachte, wenn ich den besten Programmierer frage den das Forum hat, gäbe es da vielleicht Chancen... :)
Wie du siehst, ist 'die Palette verzerren' genau der richtige Weg =)
(zumindest ist es der erste Schritt) Wenn sie wieder zurück gezerrt wird, jo.

[zeckensack]

Wärst du auch mit 10 Bit Gamma-LUT und einer neuen Limitierung auf 5x5 AA einverstanden? :|

edit: MMX hat nämlich einige 'interessante' Limitierungen beim Umgang mit Zahlen >32767. 25 Samples*1023 ist das Maximum, was ich da hineinquetschen kann.

edit2: Ach was erzähle ich denn da ... das Problem ist bereits elegant umschifft :)

[aths]

Ach MMX hin oder her, bei 8x8 AA (also 64 Samples) und Gamma-korrektem Downfiltering denke ich, 16 Bit Präzision ist nicht übertrieben.

Ich weiß nicht, ob ich jetzt Dünnpfiff labere, doch zum Bild-Refresh hätte ich folgende Ideen:

Tiling! Komplette Tiles (z.B. 16x16-Felder "echter" Pixel) werden, wenn sie komplett sind, als "fertig" markiert und extra (= bereits gefiltert) als RGB gespeichert. Wenn eine neue Palette geladen wird, muss natürlich alles noch mal neu downgesampelt werden.

[zeckensack]

Originally posted by aths
Ach MMX hin oder her, bei 8x8 AA (also 64 Samples) und Gamma-korrektem Downfiltering denke ich, 16 Bit Präzision ist nicht übertrieben.Und was hältst du von 32 Bit Fließkomma? :D

Das ergibt erstens die bestmögliche Näherung der (De-)Gammakurve, zweitens ist's schneller, drittens fallen alle Einschränkungen bzgl Zahlenbereich =)
Btw, das Rückrechnen nach der Addition aller Samples und Rundung erfolgt jetzt mit einer 11 Bit LUT, was IMO ausreichend ist.

Ich weiß nicht, ob ich jetzt Dünnpfiff labere, doch zum Bild-Refresh hätte ich folgende Ideen:

Tiling! Komplette Tiles (z.B. 16x16-Felder "echter" Pixel) werden, wenn sie komplett sind, als "fertig" markiert und extra (= bereits gefiltert) als RGB gespeichert. Wenn eine neue Palette geladen wird, muss natürlich alles noch mal neu downgesampelt werden. Auch das noch ...

Im Vollbild mit 8x8AA (ergo 9216*66xx Samples) reicht's noch für gerade so tolerable 2 Refreshes pro Sekunde. Bei vernünftigerem 3x3AA sind's 10. Das ist zwar nicht supi, aber für mein Empfinden gut genug um nicht noch mehr umzuschmeißen.

[Unregistered]

Respekt zeckensack!

ist zwar ot, aber mal eine Frage.
Was machst du wenn du mal gerade nicht am Mandelbrot-Renderer arbeitest?

[aths]

Originally posted by zeckensack
Und was hältst du von 32 Bit Fließkomma? :D Finde ich klasse... wenn ich jetzt noch die Exe haben könnte :D

[zeckensack]

Echse (http://home.t-online.de/~zsack/brot.zip) =)
Gamma-korrigiertes Downsampling. Man drücke 9 und 0 für den Gamma-Wert (liegt so schön neben den anderen, bereits für AA zuständigen Zahlen)
Das Preview ist etwas sparsamer geworden (merkt man erst bei extremen Auflösungen mit AA)
Da aths mir mit seinen Wünschen kaum Ruhe lässt, gibt's sonst nix zu vermelden :D

[zeckensack]

Originally posted by Unregistered
Respekt zeckensack!

ist zwar ot, aber mal eine Frage.
Was machst du wenn du mal gerade nicht am Mandelbrot-Renderer arbeitest? Och, so'n bisschen studieren und sowas :D

[Unregistered]

najo wo und was ;)

[zeckensack]

Bonn. Informatik. Nicht immer ganz erfolgreich ;)

[aths]

Originally posted by zeckensack
Echse (http://home.t-online.de/~zsack/brot.zip) =)
Das rult *knuddel*

Wenn man jetzt noch die Auflösungen hätte, sowie die Möglichkeit, das Bild in eine Datei zu speichern, sowie die Speicherung so erfolgt dass eine extra Datei (mit anderer Endung) mitgespeichert wird, die eine Fortsetzung der Berechnung erlaubt...

Das mit den Auflösungen wäre am besten, wenn man die ebenfalls "locken" kann.

[zeckensack]

Ach so, ja, was ich noch sagen wollte:
Du hattest ja die Pfeiltasten für Gamma-Regelung vorgeschlagen. Die sind schon seit Ewigkeiten für die Navigation nutzbar, und damit bereits belegt gewesen ;)

[aths]

Die Navigation ist aber ziemlich "dumm": Du berechnest jeweils das gesamte Bild neu, und nicht nur den neuen Ausschnitt :naughty: :naughty: :naughty:

Ich wollte noch fragen, wenn ich in 1152x864 im maximierten Fenster rechnen lasse, mit 8x8 FSAA, gamma-korrigiert gefiltert, wieviel % der Rechenleistung verballert er für die Refreshs der Bilder?

[zeckensack]

Viel. Etwa die Hälfte.
Deswegen solltest du das Fenster am einfachsten minimieren, dann schenkt er sich das Runterfiltern nämlich komplett.

[aths]

zecki, ohne schleimen zu wollen, dein Progrämmchen ist weltweit spitze wenn es darum geht, möglichst tief zu zoomen, und liefert nebenbei die absolut besten Bilder (sehr hohe AA-Stufen, gamma-korrektes Downsampling - ich habe schon viele Mandelbrot-Mengen-Ausschnitte gesehen, aber nie in solcher Qualität.)

Um es jetzt noch so richtig sinnig zu machen, müsste es eine Möglichkeit geben, über mehrere Sitzungen verteilt zu rendern. Das ganze sollte mit einer Speicherung des Bildes verbunden werden.

[zeckensack]

*ausderwaschküchezurückkomm*

Ja, das wäre ein sehr wichtiges Feature. Ich habe da im Moment noch ein paar Sorgen mit dem Design, aber ich arbeite bereits daran. Und eine Browser-mäßige History würde ich auch gerne machen.

Ich habe jetzt noch eine Frage wegen den Paletten, die du geliefert hast:
Ich würde das Programm so langsam gerne 'richtig' veröffentlichen, und mir schwebt eine freizügige Lizenz vor. GLUT (mein Windowing-Toolkit) ist offen, meinen Code würde ich verschenken (bzw unter LGPL stellen), aber bei den Paletten weiß ich nicht so recht, ob ich sie überhaupt vertreiben darf :|

Hast du die aus einem Fremdprogramm gemopst, und wenn ja, aus welchem?

[aths]

Eine Veröffentlichung kann ich natürlich nur begrüßen :) mögen möglichst viele in diesen Genuss kommen.
Originally posted by zeckensack
Hast du die aus einem Fremdprogramm gemopst, und wenn ja, aus welchem? Na mal durchschauen:

Def - VGA Default Palette.
Goodega, gray, neon, plasma, royal - alle aus Fractint. Fractint ist Freeware und afaik auch mit Source erhältlich.

Rainbow - Eigenkreation. Jahre alt, übrigens. Gemacht in einem superbilligen Paletten-Editor in einem selbst geschriebenen Power-Basic-Programm, was eigentlich Bitmap-Folgen mit einem Delta-RLE-Algo komprimiert und als "Video" abgespielt hat (war inkl. VESA-Support und nutzte EMS, für die Vesa-Fenster, ohne EMS wurde nur 320x200-Support geboten.)

Die Rainbow.pal würde ich noch mal neu erzeugen, wenns recht ist, um bessere Farbgenauigkeit zu gewährleisten, und dann als in jeder Hinsicht frei verfügbar machen. (Außerdem denke ich daran, statt in Schwarz zu blenden, dafür lieber weiß oder grau zu nehmen, oder was auch immer.)



Hm, du verwendest die Palette um die Innenfarbe zu bestimmen. Das finde ich suboptimal. Ich möchte für den Kern eine exklusive Farbe. edit: Ist offenbar nur halb so kritisch, da du für das Äußere die Innenfarbe nicht verwendest.

[zeckensack]

Jopp. Da war bis zu deinem Einschreiten der Wurm drin, daß er bei Iterationstiefe 1 gleich die dritte Farbe genommen hat. Aber die erste* Farbe war schon immer exklusiv für den Kern reserviert.

*oder in programmiererverständlichen Array-Indizes gesprochen, die nullte

[Ganon]

Wuzel? Linux native? :D;)

Ich hab leider keine Zeit dafür, ich muss was für die Berufsschule proggen!

Hast du Zeit?

[zeckensack]

Ganon,
das Ding ist eigentlich beinahe portabel. GLUT gibt's auch für Linux, und Systemfunktionen fasse ich nicht selbst an.

Problem #1 ist, daß völlig unnötigerweise (reine 2D-Ausgabe) OpenGL benutzt wird. Da könnte man auf SDL umschwenken oder so. Gut, hat mit der Portabilität nix zu tun, aber unter Linux gibt's nicht für alle Karte gute OpenGL-Treiber, bzw sie sind schwieriger zu installieren.

Problem #2 ist die Verwendung von MSVC-spezifischem Inline-Assembler. Eine NASM-Portierung würde helfen (damit habe ich auch schon Erfahrung).

[aths]

Da ist nach wie vor ein Problem:

[zeckensack]

Hmmm, mit 'M' nicht lösbar?
Im Zweifelsfall AA an, oder Auflösung ändern (nicht mal unbedingt erhöhen ...).

[aths]

Originally posted by zeckensack
Hmmm, mit 'M' nicht lösbar?
Im Zweifelsfall AA an, oder Auflösung ändern (nicht mal unbedingt erhöhen ...). Mit M wohl lösbar, ich gucke gerade ob es reicht das Preview abzuschalten.

Jedenfalls sollten solche Fehler imo raus.

edit: Auch ohne Preview, gleiches Problem.

[Ganon]

Originally posted by zeckensack
Ganon,
das Ding ist eigentlich beinahe portabel. GLUT gibt's auch für Linux, und Systemfunktionen fasse ich nicht selbst an.

Problem #1 ist, daß völlig unnötigerweise (reine 2D-Ausgabe) OpenGL benutzt wird. Da könnte man auf SDL umschwenken oder so. Gut, hat mit der Portabilität nix zu tun, aber unter Linux gibt's nicht für alle Karte gute OpenGL-Treiber, bzw sie sind schwieriger zu installieren.

Problem #2 ist die Verwendung von MSVC-spezifischem Inline-Assembler. Eine NASM-Portierung würde helfen (damit habe ich auch schon Erfahrung).

Hmm,

zu Problem #1:
Für Karten die keine OpenGL-Treiber haben, aber wenigstens XFree-Dummys, da sollte doch Mesa reichen oder? Mesa kann doch OpenGL übernehmen, oder? SDL hat auch nicht jeder drauf! Imo kannst du auch bei OpenGL bleiben!

zu Problem #2:

Also mit Assembler kenne ich mich nicht so aus! Sind die so unterschiedlich?!

[zeckensack]

Originally posted by Ganon
Hmm,

zu Problem #1:
Für Karten die keine OpenGL-Treiber haben, aber wenigstens XFree-Dummys, da sollte doch Mesa reichen oder? Mesa kann doch OpenGL übernehmen, oder? SDL hat auch nicht jeder drauf! Imo kannst du auch bei OpenGL bleiben!GLUT hat auch nicht jeder ;)
Und statisch linken kann ich das auch nicht. Irgendwas muß es doch unter Linux geben, womit ich 2D-Grafik ausgeben, und Mausklicks und Tastendrücke entgegennehmen kann. Mir fiel da als erstes SDL ein. Direkt auf X draufproggen will ich nicht (kann ich auch nicht).
Zu Problem #2:

Also mit Assembler kenne ich mich nicht so aus! Sind die so unterschiedlich?! Der Code ist der gleiche, aber GCC frißt die Syntax nicht. Und bevor ich auf die Inline-ASM-Syntax von GCC umstelle (dann wär's mit MSVC nicht mehr kompilierbar :eyes: ), gehe ich lieber auf NASM und erzeuge damit eine Lib. Die NASM-Syntax ist der von MSVC auch sehr ähnlich, was man von GCC nun wirklich nicht behaupten kann.
Das gute: NASM kann aus dem gleichen Code Libs für alle möglichen Linker erzeugen.

Nachteile: gibt's nicht :)

Der restliche C++ Code ist sowieso überall kompilierbar.

[Ganon]

Originally posted by zeckensack
GLUT hat auch nicht jeder
Und statisch linken kann ich das auch nicht. Irgendwas muß es doch unter Linux geben, womit ich 2D-Grafik ausgeben, und Mausklicks und Tastendrücke entgegennehmen kann. Mir fiel da als erstes SDL ein. Direkt auf X draufproggen will ich nicht (kann ich auch nicht).


Wuzel scheint es aber zu können! Könnt ihr euch da nicht zusammenschließen?:)
SDL ist so.....bäh!:D;)

Danke für den kleinen Assembler Kurs!:D;)

edit:

C++ Code? Habe ich da nicht "printf" im Code gesehen? Der macht bei mir unter Linux Probleme wenn ich den mit g++ kompilieren will, oder gibt es eine Compileroption das er C/C++ gemeinsam übersetzen kann?

[zeckensack]

Originally posted by Ganon


Wuzel scheint es aber zu können! Könnt ihr euch da nicht zusammenschließen?:)Wuzel wollte ja ursprünglich ein Win-Frontend bauen. Das darf er auch gerne noch machen, nur irgendwie scheint er's sich anders überlegt zu haben :-(
SDL ist so.....bäh!Win32 ist bäher ;)
Und von X oder gar KDE habe ich null Plan. Villeicht sollte ich mir mal GTK anschauen ???
Ehrlich gesagt ist's mir aber etwas zuviel Aufwand im Moment. Den Assembler-Teil portiere ich gerne, dann kann ich's auch endlich mit MingW für Windows kompilieren :-)

C++ Code? Habe ich da nicht "printf" im Code gesehen? Der macht bei mir unter Linux Probleme wenn ich den mit g++ kompilieren will, oder gibt es eine Compileroption das er C/C++ gemeinsam übersetzen kann? Ööööhm :|
Unter C++ ist die komplette C-Standard library erlaubt. Du bekommst höchstens eine Warnung, aber kompilieren muß er das (GCC3.2 tut's zumindest).

[Ganon]

Originally posted by zeckensack
Wuzel wollte ja ursprünglich ein Win-Frontend bauen. Das darf er auch gerne noch machen, nur irgendwie scheint er's sich anders überlegt zu haben :-(
Win32 ist bäher ;)


WUUUUUUUUUUZZZZZZZZZZEEEEEEEEELLLLLLLL!!!!!!!!!!!!!
:D;)


Ööööhm :|
Unter C++ ist die komplette C-Standard library erlaubt. Du bekommst höchstens eine Warnung, aber kompilieren muß er das (GCC3.2 tut's zumindest).

Mag sein das gcc 3.2 das schon kann (ich hab nur 2.95.3) aber wenn ich C++-Code mit "gcc -I . -c Test.cpp" in eine Objektdatei wandle und dann mit "gcc -o Test Test.o" erstellen will bekomme ich eine fette Liste mit Fehlermeldungen! Es geht nur mit g++! Hat sich das denn jetzt schon geändert?

[wuzel]

Huhu, bin wieder da ;)

Sorry, aber beruflich hats mich grad massiv eingespannt :(
Werde aber noch am GUI baun, hab ja schon eine Teile fertig.

Also heute muss ich noch schaffen wie Sau, morgen oder so kann ich weiterbauen.

Wenn ich die Win 32 Version ferig habe, werde ich eine GTK+ Version bauen -> unter Lin ..
Einziger Knackpunkt, ich muss Zeckensacks ASM code kapieren ...
Denn meinereins kann bloss AT&T ASM unter Unix .. nix Intel ..
Oder jemand anders schreibt das um, ist aber 'nicht ganz so easy' wies ausschaut, da NASM etc. unter Lin der blanke scheiss sind, gcc mag inline eigentlich nur AT&T, alles andere ist murks der sich schlecht kompilieren lässt ...

[Wuzel]

Wahhhh , nich eingelogt :-(

So, jetzt kann ich's ausführlich schreiben (*grummel*):
Ich hab ne Firma am Hals und kann urplötzlich mal ne Woche ausfallen, sorry.
Ich werde jetzt so schnell wie möglich am Win Gui weiterbauen, viel fehlt nicht mehr, eigentlich gabs bloss probleme mit dem verlinken vom Code ... MFC wies leibt und lebt halt ..

Eventuell kann man danach eine Lin/Unix version bauen.
GTK+ ist kein prob, das kann ich sogar besser als Win32 ( was ich eigentlich bloss Hobbymässig betreibe ).
Das einzige Problem ist hier der ASM Part, unter Lin kann man eigentlich bloss AT&T ASM gescheit verwenden, ausser man gibt das Endprodukt nur als binäre version weiter. Denn sonst kriegens die Jungs und Mädels unter Lin nicht kompiliert ( so ohne weiteres ).
Ich persöhnlich kann kaum AT&T für Intel prozies, Sparcs wie Alphas sind meine Welt, nen bissel Power Protz geht auch.
Und das bischen Intel wird für Zeckensacks ASM kaum reichen, deswegen bräuchts hier nen Spezie.

[zeckensack]

Hi, Wuzel :)

NASM ist echt kein Problem. Schau mal was der alles kann:

NASM -f win32 <- erzeugt Module für MSVC/MingW/etc
NASM -f aout <- für diverse Unixe
NASM -f aoutb <- für Net/FreeBSD
NASM -f elf <- Jarharhar
NASM -f as86 <- Linux as86 (dürfte natives GCC-Format sein)
NASM -f coff <- COFF für zB DJGPP und Borland
NASM -f obj <- MSDOS
NASM -f rdf <- 'relocatable data file format 2.0'
NASM -f ieee <- IEEE-965 was auch immer ...
Den Code schreiben tu ich. Kompilieren kann ich's auch, mußt mir nur sagen welches Format der Linker haben will. Kann hier alle genannten Formate direkt aus Win raus erzeugen.

Übrig bleibt ein stinknormales Modul (mit C-Linkage), daß vom dann sauberen C++ benutzt wird. Also Header includen (mach ich auch noch selber), Modul ins Verzeichnis schmeißen, Linker freundlich darauf hinweisen, fertig :)

[aths]

*Anmerk*

Eine Möglichkeit, das aktuelle Projekt während der Berechnung zu speichern, was dann an dieser Stelle eine wiederaufnahme ermöglicht und auch das (soweit) fertige Bild rausschreibt, würde ich echt begrüßen. (Außerdem könnte es eine einstellbare Auto-Speicher-Funktion geben :) Hintergrund - man zieht das Projekt in den Autostart. Alle 10 Minuten speichert er. Wenn der Rechner runtergefahren wird, sind also höchstens 10 Minuten Rechenzeit verschwendet. Beim nächsten Hochfahren rechnet er weiter.)

Übrigens sollte sich das Programm von alleine mit der Priorität "Idle" begnügen. Ich hab irgendwo (Delphi)-Code dafür rumliegen, falls du das brauchst...

[zeckensack]

Bin gerade bei der 16-stufigen History (vorwärts/rückwarts). Das Problem an dem ich gerade arbeite ist der Speicherbedarf.
Das ganze soll nämlich so funktionieren, daß komplette Bilder gespeichert werden
angefangene Bilder weitergerechnet werden, wenn der User diese wieder aufruft (also nix nochmal von vorn)
Die Auflösung/AA-Stufe mit in der History gespeichert, und wiederhergestellt wird

Eine History, die nur die besuchten Fraktalkoordinaten speichert, ist IMO Quatsch as Quatsch can. Eine History, die allerdings komplette Bilder unkomprimiert speichert, würde bei exzessivem AA-Gebrauch (User-Profil: aths :D ) schnell den Rechner zur Explosion bringen.

Ich habe jetzt mit mehreren Kompressionsalgos herumexperimentiert, und nachdem ich gestern abend sogar bzip2 ausprobiert und für ungeeignet befunden habe, bin ich der Lösung jetzt (hoffentlich) recht nah. Delta-RLE bringt's, aber ich habe da irgendwo einen Wurm drin, den ich finden muß ;)

Außerdem steht zu erwarten:
Schnelleres und genaueres Downfiltering (jetzt auf 16 bit Integer mit korrekter Rundung).
Export/Import von Koordinaten im Textformat.
Kompilierbarkeit mit MingW/GCC + NASM.
Wieder ein paar MFLOP/s mehr mit den ExtremeFloats.
Aufnahme von Koordinatensätzen in eine Todo-List, die 'Quasi-Offline' abgearbeitet werden kann.
Speichern fertiger Bilder als TGA (mit AA), oder PCX (ohne AA).

[aths]

Diese "leaks" machen mir das Warten auf die nächst Version schmackhaft :)

Delta-RLE sollte für solche Bilder einen guten Kompromiss aus Geschwindigkeit Komprimierungsrate bieten. LZW dürfte wenig bringen, maximal noch Huffmann-Optimierung, aber das ist vermutlich mehr aufwändiger als es Nutzen bringt.

16 Bit Integer-Präzision sollte beim Downfilgering imo ausreichen, aber wieso wird das nun genauer als deine 32-Bit-Float-Lösung?

Und, ja, selbst Preview-Bilder haben bei mir AA :)

[zeckensack]

Originally posted by aths
Delta-RLE sollte für solche Bilder einen guten Kompromiss aus Geschwindigkeit Komprimierungsrate bieten. LZW dürfte wenig bringen, maximal noch Huffmann-Optimierung, aber das ist vermutlich mehr aufwändiger als es Nutzen bringt.Huffman hintendrauf wäre optimal, aber das will ich mir jetzt nicht unbedingt auch noch antun ;)
Zum Vergleich braucht der jetzige Algo ohne Assembler-Tricks oder sonstiges eine halbe Sekunde für die Kompression eines 8x8AA-Vollbilds. Zip und ähnliches dauert doch erheblich länger, komprimiert aber nicht wirklich besser (oft sogar schlechter). Im Fraktal ist viel zu viel Rauschen drin, als das klassische Kompression viel ausrichten könnte.

16 Bit Integer-Präzision sollte beim Downfilgering imo ausreichen, aber wieso wird das nun genauer als deine 32-Bit-Float-Lösung?Floats sind prinzipiell überlegen, nur meine bisherige Lösung hat sich nicht sonderlich viel Mühe bei der Rundung gegeben.

Und für die Rückrechnung muß sowieso wieder nach Integer gewandelt werden (für's Gamma-Lookup) ;)
Im Prinzip limitiert eher diese Rückwandlung die Präzision, sodaß es sich nicht auszahlt, bei der Akkumulation der Samples mit Floats zu arbeiten. Eigentlich hatte ich das auch nur gemacht, um nicht mit den Einschränkungen im Wertebereich bei Integern kämpfen zu müssen. Das ließ sich aber dann doch erstaunlich leicht lösen :)

[aths]

Originally posted by zeckensack
Huffman hintendrauf wäre optimal, aber das will ich mir jetzt nicht unbedingt auch noch antun ;)
Zum Vergleich braucht der jetzige Algo ohne Assembler-Tricks oder sonstiges eine halbe Sekunde für die Kompression eines 8x8AA-Vollbilds. Komprimierst du das 8-Bit-Bild oder das fertige RGB?

[Wuzel]

Jub,
Also ich hab mal das Problem einkreisen können :
Und zwar ist das was, was mich tierisch 'anko...' und eigentlich laut MS seit VC++ 7 ( .net ) behoben sein müsste.
Wie schon in VC++ 6 mag das MFC Gestrüpp zuviel ANSI C++ überhaupt nicht, diverse MFC sachen 'kolidieren' mit C++ ANSI Funktionen/Klassen.
Tja, wie zu guten VC++ 6 Zeiten muss ich jetzt entweder 'Hüllklassen' ( zu neudeutsch wrapper ) bauen, oder meine Favorisierte Methode, alles in eine DLL schmeissen.

Hmmm, wenigstens hab ich die GDI dazubekommen ( mit ner 'Hüllklasse' ;) ) das 'Bitmap' in einer MFC tauglichen CBitMap ( Geräteunabhängig, 32 bit ) 'reinzupusten'.. . wenigstens was, so lassen sich Dokumente nutzen, sprich saven, konvertieren, printen etc.

Und wenn jemand auf die Idee kommt : machs doch von Hand zu Fuss ohne MFC -> Ich geb nicht auf, Wuzel schlägt zurück, scheiss Imperium :D

[zeckensack]

Originally posted by aths
Komprimierst du das 8-Bit-Bild oder das fertige RGB? 8 Bit natürlich, mehr haben die Paletten ja auch nicht :)
Außerdem soll der User weiterhin die Möglichkeit haben, die Palette zu wechseln.
Der Sinn der Übung ist ja gerade, ein halbfertiges Bild irgendwo platzsparend 'zu parken'. Da werde ich mich hüten, die Original-Information (ergo die Fraktal-Samples) wegzuwerfen.

[zeckensack]

Hi Wuzel :wink:

hast du dir die Bedienung der Klassen (bei mir in main.cpp) schon angesehen? Klappt das soweit?

[Wuzel]

Originally posted by zeckensack
Hi Wuzel :wink:

hast du dir die Bedienung der Klassen (bei mir in main.cpp) schon angesehen? Klappt das soweit?

Das klappt soweit, besser gesagt die Bitmap rausholen ( ohne GLUT , habe ich soweit in GDI umgesetzt ).
Bloss, sobald ich das ganze in mein SDI reinpack, gibts ein Feuerwerk :D
Der Debuger ( schrittablauf ) kommt soweit auch durch ( Bitmap wird generiert, GDI baut Pallete und so drumm rum etc. ), doch sobald das Docu aufbaut -> Bumms.
Laut Referenz kolidiert irgend eine ANSI C++ Funktion mit einem pseudo C++ MFC Gedöns.

Also mein Ziel beseht darin eine Schnitstelle zu konstruieren die wie die Main.cpp ein Mandelbrot Objekt erzeugt, das Bitmap rausholt -> in ein CBitMap kompatibles Format pustet und das eben zurückschiesst ( besser gesagt die Adresse ;) ) ....
Und,der ganze Spass natürlich als 'einsamer Wolf', abgekapselt und gesichert.
Natürlich wird das 'Ding' auch die ganzen Parameter anehmen, um das Mandelbrot zu steuern ( Hier werd ich einen CRect 'umrechner' in Pixel koordinaten schreiben .. um wirklich autark von der Anwendung zu sein ).

Typisch MFC, auf denn ersten Blick total easy, auf denn zweiten ein heiden Spass.
Wenigstens lässt sich das ganze dann total easy threaden, immerhin ein Zuckerli für die Arbeit gratis.

[aths]

Originally posted by zeckensack
8 Bit natürlich, mehr haben die Paletten ja auch nicht :)
Außerdem soll der User weiterhin die Möglichkeit haben, die Palette zu wechseln.
Der Sinn der Übung ist ja gerade, ein halbfertiges Bild irgendwo platzsparend 'zu parken'. Da werde ich mich hüten, die Original-Information (ergo die Fraktal-Samples) wegzuwerfen. Bitte bau mal gleich vor und speicher von vornherein in 16 Bit, damit für die Palette auch größere LUTs möglich sind. Der RLE-Algo müsste dann sinnvollerweise Word-weise arbeiten, um die Effizienz zu erhalten.


Der Berechnungs-Algo sollte imo auch Multithreading supporten, um Dual CPUs oder HTT zu nutzen. (Einfach das Bild in Streifen aufteilen, jeder Streifen kriegt seinen Thread. Ist einer zuende, grabscht sich der Thread den nächsten Streifen. Senkt die Effizenz von Boundary Tracing, sollte - sofern es 2 CPUs gibt - aber letztlich schneller sein.)

Das mit der 16-Bit-Palette-LUT halte ich allerdings erst mal für sinnvoller.

[Kennung Eins]

Es ist total geil, man sagt einfach, was man will, und -egal wie schwierig es scheint- Zecki baut und baut und tattaaa es funktioniert.

Ich krieg meine Kinnlade garnicht mehr hoch, verdammt.

[Lost Prophet]

Originally posted by Kennung Eins
Es ist total geil, man sagt einfach, was man will, und -egal wie schwierig es scheint- Zecki baut und baut und tattaaa es funktioniert.

Ich krieg meine Kinnlade garnicht mehr hoch, verdammt.

DITO

:O :O @ Z-BAG

cya axel

[aths]

Joar, wenn Zecki das mit der History schafft, sowie auf Knopfdruck ein "absaven" der History auf Platte ermöglicht, dann hat er m.E. den weltbesten Mandelbrot-Renderer geschrieben den es jibt. (Und solange die Existens von intelligentem Leben außerhalb unseres Sonnensystems nicht bestätigt ist, sogar den besten im ganzen bekannten Universum!! *raspel, raspel*)

[zeckensack]

Danke für die Blumen :)

Leider wird sich das ganze noch ein paar Tage verzögern. Bin leicht verletzt und kann nicht gut tippen. Ist aber nichts allzu ernstes.

[ethrandil]

sehnenscheidenentzündung? ;)

[zeckensack]

Nein, diesmal nicht :)

'Spochtunfall' ;)

[Lost Prophet]

Originally posted by zeckensack
Nein, diesmal nicht :)

'Spochtunfall' ;)

was für sowas hast du zeit? :D

was wars denn?
auf dem weg vom klo zurück ausgerutscht? :naughty: ;D
scherz beiseite, gute besserung



eine frage zum renderer hätt ich noch:

is da noch mehr freiheit drin??
so in die richtung: mehr funktionstasten, tasten für functionen selber definieren, auflösung selber einstellen

na?


cya axel

[zeckensack]

Möglich wär's. Lohnt sich IMO noch nicht, solange wir auf GLUT rumkrebsen. Das kann nämlich nur ASCII-Keys 'melden'. Ergo kann ich zwar recht leicht ein kleines a und ein großes A als zum gleichen Knopf gehörend erkennen, bei '1' und '!' wird's aber schon schwierig ?-)

[aths]

* aths wartet gespannt auf das neue Release.

[Lokutus01]

wow, das ist RICHTIG fähig. Ich habe vor Ewigkeiten in der Schule mal an so was gespielt. Ich hacke mir jetzt auch den Code in den Kopf... mal schauen, ob ich meine non-Java-Kenntnisse wieder hochbekomme.

In jedem Fall: Weiter so! Eine tolle Funktion wäre eine Art F1-Hilfe, welche alle möglichen Tastenkombinationen zeigt ;-)

Viele Grüße

[aths]

Für Tasten-Kombos gibts die Readme.

Zecki, neue Idee: Speichern der aktuellen Koordinaten in einer Text-Datei, deren Inhalt übers Forum mit Copy&Paste übertragen werden kann.

[Sir Integral Wingate Hellsing]

respekt @ z-bag!

sehr gutes proggy!

feature-frage:

gibt es noch möglichkeiten im rechner weitere rechenkapazität dafür auszunuten....und wenns nur der vertex shader vonner graka (falls überhaupt möglich) is oder ähnliches...

oder könenn z.b CPU extensions weiterhelfen (du sagst du nutzt ja MMX, was ist mit anderen CPU features?)

sorry ist n00b-mässig gefragt, aber vom proggen hab ich nunmal kein plan :sulkoff:

trotzdem: weiter so! :wink:

[peanball]

Originally posted by aths
* aths wartet gespannt auf das neue Release. * [UPS]Erazor auch.

Der beste Brotbäcker, den ich bisher gesehen hab...

keep on codin' ;)

edit: mir ist eine neue Funktion für mein Forum eingefallen :)

'/me' durch den Schreiber-Namen ersetzen...

[aths]

Ähm... Zecki??

[zeckensack]

Hallo! :wink:

Gedulde dich bitte noch einen Tag, oder so :)

[TheRealTentacle]

Hab zwei eher sinnlose Ideen, aber vieleicht hast du mal zuviel Zeit zeckensack :D.

1. ein Fullscreenmode wäre interessant
2. eine Art Screensaver, der selbst interessante Stellen findet (dürfte realisierbar sein)

Sicher keine "you need" Features, aber bei 2. könnte man auch ohne Klickarbeit schöne Bilder sehen, was Apfelmännchenfans sicher begeistern wird.

Übrigens habe ich das Programm in Physik zu der Darstellung im Zusammenhang von Ähnlichkeit und Wahrscheinlichkeit gut gebrauchen können.

Danke, schönes Programm, mach weiter so!

[Lost Prophet]

Originally posted by TheRealTentacle
Hab zwei eher sinnlose Ideen, aber vieleicht hast du mal zuviel Zeit zeckensack :D.

1. ein Fullscreenmode wäre interessant
2. eine Art Screensaver, der selbst interessante Stellen findet (dürfte realisierbar sein)

Sicher keine "you need" Features, aber bei 2. könnte man auch ohne Klickarbeit schöne Bilder sehen, was Apfelmännchenfans sicher begeistern wird.

Übrigens habe ich das Programm in Physik zu der Darstellung im Zusammenhang von Ähnlichkeit und Wahrscheinlichkeit gut gebrauchen können.

Danke, schönes Programm, mach weiter so!


also zu 1:

da drückt man rechts oben auf den "maximierern"-button *eg*

2 macht imho nicht so viel sinn, höchstens eine slideshow aus vorher gespeicherten bildern

cya axel

[zeckensack]

Originally posted by 028
respekt @ z-bag!

sehr gutes proggy!

feature-frage:

gibt es noch möglichkeiten im rechner weitere rechenkapazität dafür auszunuten....und wenns nur der vertex shader vonner graka (falls überhaupt möglich) is oder ähnliches...

oder könenn z.b CPU extensions weiterhelfen (du sagst du nutzt ja MMX, was ist mit anderen CPU features?)

sorry ist n00b-mässig gefragt, aber vom proggen hab ich nunmal kein plan :sulkoff:

trotzdem: weiter so! :wink: Nope, ist reines Software-Rendering. HW-Beschleunigung ist nicht so einfach zu machen.

Das Fraktal könnte man höchstens mit einem Vertex oder Pixel Shader der Version 2.0 oder besser ausrechnen (Shader mit flow control), das wäre dann aber brute force und sehr wahrscheinlich nicht schneller als eine CPU-basierte Lösung mit den entsprechenden Optimierungen. Außerdem ist die Präzision von Grafikhardware viel zu gering für 'meine' Zwecke ;)

[Lost Prophet]

eine frage bezüglich der tastenbelegung lässt mir im moment keine ruhe

also, das is doch mit C geschrieben oder

ich weiß jetzt nicht wie weit man mit C in den Computer eindringen kann, aber wenn man bis zu den Tastatur interupts käme müssten sich doch so die tasten belegen lassen oder bin ich da völlig auf dem holzweg???


cya axel

[zeckensack]

Originally posted by Purple_Stain
... oder bin ich da völlig auf dem holzweg???


cya axel Ja :bäh:

Moderne Betriebssysteme erlauben direkte Hardware-Zugriffe nicht (das ist IMO auch ganz gut so), ergo kann eine 'normale' App da auch nichts machen. Treiber, die aufgrund ihres speziellen Status direkt an die Hardware müssen, kann man natürlich auch in C schreiben - in Java eher nicht.

Ergo: C ist zwar recht maschinennah, daß heißt aber nicht daß man machen darf was man will. Btw nutze ich C++, das ändert aber natürlich nichts an der Aussage ;)

HW-Interrupts werden unter Windows direkt in 'Messages' umgesetzt, das sind Nachrichtenpakete die Applikationen empfangen und verarbeiten ... normalerweise.
Ich habe nämlich durch das gewählte windowing toolkit überhaupt keine Message queue mehr :|
Ergo empfange ich nur die Informationen, auf die das toolkit ausgerichtet ist, und das sind eben nur die nötigsten.

[zeckensack]

edit:Bitte auf einen Bugfix warten!
edit2: Bugfix ist oben, brot.exe muß datiert sein auf heute, 18:16 Uhr. Wenn nicht, dann bitte in ein paar Minuten neu runterladen


Leider fehlt die Hälfte (http://home.t-online.de/~zsack/brot.zip) :(
History. Man drücke X und Y und fühle sich wie in einem INet-Browser (hoffentlich).
Wie angekündigt, Änderung am downfilter (bissi schneller, viel genauer)
Runterrechnen und Anzeige jetzt wirklich nur noch wenn es nötig ist - hoffentlich ...
Endlich! Kompilierbar mit DevCC/MingW + NASM oder MSVC + NASM. Setzt eine NASM-Installation in C:\NASM voraus. Fertige OBJs wollte ich eigentlich gleich dazupacken, ums leichter zu machen (dann braucht ihr NASM nicht), hab's aber wohl vergessen ?-)
edit: jetzt ist der kompilierte Assembler-Kram im Archiv enthalten. .obj für MSVC und .o für MingW.
Und was bringt das, höre ich euch fragen? Erstens Portabilität, und GCC3.2 zieht MSVC6 speedmäßig die Hosen aus, das bringt es. Man vergleiche die Geschwindigkeit der beiden enthaltenen Echsen.
Wechsel der maximalen Iterationstiefe leicht geändert: Q/A für ein wenig hoch/runter, SHIFT+Q/A viel hoch/runter. W/S machen nix mehr.


Tjo, ansonsten leider nichts neues. Kompression fehlt, Speichern/Laden als Text fehlt, Todo-List/Offline-Render fehlt, komfortablere Auflösungswahl fehlt. Ich will das Design dafür erst nochmal gehörig umschmeißen, und die Zeit reichte nicht für mehr :-(

Siehe meinen Thread im Progger-Forum (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=56168), wäre für jede Hilfe dankbar.

Demnächst wird das Projekt in Core-DLL und Frontend-EXE zerblasen, sodaß jeder der lustig ist ein eigenes Frontend bauen kann. Wäre durchaus denkbar daß andere in Sachen UI-Design eure vielen guten Ideen besser realisieren können als ich ;)

[ow]

Also das MSVC-Brot crasht bei mir nach kurzer Zeit.:(
Das andere test ich jetzt mal noch kurz.

/edit: hmm...das andere auch:(

[zeckensack]

Oh Gott :o

Stimmt!

[Unregistered]

bei mir auch
ich denke beim wechsel auf die extremefloats passiert das :)

Kommt ein speicherfehler..
irgendwas ned gelöscht?? ;)

[mh01]

Bei mir kachelt die Kiste kurz nach dem Wechsel auf den Rectangle-Mode ab (BSoD!!!). Contour-Tracing tut problemlos, auch bis x.xxxe-24 und tiefer rein. Scheint also nicht an den Extreme-Floats (geile Bezeichnung für einen Datentyp, solltest Du schützen lassen ;)) zu liegen.

[zeckensack]

Originally posted by Unregistered
bei mir auch
ich denke beim wechsel auf die extremefloats passiert das :)

Kommt ein speicherfehler..
irgendwas ned gelöscht?? ;) Beim Erreichen der maximalen History-Tiefe:
Doppelt gelöscht :(

Fix ist raus, siehe oben.
Die Echse muß 18:16 Uhr als Änderungszeit haben (MSVC-Version 18:13).

[Wuzel]

Originally posted by zeckensack

Demnächst wird das Projekt in Core-DLL und Frontend-EXE zerblasen, sodaß jeder der lustig ist ein eigenes Frontend bauen kann. Wäre durchaus denkbar daß andere in Sachen UI-Design eure vielen guten Ideen besser realisieren können als ich ;)

Genau so eine 'Core DLL' würde einiges lösen ;)
Ich wurschtel grad mit MFC 7 rum und guck das ich was gebastelt krieg, aber die 'anti ANSI C++' Haltung von dem Teil ist mehr als derb.
Witzig : bau ich die Schnitstellen im 'managed' Code, scheints zu laufen .... naja aber wer will sich schon zum 'mandeln' das Net Framework auf die Kiste nudeln .... zumal es 'kriecht' wie Sau und irgendwo mal 'Schiff geht unter' spielt, reset Ahoi.

Zur Zeit Umschiff ich das ganze, hab meinen Intel Compi angeschmissen und nen COM+ Interface drangezwiebelt
, Problem : Der ASM Code wird nicht gefressen :(
Hmmm, NASM kann doch so lsutige bib's zwiebeln .. gibts da auch was für Intel Compis ???

Tjaja ...

[ow]

öhm, während des Berechnes drängtz sich die AUsgaeb immer in den Vordergrund, ich tip hier fats blind

[ow]

wie man sieht:D

hier noch ein screenie davon:

[mh01]

Originally posted by mh01
Bei mir kachelt die Kiste kurz nach dem Wechsel auf den Rectangle-Mode ab (BSoD!!!). Contour-Tracing tut problemlos, auch bis x.xxxe-24 und tiefer rein. Scheint also nicht an den Extreme-Floats (geile Bezeichnung für einen Datentyp, solltest Du schützen lassen ;)) zu liegen.

Same procedure as last version...

Contour tut, Rectangle stirbt :(

Alle Versionen vor den heutigen kannten dieses Problem nicht, was läuft falsch???

[zeckensack]

@Wuzel:
NASM (http://sourceforge.net/projects/nasm).

Der Assembler-Code ist im MSVC-Projekt eingebunden mit einer Custom-Build-Option. Einstellen kannst du das, wenn du dir die Eigenschaften von xfloat.asm und downfilter.asm anschaust. Im Moment ist's so geregelt, daß der ASM-Code automatisch mitkompiliert wird, wenn man das Projekt baut, setzt aber eine NASM-Installation (üpp (http://prdownloads.sourceforge.net/nasm/nasm-0.98.35-win32.zip?download)) in C:\NASM\ voraus. Wenn du an den Einstellungen spielst, geht's auch ohne, denn die fertigen Kompilate sind seit dem Bugfix gerade eben im Archiv mit drin.

[zeckensack]

Originally posted by mh01


Same procedure as last version...

Contour tut, Rectangle stirbt :(

Alle Versionen vor den heutigen kannten dieses Problem nicht, was läuft falsch??? Die Version gerade war definitiv faul. Mit der neuen gelingt's mir aber nicht mehr, einen Absturz zu provozieren???

Hilf mir mal bitte ... sag mir was ich in welcher Reihenfolge machen muß, damit er absemmelt :)
Auflösung ändern?
Am AA spielen?
F-Tasten drücken?
Navigation über Tastatur?
Navigation über Maus?
History wann, wie benutzen?

Ich krieg's im Moment nicht kaputt???

[[EF]peppa]

Eine Kleinigkeit noch. OGL sollte immer das primary device verwenden. Macht wohl bei den Meisten nicht so dolle Probleme aber bei mir schon. Ich hab naemlich keinen OGL-Treiber fuer das zweite und dritte device installiert und das Programm crasht beim Start. Je nachdem auf welchen Monitor Windows das Fenster aufbauen will. :)

EDIT: Ist glaub ich doch was anderes, also nicht ogl sondern glut. Screenshots folgen.

EDIT2:

http://elreyforce.org/~peppa/brot_scrshot1.png

Bei msvc kommt das selbe wie oben nur nach einen Klick auf OK schmeisst sich der msvc-debugger dazwischen:
http://elreyforce.org/~peppa/brot_scrshot2.png

[ow]

Hi zecki:)

Bin ich der einzige mit og. Problem???

/edit: hmm....könnte sein, bei 8Bit Desktop funzt es. Fauler NV Treiber?:D

[zeckensack]

Originally posted by ow
Hi zecki:)

Bin ich der einzige mit og. Problem?

/edit: hmm....könnte sein, bei 8Bit Desktop funzt es. Fauler NV Treiber?:D

Huch???
Sorry, hatte das Ende der letzten Seite übersehen ?-)

Hattest du das schonmal? Am Display-Code hat sich nämlich nix geändert, bis auf die Tatsache daß er jetzt noch seltener aufgerufen wird.
Bei mir läuft die Kombination Opera 6.05/Brötchen/Catalyst 3.1 ganz normal :|

[zeckensack]

Originally posted by [EF]peppa
Eine Kleinigkeit noch. OGL sollte immer das primary device verwenden. Macht wohl bei den Meisten nicht so dolle Probleme aber bei mir schon. Ich hab naemlich keinen OGL-Treiber fuer das zweite und dritte device installiert und das Programm crasht beim Start. Je nachdem auf welchen Monitor Windows das Fenster aufbauen will. :)

EDIT: Ist glaub ich doch was anderes, also nicht ogl sondern glut. Screenshots folgen.Sorry, ich kann leider nicht steuern, auf welchem Monitor das Ausgabefenster erzeugt wird. Habe gerade mal geschaut, die aktuellste GLUT-Version ist von 2000, aktualisiert wird da nichts mehr.

Ein Fall für die Frontend-Front ;)

[ow]

Originally posted by zeckensack
Huch???
Sorry, hatte das Ende der letzten Seite übersehen ?-)

Hattest du das schonmal? Am Display-Code hat sich nämlich nix geändert, bis auf die Tatsache daß er jetzt noch seltener aufgerufen wird.
Bei mir läuft die Kombination Opera 6.05/Brötchen/Catalyst 3.1 ganz normal :|


Entwarnung.:)

War der NV Treiber. Irgendwas hat den wohl zuvor aus der Fassung gebracht.:|
Nach einem Reboot alles ok, vorher waren alle Brote faul (auch die älteren).

[Xmas]

LOL, ich hab das ganze mal mit Optimierungen mit VC.net kompiliert. Der Unterschied zur VC6-Version ist nahe Null. Die GCC-Version ist teilweise doppelt so schnell.

Und falls jemand sich beim Neukompilieren wundert dass das Fenster immer schwarz bleibt... Paletten nicht vergessen ;)

[ow]

Frage: wie ermittelt man da welche Geschwindigkeit???

[zeckensack]

Originally posted by ow
Frage: wie ermittelt man da welche Geschwindigkeit??? Man sucht sich ein Preset aus, das etwas länger dauert (zB F12 wäre so ein Kandidat) und/oder aktiviert AA. Fenster maximieren nicht vergessen ;)

Dann braucht man noch eine Uhr im Zimmer, die deutlich hörbar tickt ... :D

[ow]

Originally posted by zeckensack


Dann braucht man noch eine Uhr im Zimmer, die deutlich hörbar tickt ... :D

Achso;D
Jetzt weiss ich was mir da fehlt.:D

Kannste da nicht schnell was reinbasteln, was die Zeit zu Start und Ende einer Berechnung protokolliert:;)

[zeckensack]

Ah, Moment!
Ein neuer Satz Presets, diesmal hoffentlich etwas geschmackvoller als bei den letzten Malen :)
Ich empfehle rainbow.pal oder neon.pal für den besten Effekt ;)

[[EF]peppa]

Wieso ist nicht rainbow.pal oder neon.pal schon Standard???

[zeckensack]

Das ist eine guuute Frage
*nick*
;)

[turboschlumpf]

weil es eben rainbow und neon,
nicht standard ist
;D

[mh01]

Originally posted by zeckensack
Die Version gerade war definitiv faul. Mit der neuen gelingt's mir aber nicht mehr, einen Absturz zu provozieren???

Hilf mir mal bitte ... sag mir was ich in welcher Reihenfolge machen muß, damit er absemmelt :)
Auflösung ändern?
Am AA spielen?
F-Tasten drücken?
Navigation über Tastatur?
Navigation über Maus?
History wann, wie benutzen?

Ich krieg's im Moment nicht kaputt???

Ich habe das F7-Preset genommen, die Iterationstiefe zuerst auf 2 runtergefahren, dann hoch auf 1024 und habe reingezoomt. Mit Contour-Tracing würde ich wahrscheinlich jetzt noch zoomen, ohne das es zu einem Absturz gekommen wäre. Wenn ich das gleiche aber mit dem Rectangle-Verfahren gemacht habe, hat er angefangen, Rechtecke zu malen und bevor er einmal von oben nach unten durch war - BSoD...

[Lost Prophet]

8 std rechenzeit für den popo

ich lass meinen comop seit 3 uhr rechnen schau regelmäßig rein wie weit's is so auch jetzt nur diesmal wars ein doppeklick in der taskleiste = fenster hat sich verkleinert = neu angefangen zu rechnen

ARGH!!!!111

cya axel

[ethrandil]

nun mal los jungens: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=56280 :D
*schon gespannt sei*

[Wuzel]

Originally posted by Xmas
LOL, ich hab das ganze mal mit Optimierungen mit VC.net kompiliert. Der Unterschied zur VC6-Version ist nahe Null. Die GCC-Version ist teilweise doppelt so schnell.

Und falls jemand sich beim Neukompilieren wundert dass das Fenster immer schwarz bleibt... Paletten nicht vergessen ;)

VC 7 ist gegenüber VC6 auf 'neueren' Systemen so knappe 2% schneller, auf 'älteren' deutlich langsamer ( ohne MFC, die neue MFC ist so oder so nen weng schneller .. ).

Der Intel Compi ist beiden ( dreien mit GCC ;)) in Sachen Speed meilenweit überlegen ... echt grasss des vieh ..

Naja ich werd mal in aller Ruhe mein NASM probi angehen ( iss aber anscheinend nicht alzuwild ;) ), wenn dann der Intel den Schlonz durchhaut hab ich gewonnen -> Juppii.
Schon doof das der MS Compi bei sowas versagt :...(

Von wegen 'kann jetzt 'olla very special' ANSI C++ und rult alles wech' da glaub ich lieber an den :santa:

EDIT : Wo fin ich die neuste 'Mandel' ? Ich blick hier nicht mehr durch -> need link

[zeckensack]

Originally posted by mh01


Ich habe das F7-Preset genommen, die Iterationstiefe zuerst auf 2 runtergefahren, dann hoch auf 1024 und habe reingezoomt. Mit Contour-Tracing würde ich wahrscheinlich jetzt noch zoomen, ohne das es zu einem Absturz gekommen wäre. Wenn ich das gleiche aber mit dem Rectangle-Verfahren gemacht habe, hat er angefangen, Rechtecke zu malen und bevor er einmal von oben nach unten durch war - BSoD... Hmmm ... nein, hier nicht :|

Welches Modul tötet sich dabei? (steht ja im BSOD)

Ich sehe du hast 'ne Kyro. Es liegt mir fern, hier mangelnde Treiber-Quali zu unterstellen, weil das Brötchen wirklich so gut wie nix vom Treiber fordert. Aber können andere Kyro-Besitzer das vielleicht bestätigen? Dann hätte ich einen Anhaltspunkt.

Was für eine Desktop-Farbtiefe fährst du? War das Fenster maximiert, und wenn ja, welche Desktop-Auflösung?

Haben andere ohne Kyro auch dieses Problem?

Fragen über Fragen ...

[mh01]

Originally posted by zeckensack
Hmmm ... nein, hier nicht :|

Welches Modul tötet sich dabei? (steht ja im BSOD)

Ich sehe du hast 'ne Kyro. Es liegt mir fern, hier mangelnde Treiber-Quali zu unterstellen, weil das Brötchen wirklich so gut wie nix vom Treiber fordert. Aber können andere Kyro-Besitzer das vielleicht bestätigen? Dann hätte ich einen Anhaltspunkt.

Was für eine Desktop-Farbtiefe fährst du? War das Fenster maximiert, und wenn ja, welche Desktop-Auflösung?

Haben andere ohne Kyro auch dieses Problem?

Fragen über Fragen ...

Hoffentlich hilfreiche Antworten:

Desktop-Farbtiefe: 32 Bit
Desktop-Auflösung: 1600x1200
Fenstergröße: dein Standard
Treiber: Hercules-Treiber V 16.55 (Freigabedatum 22.08.2002)

Den Drang zum Suizid (auf unehrenhafte Art und Weise;)) entwickelt immer wieder die win32k.sys...

Und wie bereits erwähnt, tritt das Problem erst mit den neuen Versionen auf. Alle bisherigen liefen ohne Probleme und tun dies noch immer.

[zeckensack]

Originally posted by Wuzel
EDIT : Wo fin ich die neuste 'Mandel' ? Ich blick hier nicht mehr durch -> need link Hier (http://home.t-online.de/~zsack/brot.zip), gleicher Link wie immer :)

[aths]

Originally posted by zeckensack
Wechsel der maximalen Iterationstiefe leicht geändert: Q/A für ein wenig hoch/runter, SHIFT+Q/A viel hoch/runter. W/S machen nix mehr.Hm. Ich fände es andersrum besser: Q/A für Faktor 2, und Shift dann fürs Feintuning.

Ansonsten: Die Rechteck-Methode mit Preview und Anti-Aliasing ergibt einen sehr netten Bildaufbau-Effekt.

Die History möchte ich bitte absaven können, mit Bildauflösung, und Bildinhalt! Bitte bitte bitte! (Einfach eine Taste für einen SaveAs-Dialog...)

Ebenso möchte ich Einzel-Bilder abspeichern. Bitte als BMP oder was auch immer erzeugen, inkl. Datei (mit anderer Endung) welche die Koordinaten und anderen Einstellungen erhält. Diese Datei sollte natürlich auch wieder ladbar sein. Das mit den Presets ist eine nette Sache für sich, zum Weitergeben macht sich das aber nicht sonderlich toll. Diese Datei sollte imo auch die Palette integriert habe (kein Verweis auf die Pal-Datei, sondern richtig die Palette.)

Dabei wäre darauf zu achten, dass du "Platzhalter" berücksichtigst, für spätere Dinge wie Color Cycling, also z.B. den Offset in der Palette abspeicherst.

Diese Datei die die Koordinaten+Palette enthält, sollte imo rein im ASCII-Format geschrieben werden (=Weitergabe mit Copy&Paste möglich.) Die Palette müsste also mit BASE64 oder wie auch immer in Buchstaben umgewandelt werden.

[zeckensack]

Originally posted by mh01


Hoffentlich hilfreiche Antworten:

Desktop-Farbtiefe: 32 Bit
Desktop-Auflösung: 1600x1200
Fenstergröße: dein Standard
Treiber: Hercules-Treiber V 16.55 (Freigabedatum 22.08.2002)

Den Drang zum Suizid (auf unehrenhafte Art und Weise;)) entwickelt immer wieder die win32k.sys...

Und wie bereits erwähnt, tritt das Problem erst mit den neuen Versionen auf. Alle bisherigen liefen ohne Probleme und tun dies noch immer. Das sieht nicht gut aus :(
So als vorletzter Strohhalm: tritt das Problem auch auf, wenn du Brot_msvc.exe benutzt?

[zeckensack]

Originally posted by aths
Hm. Ich fände es andersrum besser: Q/A für Faktor 2, und Shift dann fürs Feintuning.Ja, da hast du wohl Recht. Ich werd's beim nächsten Release entsprechend ändern.
Die History möchte ich bitte absaven können, mit Bildauflösung, und Bildinhalt! Bitte bitte bitte! (Einfach eine Taste für einen SaveAs-Dialog...)Ich weiß doch selbst, daß das muß, aber noch fehlt. Hab's so schnell leider nicht hinbekommen :-(

Ebenso möchte ich Einzel-Bilder abspeichern. Bitte als BMP oder was auch immer erzeugenJau, PCX und TGA sind in Planung, aber ...
, inkl. Datei (mit anderer Endung) welche die Koordinaten und anderen Einstellungen erhält. Diese Datei sollte natürlich auch wieder ladbar sein.Wie jetzt? Also getrennt geht das, Bild speichern oder Parameter speichern, das wäre klar. Mir leuchtet nur nicht ein, wie diese beiden Dinge sinnvoll wieder zusammen ladbar sein sollen. Entweder ich speichere den internen Arbeitsfortschritt (so wie in der history), dieser ist dann aber kein 'normal' benutzbares Bildchen. Oder ich speichere die rohen Parameter, und die bis dahin geleistete Berechnung ist verloren.
Man könnte jetzt natürlich hingehen und alles speichern, ein .TGA, und den Arbeitsfortschritt inkl Parameter. Das wäre dann aber doppelt gemoppelt. Für den Fall daß die Rechnung noch nicht abgeschlossen ist, ist das TGA nicht zu gebrauchen. Wenn die Rechnung fertig ist, dann braucht's den Arbeitsfortschritt nicht mehr.

Wenn nur ein Parametersatz gespeichert wird, dann isses auch gut und sicher nützlich zum Austausch. Nur wie soll das später (beim Laden) wieder zusammenkommen?
Ich hatte eigentlich gehofft, solche Entscheidungen dem User überlassen zu können. Nach dem Motto: Bilder lädt man in der Bildverarbeitung, und das Brötchen beschäftigt sich ausschließlich mit sich selbst.
Aus eingeladenem TGA+Parametersatz kann halt IMO nicht sinnvoll weitergearbeitet werden. Soll das TGA angezeigt werden (->langweilig), oder sollen die Parameter beachtet werden (->TGA für die Tonne)? Was gewinnt???

Zum restlichen:
Ich versteh' das schon :)
Ich bin mir nur nicht sicher, ob der Export in eine Textdatei überhaupt erstrebenswert ist. Eine simple Dialog-Box mit Copy&Paste-Support würde sehr einfachen Austausch über Foren und Email ermöglichen, ohne daß der User erst noch Notepad anschmeißen muß.

Das mit den direkt dazugespeicherten Paletten finde ich widerum gut.

[aths]

Das war so gemeint: Das fertige Bild zum speichern, um es z.B. als Hintergrund oder was auch immer zu verwenden. Die Daten (Koordinaten etc) dazu speichern, falls man später noch Ausschnittsvergrößerungen laden möchte. Lädt man die Koordinaten, fängt er an, von neuem zu rechnen, und das Bild dazu kann höchstens in Bildverarbeitungsprogrammen weiter verwendet werden, nicht mehr im Mandelbrot-Renderer.

[Wuzel]

Originally posted by zeckensack
Hier (http://home.t-online.de/~zsack/brot.zip), gleicher Link wie immer :)

Danke ;)

Meine Fresse hat sich da viel getan :O

Der Code sieht um 180 % anders aus, als der, der auf meiner Platte rumschwirt ....

Die Sache hat sich für mich ja mehr als vereinfacht ... hmm der ganze Stress wohl umsonst :-(

Naja, nicht so voreilig sein, ich bau mal auf dem neuen Code, mal kucken wies tut ... ( sieht aber deutlich positiver aus )

[peanball]

Originally posted by zeckensack
Ich bin mir nur nicht sicher, ob der Export in eine Textdatei überhaupt erstrebenswert ist. Eine simple Dialog-Box mit Copy&Paste-Support würde sehr einfachen Austausch über Foren und Email ermöglichen, ohne daß der User erst noch Notepad anschmeißen muß.

Das mit den direkt dazugespeicherten Paletten finde ich widerum gut.
Ich hab gerade eine noch viel krassere Idee...
Wie wäre es, wenn du dir eine Art von URL-Prefix ausdenkst...
Ich denke da an ed2k:// oder ftp://, die ja mit bestimmten Programmen verknüpft werden können.
Wenn du dann brot://koordinate1:koordinate2:iterationstiefe[:Palette] über einen Link im Browser aufrufst (kann man ja sogar im Forum verlinken) dann öffnet sich das Brot und rendert den angegebenen Ausschnitt. Ein Export einer gefundenen Stelle über eine Textbox wäre da natürlich auch noch sinnvoll...
Das mit der Dialogbox zum reinpasten finde ich natürlich auch toll.
Zu den Dateien: Es sollte mehrere Brot-Dateitypen geben: Zum einen einfach die Datei mit Koordinaten (äquivalent zum Link) und eine mit Fortschrittsdaten zum später weiterrendern.
Zur Navigation: Kannst du die Alt-Taste abfangen mit deinem Toolkit? Wenn ja, mach doch bitte für vor Alt+Rechts und zurück Alt+Links.
Dann können die Leute mit den 5-Tasten Mäusen die Seitentasten wie im Browser benutzen... Das wäre wirklich noch die Krönung ;)

am Mitte März fange ich an zu studieren und kriege da erstmal C++ reingeprügelt. Ma kuckn, vielleicht kann ich mich dann mal aktiv beteiligen, wär cool.

[ethrandil]

ich würde dann noch gerne ein Feature anmelden:
Man sollte ein prewiew bekommen, dann mit der Maus quasi einen Rahmen aufziehen, und dieser bereich wird dann genau gerendert.
Wenn man zB noch am heranzoomen ist, dann braucht man manchmel nur einen kleinen Bereich um das schwarze zu treffen :)

danke (kannst es ja an Wuzel den GUIler abschieben ;))

[aths]

Originally posted by ethrandil
ich würde dann noch gerne ein Feature anmelden:
Man sollte ein prewiew bekommen, dann mit der Maus quasi einen Rahmen aufziehen, und dieser bereich wird dann genau gerendert.Das finde ich blöd, wegen des Seitenverhältnisses. Imo sollte der Zoomfaktor aber durchaus schon regelbar sein.

[ethrandil]

nenene das soll nicht auf das Fenster skaliert werden!
Das soll dann nur in der Vorschau gerechnet werden! Er kann den 'Rest' ja weiterrechnen. Man kann also quasi sagen rechne diesen Abschnitt fertig (er interessiert mich besonders) dann mach den Rest weiter.

[aths]

Originally posted by ethrandil
nenene das soll nicht auf das Fenster skaliert werden!
Das soll dann nur in der Vorschau gerechnet werden! Er kann den 'Rest' ja weiterrechnen. Man kann also quasi sagen rechne diesen Abschnitt fertig (er interessiert mich besonders) dann mach den Rest weiter. Ach so. Da hätte ich eine einfachere Idee anzubieten: Per Tastendruck schaltet er auf eine Art "Center first" Modus. Das gesamte Bild wird ins Preview einbezogen, doch die eigenliche Berechnung findet zunächst nur in der Mitte statt. (Mitte = mittleres Drittel von beiden Achsen.) So sieht man schneller ob es sich lohnt, noch weiter zu zoomen.

[aths]

Ach ja, zecki, wenn der Mandelbrot-Renderer fertig ist, glaub nicht dass das alles war! Da stünde noch ein Realtime Julia-Evolver an. Wie das das ganze funktionieren soll (habe da eine konkrete Vorstellung) sag ich aber noch nicht :) damit du dir nicht gleicht die Haare raufst und rufst "Ja und wann soll ich studieren, meine Herren?!"

[zeckensack]

Originally posted by aths
Ach ja, zecki, wenn der Mandelbrot-Renderer fertig ist, glaub nicht dass das alles war! Da stünde noch ein Realtime Julia-Evolver an. Wie das das ganze funktionieren soll (habe da eine konkrete Vorstellung) sag ich aber noch nicht :) damit du dir nicht gleicht die Haare raufst und rufst "Ja und wann soll ich studieren, meine Herren?!"
Die Frage im Moment lautet wohl eher "Ja und wann soll ich den nächsten Artikel für die PCGH fertigbekommen?" ;)

Ein Julia-Set habe ich irgendwann übrigens schonmal testhalber gerendert. Das klappt soweit und verträgt sich auch gut mit den beiden Optimierungsstrategien. Aber die Navigation funktioniert in Julia-Sets halt etwas anders, und deswegen habe ich das aufgeschoben.
______________________


Ich ... habe ... eine ... DLL :naughty:

Was halten die GUI-Menschen von folgendem Interface:


enum bc_generator_type_enum {contour_tracing=0, box_matching, brute_force, max_generator_enumerant=brute_force };

#ifdef BROT_CORE_EXPORTS
#define BROT_CORE_API __declspec(dllexport)
#else
#define BROT_CORE_API __declspec(dllimport)
#endif

#define BROT_CALL

extern "C"
{
BROT_CORE_API void BROT_CALL bc_reset();
BROT_CORE_API void BROT_CALL bc_clean();
BROT_CORE_API void BROT_CALL bc_set_image_properties(int x_res,int y_res,int aa_level,float aa_gamma);
BROT_CORE_API void BROT_CALL bc_set_palette(const ubyte* const palette);
BROT_CORE_API void BROT_CALL bc_set_generator_type(bc_generator_type_enum type);
BROT_CORE_API void BROT_CALL bc_preview_control(bool enable);

BROT_CORE_API int BROT_CALL bc_get_maximum_iterations();
BROT_CORE_API int BROT_CALL bc_get_image_width();
BROT_CORE_API int BROT_CALL bc_get_image_height();
BROT_CORE_API const char* const BROT_CALL bc_describe_generator();
BROT_CORE_API float BROT_CALL bc_get_cleverness();

BROT_CORE_API bool BROT_CALL bc_refine_image();
BROT_CORE_API const ubyte* BROT_CALL bc_get_rgb_image();

BROT_CORE_API void BROT_CALL bc_zoom_on_window_coord(int x,int y,float factor);
BROT_CORE_API void BROT_CALL bc_zoom_centered(float factor);
BROT_CORE_API void BROT_CALL bc_move(float delta_x,float delta_y);
BROT_CORE_API void BROT_CALL bc_reset_current_view();

BROT_CORE_API void BROT_CALL bc_adjust_maximum_iterations(float factor);
}

Offensichtlich noch abwesend ist ein direktes Setzen und Abfragen von Parametern. Mir schweben drei Methoden vor:
'raw data', also via void*, um ExtremeFloats zu schleudern. Die Client-App wird davon nichts wissen, sie verwaltet nur den benötigten Speicher
Text. Import und Export der ExtremeFloats in C-Strings. Ließe sich als Text speichern und wäre geeignet für Copy&Paste-Betrieb
'Normale' Fließkomma-Zahlen (doubles). Nicht direkt zum Arbeiten geeignet, aber vielleicht zur Anzeige.

Die History ist übrigens intern vorhanden und arbeitet korrekt. Die Entry-Punkte kommen RSN ;)

Davon abgesehen kapselt die DLL soviel wie möglich von der Applikation ab. Ist also dann doch eher OOP, aber mit C-Bindings. Das ganze ist momentan leider noch nicht reentrant, bzw nur Single-Threading fähig (bedeutet ja das gleiche). Das ließe sich lösen durch COM-artiges Erzeugen eines Interfaces, das bei den Kernfunktionen jeweils dereferenziert werden muß.

Ich bin offen für gute Vorschläge, wie das in reinem C elegant lösbar ist. Grund: C-Bindings lassen sich einfach und konsistent in einer Vielzahl anderer Programmiersprachen nutzen, und machen allgemein die wenigsten Probleme wenn man verschiedene Compiler mischt (zB GCC3.2 für den Core und MSVC für's Frontend). Ich will definitiv keine Klassen aus der DLL exportieren.

Ansonsten sollte der Header recht einleuchtend sein. Wenn eine Funktion unklar ist, dann bitte ruhig schonmal fragen, 'richtige' API-Doku folgt später.


@mh01,
Ich habe jetzt doch noch einen Bug im Box Matching gefunden, den ich wahrscheinlich erst kürzlich 'vor lauter Cleverness' neu eingebaut habe :)

[mh01]

Originally posted by zeckensack

...
@mh01,
Ich habe jetzt doch noch einen Bug im Box Matching gefunden, den ich wahrscheinlich erst kürzlich 'vor lauter Cleverness' neu eingebaut habe :)

Insektenvernichter frei, anlegen, zielen, FEUER!

Nieder mit den Wanzen ;)

Ernsthaft: ich kann's kaum erwarten...

MfG


Marc

[aths]

Originally posted by zeckensack

Die Frage im Moment lautet wohl eher "Ja und wann soll ich den nächsten Artikel für die PCGH fertigbekommen?" ;)

Ein Julia-Set habe ich irgendwann übrigens schonmal testhalber gerendert. Das klappt soweit und verträgt sich auch gut mit den beiden Optimierungsstrategien. Aber die Navigation funktioniert in Julia-Sets halt etwas anders, und deswegen habe ich das aufgeschoben.Navigieren, nun gut, das möchte der eine oder andere vielleicht auch. Was ich möchte ist, mit der Maus übers Mandelbrot zu fahren, und in Echtzeit die passende Julia-Menge angezeigt zu bekommen! (Also im Bereich -2 .. 2)

Zooms in Julia-Mengen sind deutlich langweiliger als Zooms in Mandelbrot-Mengen. Xoas schaltet vom Mandelbrot auf einen entsprechenden Julia-Ausschnitt um, vielleicht solltest du beide Optionen anbieten: Volle Ansicht und Ausschnitts-Ansicht.

[GloomY]

Originally posted by zeckensack
Hmmm ... nein, hier nicht :|

Welches Modul tötet sich dabei? (steht ja im BSOD)

Ich sehe du hast 'ne Kyro. Es liegt mir fern, hier mangelnde Treiber-Quali zu unterstellen, weil das Brötchen wirklich so gut wie nix vom Treiber fordert. Aber können andere Kyro-Besitzer das vielleicht bestätigen? Dann hätte ich einen Anhaltspunkt.

Was für eine Desktop-Farbtiefe fährst du? War das Fenster maximiert, und wenn ja, welche Desktop-Auflösung?

Haben andere ohne Kyro auch dieses Problem?

Fragen über Fragen ... Bei mir funktioniert's ohne Probleme. Einstellungen wie unten bis auf Auflösung (1152x864), und Treiber Version (16er PowerVR), dürften aber eh die gleichen sein, bis auf das Hercules Logo ;)
Originally posted by mh01
Hoffentlich hilfreiche Antworten:

Desktop-Farbtiefe: 32 Bit
Desktop-Auflösung: 1600x1200
Fenstergröße: dein Standard
Treiber: Hercules-Treiber V 16.55 (Freigabedatum 22.08.2002)

Den Drang zum Suizid (auf unehrenhafte Art und Weise;)) entwickelt immer wieder die win32k.sys...

Und wie bereits erwähnt, tritt das Problem erst mit den neuen Versionen auf. Alle bisherigen liefen ohne Probleme und tun dies noch immer.

edit: welche .exe ist jetzt eigentlich die "bessere"? Ich hab' nicht den ganzen Thread mitverfolgt...

[zeckensack]

Originally posted by GloomY
edit: welche .exe ist jetzt eigentlich die "bessere"? Ich hab' nicht den ganzen Thread mitverfolgt... Die normale brot.exe war die IMO bessere, weil deutlich schneller. Erzeugt wurde das ganze mit dem exakt identischen Quellcode, aber einmal mit GCC3.2 (schnell), und nochmal mit MSVC6 SP5 (ca halb so schnell ;)).

Der Bug, den mh01 beschrieben hat war in beiden drin, und ziemlich obskur. Trotzdem fast schon komisch daß sonst niemand betroffen war :|

[zeckensack]

Ja und wann soll ich meinen nächsten Artikel für die PCGH fertigbekommen? (http://home.t-online.de/~zsack/brot.zip) ;)
mh01' Bug (hoffentlich) erlegt
History-Schritte 'merken' sich jetzt die Auflösung/AA-Stufe
Nur so zum Spaß ist jetzt auch ein klassischer 'brute force'-Generator verfügbar :naughty:
edit: Fortschrittsanzeige! Leider nur Unsinn, wenn der box matching-Generator zum Einsatz kommt, da muß ich mir noch was überlegen.
noch'n edit: Änderungen der Iterationstiefe (Q/A) erfolgen jetzt (wie von aths vorgeschlagen) tüchtig ohne SHIFT, und ein klitzeklein wenig mit SHIFT
Sonst nix :bäh:
... halt: Trennung Core/Applikation. Der Kern ist jetzt eine DLL (btw wieder ein GCC-Kompilat) mit einer hoffentlich für die GUI-Front verständlichen API. Habe mir Mühe gegeben :)
Funktioniert so:
Alle Funktionen der DLL haben das Präfix bc_
Die Client-Applikation muß einen 'Kontext' erzeugen. Die meisten Funktionen der DLL erfordern einen solchen als ersten Parameter. Dadurch könnte eine Applikation - wenn sie es denn wollte - mehrere Histories in mehreren Fenstern gleichzeitig fahren. Die Kontexte sind selbstredend völlig voneinander getrennt. Multithreading ahoi.
Die DLL kann alles (und noch ein bisserl mehr), was die alte standalone-App konnte.
Ausgabe, Parametersetzen und Parametermodifikation (ie zoomen, verschieben) obliegen der Applikation. Dabei wird die App bewußt 'dumm' gehalten.
Die DLL kann jetzt Koordinatensätze im Textformat ausspucken und wieder entgegennehmen. Eingabefelder, Copy&Paste ahoi.
Die DLL wurde unter großem Aufwand so gut es ging 'abschußsicher' designt. Initialisierung und so Zeuchs ist absolut optional. Es gibt keine verpflichtenden Rituale bei der Benutzung, irgendwas sinnvolles sollte jeder einzelne Funktionsaufruf tun.
Hoffentlich kann ich nun ein paar exotischere Wünsche auf andere abwälzen. Die API ist in brot_core_interface.h definiert. Dort stehen auch ein paar Kommentare drin, ist aber noch nicht vollständig. Einfach fragen :)
Außerdem findet sich im mitgelieferten Client auch quasi Beispiel-Code. Ich hoffe das ist nicht zu umständlich geschrieben.

[mh01]

Hallo, die Welt ist schön, dumdidumdiduuuuu.... :D

Das Brot funzt jetzt, ohne meinen Rechner zu töten.

Eine Frage hätte ich dann aber doch noch: Warum werden die Koordinaten und der Radius nicht mehr angezeigt, wenn ich rein- oder rauszoome, bzw. ein Preset lade?

Herr Zeckensack, äussern Sie sich dazu und schwören Sie, die Wahrheit zu sagen, die reine Wahrheit und nichts als die Wahrheit, sowahr Ihnen das Brot schmecke.

[ethrandil]

wäre ja schön, wenn man das auf knopfdruck anzeigen lassen könnte ... dachte so an 'C' und schon sieht man die koordinaten zum Copy&Pasten in der Konsole *g*

[zeckensack]

Die Wahrheit hilft mir des öfteren, ich habe sie hier in meiner Schublade, und hole sie bei Bedarf hervor :bäh:

Ist unterwegs verloren gegangen :D
Macht aber nichts, dann zimmer ich's halt wieder hinein. Wie versprochen ist die Funktionalität (ätsch@nggalai) in der DLL enthalten, man (bzw ich) muß sie nur nutzen.

[zeckensack]

Originally posted by ethrandil
wäre ja schön, wenn man das auf knopfdruck anzeigen lassen könnte ... dachte so an 'C' und schon sieht man die koordinaten zum Copy&Pasten in der Konsole *g* Drück mal V :naughty:

Das ist ein Dingens, was ich eigentlich für's Release rausnehmen wollte, aber nu ... ?-)

[mh01]

Ähm, Herr Bäckermeister, ich hätte da mal gerne ein Problem!

Wie gesagt, der Rechner stürzt jetzt nicht mehr ab, ABER:

Wenn er gerade so schön am Rechnen ist, eröffnet er nach einiger Zeit ein Brötchen-Bombardement auf meine IE-Fenster. Diese gehen dann natürlich in Deckung, also zu (bis jetzt nur bei Contour Tracing beobachtet)!!!

Das kommt mir schon etwas seltsam vor, hat da etwa ein Entwickler eine No-IE-Mode implementiert;)
Ein Schelm, wer da böses denkt...

[zeckensack]

Werter mh01, du bist mir ein Rätsel :D

edit: die heilige Inquisition will informiert werden:
Wieviel Antialiasing benutzt du?
Und wahrscheinlich auch noch im Vollbild, gell? :D
Wie groß ist dein Swap-File?


Kleines Zahlenspiel:
3x3AA @ 1600x1200 macht lustige 320MB im Vollausbau (16 Bilderchen in der History)

[mh01]

Komisch, andere behaupten das auch immer über mich:|

[mh01]

AA off, Deine Standard-Fenstergröße, Swap-File darf WinXP zwischen 256 MB und 1 GB selbst hin und her schieben. Das Preview ist ausgeschaltet.

Übrigens hat dein Programm sogar eine akustische Benachrichtigung, wenn es fertig mit Rechnen ist - meine Lüfter laufen dann wieder leiser:D


Edit1: Räschdchraypunk
Edit2: Preview-Info ergänzt

[ethrandil]

Originally posted by zeckensack
Drück mal V :naughty:

Das ist ein Dingens, was ich eigentlich für's Release rausnehmen wollte, aber nu ... ?-)
Cool, danke :)
Aber was soll 'Oyoyoy!' bedeuten ?? *g*

[Kennung Eins]

Zecki, vielleicht kannst du diese Kurzform deiner readme.txt mit übernehmen, das find ich übersichtlicher / nützlicher.
Kannst ja auch unter der Taste "h" ein "Hilfefenster" öffnen lassen, wo dies dann angezeigt wird (i.e. einfach nur die readme.txt auslesen und anzeigen)Navigation
==========
Left-Click -> Zoom in
Right-Click -> Zoom out

directional keys -> navigation
PGUP/PGDOWN -> Zoom in/out

SPACE -> returns to the origin

Zoom Factor
===========
Q -> increase maximum iteration depth
SHIFT+Q -> increase maximum iteration depth by smaller steps
A -> decrease maximum iteration depth
SHIFT+A -> decrease maximum iteration depth by smaller steps

Save/restore locations
======================
F1 - F12 -> switch to preset places
CTRL + function key -> save current location

Antialiasing
============
1 -> 1x1 (AA = off)
2 -> 2x2 OGSS AA
3 -> 3x3 OGSS AA
4 -> 4x4 OGSS AA
5 -> 5x5 OGSS AA
6 -> 6x6 OGSS AA
7 -> 7x7 OGSS AA
8 -> 8x8 OGSS AA

9 -> lower downfiltering gamma
0 -> raise downfiltering gamma

History
=======
Y -> previous view
X -> next view

Palettes
========
DEF.PAL is the default palette
P -> load different palette

Optimizations
=============
M -> toggle between box matching and contour tracing

More stuff
==========
D -> toggle preview on/off (on = default)
R -> restart current view
L -> toggle mouse lock

[zeckensack]

Tja, KennungEins, ich bin eben ein Schwaller :D

Juppdidu (http://home.t-online.de/~zsack/brot.zip)
Save as TGA. S drücken =)
Background processing. Soll heißen, daß nachdem das gerade aktuelle Bild fertig ist, alle bisher unfertigen in der History gespeicherten Ansichten durchgerattert werden. Das kann man auch abschalten, und zwar mit B.
Fehlende API-Funktion nachgerüstet:
bc_set_view_params_from_doubles ... peinlich peinlich ...
Neue API-Funktion:
bc_refine_history => siehe oben, background processing
Parameter werden wieder automatisch angezeigt
Uups, fast vergessen:
Jetzt 'echtes' Timing. Es wird pro Funktionsaufruf nicht mehr eine konstante Zahl Iterationen berechnet, sondern eine (beinahe) konstante Zeit verbraten. Sollte zu besserer Bedienbarkeit auf kleinen Systemen, und weniger Leistungsverschwendung durch übermäßige Fenster-Updates auf großen Systemen führen :)

[aths]

"Ersteindruck: Sehr gut"

Du hast sogar jetzt eine Fortschrittsanzeige drin! Mein Flehen wurde erhört :) Leider funzt die ausgerechnet bei "M" nicht :( (Nur 0 - 50 - 100%)

Hihi: Neue Idee: "Film" aufnehmen. Der Vergrößerungsfaktor wird niedriger gestellt, und er speichert alles in eine Datei, welche nach Abschluss der "Aufnahme" komprimiert wird (Delta RLE, u.U. Huffman-Optimiert.)

Das würde natürlich noch immer sehr groß, deshalb wäre es vielleicht empfehlenswert, mit Verlusten zu komprimieren. Erstidee: DXT1. (Gaaanz besonders ausgefuchst wäre natürlich FXT1, um je nach Kachel einen optimalen Algo zu finden. DXT1 sollte aber auch schon vernünftig zupacken.)

Zur "Aufnahme" eines Filmes könnte es alternativ noch eine andere Möglichkeit geben. Bei einem gegebenen Ausschnitt sagt man: "Zoome hier rein!" und er fängt dann an, von der Gesamt-Übersicht bis zu diesem Ausschnitt stückweise zu zoomen, speichert jedes Einzelbild (verlustfrei komprimiert) und haut das am Ende in ein mit verlusten komprimiertes "Video"-File.

Falls du das mit den Filmen schafft, sehe ich mich genötigt, dir einen Orden zu verleihen.

[PhoenixFG]

Wenn man manchen Leute mal den kleinen Finger gibt, reißen die einem gleich den ganzen Arm ab.:D

MfG

[aths]

zs, gaaanz wichtig: Ich möchte die History auf 1 oder 2 Bilder begrenzen können - sonst nehmen die Speicheranforderungen überhand (du weißt ja, wie sehr ich FSAA mag.)

Außerdem möchte ich, dass beim Beenden die History gesavt und beim nächsten Start geladen wird.

Und ich möchte noch Paletten-Shifting ("Color Cycling"), also die Palettenindizes verschieben können.

Und das alles bis morgen, wenns geht.

[ethrandil]

zecki war so unglaublich raffiniert, dass er jetzt einfach sagen kann: Frag Wuzel!
*ggg* tja, so spielt das leben :bäh:

[Lost Prophet]

editiert: wie blöd kann man sein?? (ich) :bonk:

noch eine frage

berechnest du den fortschritt nach dem tatsächlichen rechenfortschritt, dh wie lang es tatsächlich noch braucht


oder

nur wie weit der fortschritt des BILDES ist?

cya axel

[zeckensack]

Originally posted by aths
"Ersteindruck: Sehr gut"

Du hast sogar jetzt eine Fortschrittsanzeige drin! Mein Flehen wurde erhört :) Leider funzt die ausgerechnet bei "M" nicht :( (Nur 0 - 50 - 100%)Ja, das hatte ich oben auch extra erwähnt. Mir ist bis jetzt kein simpler Ansatz dafür eingefallen ...
Brute force ist klar. Dort wird die aktuelle Zeile abgegriffen. Zeile 'durch' Höhe ist der Fortschritt.
Tracing startet auch 'von oben'. Der Anfang einer Kontur hat immer eine y-Koordinate. Die nehme ich dann.
Beim box matching ist's schwierig, weil der Arbeitsstack wächst und schrumpft. Es ist garnicht so einfach abzuschätzen wie weit das schon ist.
Hihi: Neue Idee: "Film" aufnehmen. Der Vergrößerungsfaktor wird niedriger gestellt, und er speichert alles in eine Datei, welche nach Abschluss der "Aufnahme" komprimiert wird (Delta RLE, u.U. Huffman-Optimiert.)Aha :|
Das würde natürlich noch immer sehr groß, deshalb wäre es vielleicht empfehlenswert, mit Verlusten zu komprimieren. Erstidee: DXT1. (Gaaanz besonders ausgefuchst wäre natürlich FXT1, um je nach Kachel einen optimalen Algo zu finden. DXT1 sollte aber auch schon vernünftig zupacken.)An schneller DXT1-Kompression bin ich schon vor vier Jahren gescheitert :|
Zur "Aufnahme" eines Filmes könnte es alternativ noch eine andere Möglichkeit geben. Bei einem gegebenen Ausschnitt sagt man: "Zoome hier rein!" und er fängt dann an, von der Gesamt-Übersicht bis zu diesem Ausschnitt stückweise zu zoomen, speichert jedes Einzelbild (verlustfrei komprimiert) und haut das am Ende in ein mit verlusten komprimiertes "Video"-File.

Falls du das mit den Filmen schafft, sehe ich mich genötigt, dir einen Orden zu verleihen. Aha :|

[zeckensack]

Originally posted by PhoenixFG
Wenn man manchen Leute mal den kleinen Finger gibt, reißen die einem gleich den ganzen Arm ab.:D

MfG Das habe ich auch gerade gedacht :D

[zeckensack]

Originally posted by aths
zs, gaaanz wichtig: Ich möchte die History auf 1 oder 2 Bilder begrenzen können - sonst nehmen die Speicheranforderungen überhand (du weißt ja, wie sehr ich FSAA mag.)Ich hatte mir das etwas 'sauberer' überlegt:
Beim Erzeugen eines Kontexts wird der DLL mitgeteilt, wieviel Speicher sie maximal für diesen Kontext verbraten darf. Wieviele Bilder letztendlich vorgehalten werden, liegt dann nur noch an der Größe und Komprimierbarkeit der Bilder.

Apropos Komprimierbarkeit: Kompression ist im Moment noch nicht aktiv. Der bisherige Algo (der im Source bereits enthalten ist, aber brachliegt) macht mich auch immer noch nicht richtig froh. Denn er komprimiert 'dumm' das ganze Bild, obwohl es ausreichend wäre, nur die 'echten' Samples zu berücksichtigen. Aus diesen kann der entsprechende Generator mit sehr geringem Rechenaufwand (ie NULL Fraktal-Iterationen) das Ausgangsbild bereits vollständig rekonstruieren. Dann wäre die Kompression aber wieder abhängig vom gewählten Generator. Ohne zu sehr ins Detail zu gehen, das sind recht unschöne 'Issues'.

Außerdem möchte ich, dass beim Beenden die History gesavt und beim nächsten Start geladen wird.Setze deine Prioritäten, Grashüpfer =)
Jedenfalls habe ich exakt das schon lange im Hinterkopf, aber die Architektur drumherum muß erst stimmen.
Und ich möchte noch Paletten-Shifting ("Color Cycling"), also die Palettenindizes verschieben können.Wäre eine Aufgabe des Clients. Ist machbar, und wenn ich's selbst tun muß :)
Und das alles bis morgen, wenns geht. Sicher :|

Hast du mal versucht, einen Delphi-Client zu schreiben? Mich würde interessieren, was funktioniert, und auf welche Hindernisse man da stößt.

[zeckensack]

Originally posted by ethrandil
zecki war so unglaublich raffiniert, dass er jetzt einfach sagen kann: Frag Wuzel!
*ggg* tja, so spielt das leben :bäh: Tja, es darf jeder der mag, einen Client schreiben. Dafür habe ich diese Trennung doch gemacht :bäh:

[zeckensack]

Originally posted by Purple_Stain
editiert: wie blöd kann man sein?? (ich) :bonk:

noch eine frage

berechnest du den fortschritt nach dem tatsächlichen rechenfortschritt, dh wie lang es tatsächlich noch braucht


oder

nur wie weit der fortschritt des BILDES ist?

cya axel
Offensichtlich letzteres :)

[aths]

zecki, ich weiß leider nicht, wie man in Delphi DLLs nutzt. Was ich in Delphi allerdings schon mal geschafft habe ist, einen Texturkomprimierungcodecalgo zu schreiben, der pro Kachel aus 4 (eigentlich 5) Möglichkeiten auswählt, und sogar die Einstellung einer Mindestkomprimierungsrate supportet :naughty:

Ich guck mal, ob ich das Teil noch finde (das nützt dir zwar nix, stachelt aber vielleicht deinen Ehrgeiz an :))

[x-dragon]

Originally posted by aths
zecki, ich weiß leider nicht, wie man in Delphi DLLs nutzt. ... Man erstellt eine Unit in seinem Projekt wo dann das da reinkommt:

unit brot;

interface

function bc_preview_control : boolean; stdcall; external 'brot_core.dll';
//function ...
//.
//.
//.

implementation

end. wobei ich selbst nicht ganz durchblicke, was für Datentypen für Ein- bzw Ausgabe verwendet werden, bei der DLL.
Aber vom Aufbau her sollte das so passen :).

Die Unit funzt dann als Schnittstelle zwischen Delphi-Prog und DLL und man kann die DLL-Prozeduren einfach über die Unit aufrufen.

[Lost Prophet]

Originally posted by ethrandil
ich würde dann noch gerne ein Feature anmelden:
Man sollte ein prewiew bekommen, dann mit der Maus quasi einen Rahmen aufziehen, und dieser bereich wird dann genau gerendert.
Wenn man zB noch am heranzoomen ist, dann braucht man manchmel nur einen kleinen Bereich um das schwarze zu treffen :)

danke (kannst es ja an Wuzel den GUIler abschieben ;))

genau

folgende situation:

man zoomt irgenwo hinein, und man will aber eine bestimmte stelle haben und nicht auf den ganzen rest warten den man zuvor schon 100 mal gesehen hat

so ungefähr



00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
0000000000000000/XXXXXXXXXXXXXXXXXXXX\000000
0000000000000000|XXXXXXXXXXXXXXXXXXXX|000000
0000000000000000|XXXXXXXXXXXXXXXXXXXX|000000
0000000000000000|XXXXXXXXXXXXXXXXXXXX|000000
0000000000000000|XXXXXXXXXXXXXXXXXXXX|000000
0000000000000000\XXXXXXXXXXXXXXXXXXXX/000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000


0 = preview

X = teil der zuerst berechnet wird


oder mit 2 rahmen


00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
0000000000000000/XXXXXXXXXXXXXXXXXXXX\000000
0000000000000000|XXXXXXXXXXXXXXXXXXXX|000000
0000000000000000|XXXXXXXXXXXXXXXXXXXX|000000
00000000/YYYYYYY|XXXXXXXXXXXXXXXXXXXX|000000
00000000|YYYYYYY|XXXXXXXXXXXXXXXXXXXX|000000
00000000|YYYYYYY\XXXXXXXXXXXXXXXXXXXX/000000
00000000|YYYYYYYYYYYYYYYYY|00000000000000000
00000000|YYYYYYYYYYYYYYYYY|00000000000000000
00000000|YYYYYYYYYYYYYYYYY|00000000000000000
00000000|YYYYYYYYYYYYYYYYY|00000000000000000
00000000\YYYYYYYYYYYYYYYYY/00000000000000000
00000000000000000000000000000000000000000000


0 = preview

X = 1. higher priorty rectangle
Y = 2. higher priorty rectangle

natürlich beliebig erweiterbar

und wenn er mit den rechtecken fertig ist macht er den rest des bildes fertig



wahrscheinlich ist das ganze mit eine begrenzung von 3 higher priority rectangles schon getan, wie gesagt beliebig erweiterbar


und dann noch die idee sowohl first hpr als auch last hpr, dh ob das erste oder das jeweils letzte gezogene rechteck dei allerhöchste priorität hat. (natürlich verstellbar mit hotkey und im GUI ;) )


naja so ähnlich, ich weiß ihr schafft das :D

cya axel

[PhoenixFG]

Hm, und wenn ihr gerade dabei seid, könntet ihr noch ein OS entwerfen. Das sollte natürlich alle Vorteile der derzeitigen Betriebssysteme enthalten und die Nachteile weglassen. :bad3:

MfG

[Kennung Eins]

Originally posted by PhoenixFG
Hm, und wenn ihr gerade dabei seid, könntet ihr noch ein OS entwerfen. Das sollte natürlich alle Vorteile der derzeitigen Betriebssysteme enthalten und die Nachteile weglassen. :bad3:

MfG Das trifft es E X A K T.

[zeckensack]

Wischtischer Bugfix! (http://home.t-online.de/~zsack/brot.zip)
Böses Speicherleck gestopft. Unbedingt aufrüsten.
jeder Kontext hat jetzt ein Maximum an Speicher, das er für die History verbratzt. Die aktuelle Ansicht und die Arbeitsdaten für die im Hintergrund ratternden Generatoren werden nicht mitgezählt. Kann über die Kommandozeile gesetzt werden. Bsp:
brot2 -megs=32

Default sind 96 MB. Oder besser gesagt MiB, die Unterscheidung ist aber eh wurscht, denn ... nochens: er hält sich nicht exakt daran, starrt also nicht zu genau auf den Systemmonitor.
Kompression ist drin und hilft bei letzterem
Die History ist jetzt 64 Einträge lang. Die aktuelle Ansicht ist wie gehabt, alles andere ist komprimiert. Wenn der Speicher auch dafür nicht reicht, dann werden die von der aktuellen Position am weitesten entfernten Einträge auf ihre rohen Koordinaten zusammengestutzt und belegen dadurch fast garnix mehr.
brute-force ist wieder draußen. Macht einfach keinen Sinn und es bestand die Gefahr, es 'aus Versehen' zu wählen.
Noch ein paar tausend Kleinigkeiten, die ich alle wieder vergessen habe :eyes:

[aths]

Das sind wichtige Fortschritte auf dem Weg zum "Film" :)

Das mit der History ist 'ne megageile Sache - wenn man die jetzt noch abspeichern könnte... weitere Kommentare zur aktuellen Version spare ich lieber - das würde sonst in einer unerträglichen Lobhudelei ausarten.

[mh01]

Originally posted by zeckensack
Wischtischer Bugfix! (http://home.t-online.de/~zsack/brot.zip)
Böses Speicherleck gestopft. Unbedingt aufrüsten.
jeder Kontext hat jetzt ein Maximum an Speicher, das er für die History verbratzt. Die aktuelle Ansicht und die Arbeitsdaten für die im Hintergrund ratternden Generatoren werden nicht mitgezählt. Kann über die Kommandozeile gesetzt werden. Bsp:
brot2 -megs=32

Default sind 96 MB. Oder besser gesagt MiB, die Unterscheidung ist aber eh wurscht, denn ... nochens: er hält sich nicht exakt daran, starrt also nicht zu genau auf den Systemmonitor.
Kompression ist drin und hilft bei letzterem
Die History ist jetzt 64 Einträge lang. Die aktuelle Ansicht ist wie gehabt, alles andere ist komprimiert. Wenn der Speicher auch dafür nicht reicht, dann werden die von der aktuellen Position am weitesten entfernten Einträge auf ihre rohen Koordinaten zusammengestutzt und belegen dadurch fast garnix mehr.
brute-force ist wieder draußen. Macht einfach keinen Sinn und es bestand die Gefahr, es 'aus Versehen' zu wählen.
Noch ein paar tausend Kleinigkeiten, die ich alle wieder vergessen habe :eyes:


Jetzt wird mir klar, warum die Kiste nach einer Vergrößerung der Auslagerungsdatei auf 1.5 GB immernoch meinte, dass zu wenig Speicher vorhanden sei...:|

[Lost Prophet]

ähem, wo genau kann ich das mit der speichergröße eingeben???

in der eingabeaufforderung auf jeden fall nicht

ich steh an

mag aber grosse history =)

bitte hilfe

cya axel

[zeckensack]

Originally posted by Purple_Stain
ähem, wo genau kann ich das mit der speichergröße eingeben???

in der eingabeaufforderung auf jeden fall nicht

ich steh an

mag aber grosse history =)

bitte hilfe

cya axel Doch, Eingabeaufforderung.

ZB
Brot2 -megs=7
Brot2 rainbow.pal
brot2 -megs=0 royal.pal
brot2 neon.pal -megs=512
Das sind alles gültige Kombis. Um's leichter zu machen, kannst du dir eine Batch-Datei schreiben:
REM short_bread.bat
@ECHO OFF
brot2 -megs=1 %1 %2

Die wird im nächsten Release auch enthalten sein.

Natürlich kannst du dir auch eine Verknüpfung mit den Parametern bauen (Rechtsklick/Ziehen/Verknüpfung erstellen). Da diese Dinger leider absolute Verzeichnisse enthalten, würde es wenig Sinn machen wenn ich eine fertige Verknüpfung mitliefere.

[turboschlumpf]

mal ein paar noob fragen zum entspannen:

was gibt die 'efficiency' genau an?

wie groß ist der unterschied zwischen den verschiedenen 'optimization methods' bezüglich geschwindigkeit und genauigkeit?

gabs da nicht mal noch ne dritte? zumindest kann ich mich noch an ne andere art des bildaufbaus erinnern.

[zeckensack]

Originally posted by turboschlumpf
mal ein paar noob fragen zum entspannen:

was gibt die 'efficiency' genau an?Das gibt an, wieviele Samples nicht berechnet, sondern 'geraten' wurden. Oder in anderen Worten die durch die gewählte Optimierungsstrategie eingesparte Rechenzeit.
wie groß ist der unterschied zwischen den verschiedenen 'optimization methods' bezüglich geschwindigkeit und genauigkeit?Tracing bietet die höchste Effizienz. Es versucht gleichfarbige Flächen zu finden, indem es nur deren äußere Konturen abtastet.
Box matching zerteilt das Bild rekursiv in rechteckige Stückchen, und füllt diese wenn alle Ränder des Rechtecks gleichfarbig sind.

Rein theoretisch/mathematisch sind beide Methoden gleich gut, praktisch können aufgrund von Aliasing Details die im schwarzen Kern liegen 'vergessen' werden. Bei contour tracing ist die Gefahr daß das passiert wesentlich höher als bei box matching. Praktisch vergißt box matching nie irgendwelche Details, weil's 'chaotischer' ist.
gabs da nicht mal noch ne dritte? zumindest kann ich mich noch an ne andere art des bildaufbaus erinnern. Es gab ganz kurz die Option für brute force, wobei einfach zeilenweise jedes Sample ausgerechnet wird, ganz ohne irgendwelche Mustererkennung.

Ich hab's aus dem Client rausgenommen, weil's IMO unnötig ist. Die DLL beherrscht diesen Modus allerdings noch. Wer selbst einen Client schreiben (oder meinen modifizieren) will, dem steht es weiterhin frei das zu benutzen.

[aths]

zs,

um den Bildaufbau-Fortschritt anzugeben, was sagst du dazu: Er zählt für jedes gemalte Sample einen Integer hoch. Die Gesamt-Samplezahl ist auch bekannt. Und schon weiß man exakt, wie weit man noch ist.

[turboschlumpf]

thx

aths, darf man fragen mit welchen einstellungen du deinen prozessor quälst?

[zeckensack]

Originally posted by aths
zs,

um den Bildaufbau-Fortschritt anzugeben, was sagst du dazu: Er zählt für jedes gemalte Sample einen Integer hoch. Die Gesamt-Samplezahl ist auch bekannt. Und schon weiß man exakt, wie weit man noch ist.
xxxxxxx xxxxxxx
x00x00x x00x00x
x00x00x x00xxxx
x00x00x x00x00x
xxxxxxx => xxxxxxx
x00x00x x00x00x
x00x00x x00x00x
xxxxxxx xxxxxxx
Wir sehen ein paar kleine Rechtecke und ihren nächsten (möglichen) Verfeinerungsschritt. Extra klein, um das Argument zu forcieren:
Rechteckskanten, die nicht am Bildrand liegen, sind immer in mindestens zwei Rechtecken enthalten. Man darf diese nicht mehrfach zählen.
Wird ein Rechteck unterteilt, ist deren Mittelachse wieder in beiden Teilen enthalten. Die Kanten waren darüberhinaus bereits im ursprünglichen, nicht unterteilten Rechteck enthalten. Auch da besteht wieder die Gefahr, doppelt zu zählen.

[Lost Prophet]

Originally posted by zeckensack
Doch, Eingabeaufforderung.


Das war auch mein erster gedanke, aber irgenwie scheint bei mir die eingabeaufforderung gelockt zu sein ich kann

NICHTS

eingeben


cya axel

[Nagelbrett]

.. er meint das als startparameter, den du an die exe übergibst
nicht.. während der laufzeit ins console window

[aths]

Originally posted by turboschlumpf
thx

aths, darf man fragen mit welchen einstellungen du deinen prozessor quälst? Die Frage verstehe ich nicht ganz. Einstellungen welcher Art?

[aths]

Originally posted by zeckensack
Wird ein Rechteck unterteilt, ist deren Mittelachse wieder in beiden Teilen enthalten. Die Kanten waren darüberhinaus bereits im ursprünglichen, nicht unterteilten Rechteck enthalten. Auch da besteht wieder die Gefahr, doppelt zu zählen. Du berechnest doch keine Samples doppelt? Du malst doch keine Samples mehrfach? Oder doch?

[turboschlumpf]

Originally posted by aths
Die Frage verstehe ich nicht ganz. Einstellungen welcher Art?

naja, wie hoch musst du denn die interations bei einem richtigen "monsterbild" schrauben??

3x3 ssaa liefert ja schon ganz gute ergebnisse, oder gehst du auch hier ganz gern in die vollen??

auflösung eher klein oder so um die 2048x1536??

irgendwie müssen mehrere stunden rechenzeit ja zu stande kommen ;)

[aths]

Originally posted by turboschlumpf
naja, wie hoch musst du denn die interations bei einem richtigen "monsterbild" schrauben??Hängt von der "Gegend" ab. 1'000'000 sind aber durchaus noch drin, sobald man sich nicht im ExtremFloat-Bereich bewegt.
Originally posted by turboschlumpf
3x3 ssaa liefert ja schon ganz gute ergebnisse, oder gehst du auch hier ganz gern in die vollen??3x3 nehme ich für das Vorschaubild. Wenns mir gefällt, render ich mit 8x8.
Originally posted by turboschlumpf
auflösung eher klein oder so um die 2048x1536??So wie der kleine Moni hergibt (Zweit-Monitor), der mit 800x600 läuft.
Originally posted by turboschlumpf
irgendwie müssen mehrere stunden rechenzeit ja zu stande kommen ;)Allerdings.

[turboschlumpf]

Originally posted by aths
Hängt von der "Gegend" ab. 1'000'000 sind aber durchaus noch drin, sobald man sich nicht im ExtremFloat-Bereich bewegt.


:o

[Lost Prophet]

wie heist es so schön:

unser tägliches brot gib uns heute!


du bist schon ein bisschen im rückstand :D

oder arbytest du noch am artikel für die PCGH (?)

*auch-gespannt-wart*

cya axel

[zeckensack]

Originally posted by Purple_Stain
du bist schon ein bisschen im rückstand :D

oder arbytest du noch am artikel für die PCGH (?)
Interessant daß du das gerade jetzt erwähnst :|

Das Release, das aths immer noch nicht glücklich machen wird (http://home.t-online.de/~zsack/brot.zip)
Für die Gemeinde: Paletten-Cycling. Vorwärts und rückwärts mit variabler Geschwindigkeit. Einfach ein paar mal C drücken, und dann noch ein paarmal SHIFT+C. Das schafft ihr. Macht Spaß =)
Schon wieder schnelleres Downfiltering
Arbeitsanzeige für Hintergrund-KHRUNSCHing. Man achte auf den kleinen blinkenden Punkt.
Korrekte Fortschrittsanzeige bei Box Matching
Somewhat 'snappier' all around. Weniger unnötige Kompression/Dekompression. Die History sollte sich also jetzt deutlich flüssiger verhalten.
Kleinere Unstimmigkeiten beim Wechsel der 'Methode' und Umschalten des Previews gefixt. Das Preview kann jetzt nicht mehr bereits abgegraste Bildteile dauerhaft verhunzen.
Apropos Preview: größere Änderungen am Preview, schamlose Speed-Optimierung
Apropos Speed: Nach Abschluß der Berechnung wird jetzt die Gesamtdauer angezeigt.
Kompression/Dekompression jetzt viel schneller (fauler Kompromiß, die Kompressionsrate ist leicht gesunken)
Downfiltering von der Berechnung entkoppelt. Die Berechnung läuft jetzt mit so circa 4 fps, die Bildausgabe erfolgt seltener. Dh daß das Interface im Schnitt schneller reagiert, ohne daß Leistung für's Filtern verschwendet wird.
Dokumentation leicht überarbeitet
Größenänderungen (mit der Maus am Fenster zerren) gehen jetzt flüssiger. Intern wird jetzt sofort das aktuelle Bild weggeschmissen und erst bei Berchnung/Anzeige wieder angelegt. Bisher hat's im 75Hz-Takt (oder halt so schnell, wie Windows die resize-Messages schickt) die internen Puffer verbogen.

Für die Coder: We are LGPL, baby
C++ wrapper für's komplette DLL-Interface
Import-Lib ins Paket mit aufgenommen für leichteres Client-Basteln :)
neue Interfaces für Paletten-Cycling. Der Core kann Cycling viel besser machen als der Client, glaubt mir, ich hab's ausprobiert.
Bitmaske und Bild verheiratet, und aus der Fraktal-Klasse ausgelagert ('MaskedImage')
Ein paar experimentelle Ansätze zu 'Save to disk'
History-Klasse weggeworfen und die Funktionalität direkt mit der Context-Klasse verheiratet


Und wie üblich sicher noch ein paar dutzend Kleinigkeiten die ich schon wieder vergessen habe ;)

[zeckensack]

@aaaaaths! :)

Ich kann überhaupt kein Pascal, aber versuch bitte mal, ob das hier läuft (mit der brot_core-DLL im gleichen Verzeichnis):
program ???
uses ???
var result:integer;
function bc_create_context(megs: Integer): Integer; stdcall;
external 'brot_core.dll' name 'bc_create_context';

begin
result:=bc_create_context(24);
end.

[aths]

Originally posted by zeckensack
@aaaaaths! :)

Ich kann überhaupt kein Pascal, aber versuch bitte mal, ob das hier läuft (mit der brot_core-DLL im gleichen Verzeichnis):
program ???
uses ???
var result:integer;
function bc_create_context(megs: Integer): Integer; stdcall;
external 'brot_core.dll' name 'bc_create_context';

begin
result:=bc_create_context(24);
end. Ja, und wo soll ich das hinrendern lassen? Ich hab von _dem_ shice (DLLs nutzen, VCL, ...) doch keine Ahnung! Ich bin ja nur der, wo immer das Anfängerzeugs macht.

[Kennung Eins]

Ich bastel mal an einer kleinen Delphi Implementation.

ZSack, gib mal bitte ein paar Anweisungen, was ich alles so zu tun hab. Ich hab grad ein paar Minütchen in die brot_core_interface.h geschaut - ist es richtig, daß ich nur die dort aufgeführten Methoden zu benutzen brauch?

[zeckensack]

Originally posted by Kennung Eins
Ich bastel mal an einer kleinen Delphi Implementation.

ZSack, gib mal bitte ein paar Anweisungen, was ich alles so zu tun hab. Ich hab grad ein paar Minütchen in die brot_core_interface.h geschaut - ist es richtig, daß ich nur die dort aufgeführten Methoden zu benutzen brauch? Ist richtig, du brauchst nur das, was in diesem Header steht :)

Wem meine Makros zu kompliziert sind, hier nochmal die Kurzerklärung:

//set palette cycling speed in palette entries per second. Both positive and negative values are valid
BROT_FUNCTION(bc_set_palette_cycling_speed,void,(bc_context c,float speed));
//set a new generator (=optimization strategy) by enumerant
BROT_FUNCTION(bc_set_generator_type,int,(bc_context c,int type));

In rot der Name der Funktion.
In grün der Typ des Rückgabewerts.*
In blau die Parameterliste.

'Normal' geschrieben, sähe das so aus:void bc_set_palette_cycling_speed(bc_context c,float speed);
int bc_set_generator_type(bc_context c,int type);

bc_context ist (auf der Client-Seite) btw ein stinknormales int.
Die meisten Funktionen wollen das als ersten Parameter, weil's interne Daten identifiziert. Ein Client-Programm kann auf diese Weise mehrere getrennte Kontexte, und damit getrennte Fenster, jeweils mit eigenen histories und Einstellungen fahren. Auch mehrere Client-Echsen können somit gleichzeitig auf eine einzelne DLL-Instanz zugreifen.

Die andere Möglichkeit wären exportierte Klassen gewesen, aber das ist schrecklich unportabel :)

*Rückgabetyp 'void' bedeutet in pascal AFAIK 'procedure' anstelle von 'function'

[Kennung Eins]

Alles gloar.

Ich guck mir nun erstmal deine brot2.cpp an.

[Lost Prophet]

also erstmal ein dickes :O :O :O @ paletten-cycling & speed-ups


trotzdem bin ich historytechnisch nicht so weit wie ich möchte, bitte daher ganz lieb um eine idiotensichere anleitung zum speicher-erhöhen


achja, mein prof hat gesagt, das is weltklasse, und das obwohl das vor mindestens 3-4 versionen war ;)


cya axel

[aths]

Originally posted by Purple_Stain
trotzdem bin ich historytechnisch nicht so weit wie ich möchte, bitte daher ganz lieb um eine idiotensichere anleitung zum speicher-erhöhen Verknüpfung erstellen, dort als Parameter -meg=x angeben, wobei X eine Ganzzahl im Bereich von 1 bis "sehr groß" sein kann.

[zeckensack]

Originally posted by aths
Verknüpfung erstellen, dort als Parameter -meg=x angeben, wobei X eine Ganzzahl im Bereich von 1 bis "sehr groß" sein kann. Fast richtig:
0 ist auch ein zulässiger Wert.
Werte über 1024 werden abgeschnitten (ergo Speicherbegrenzung auf ein GiB).
Negative Werte werden durch irgendeinen Default-Wert umgewandelt (habbich vergessen :| ).

[Kennung Eins]

Originally posted by zeckensack
Negative Werte werden durch irgendeinen Default-Wert umgewandelt (habbich vergessen :| ).
96 Männer in Black :)

[ethrandil]

erm, was begrenzt denn die Speicherbegrenzung??
siehe Attachment, bei standardsettings. (96)
Ist das normal, spinnt windoof, oder ist das alles GUI-Overhead ... :?
EDIT: Nach der Berechnung isses auch noch über 120 MB ...
EDIT: Ich hab mal die .bat mit 96-MB versucht, nu kommt er nicht über 96 mb mehr :)
Aaaber ich seh nur schwarz :eyes: Ich hab partout kein bild ... auch die F-Tasten gehen nicht. Wenn ichs normal starte gehts. Win2k, SP2, Radeon 8500, catalyst 3.0

[zeckensack]

Originally posted by ethrandil
erm, was begrenzt denn die Speicherbegrenzung??
siehe Attachment, bei standardsettings. (96)
Ist das normal, spinnt windoof, oder ist das alles GUI-Overhead ... :?
EDIT: Nach der Berechnung isses auch noch über 120 MB ... 1)
a)Speicher für alle Fraktale in der History
Höhe*Breite*ein Byte
+ Cachemaske: ~(Höhe*Breite)/8
+ interpolierte Parameter: (Höhe+Breite)*40 Byte <-Peanuts
+ Kleincreme: ~ 100 Byte

Wobei Höhe/Breite hier die logische Auflösung sind. Bei 3x3 AA also jeweils dreimal so groß wie das Fenster.

'Entfernte' Fraktale werden bei echter Überschreitung des Limits (Kompression hilft nix mehr) auf ~100 Bytes reduziert, bis es wieder paßt.

b)Nicht ans Limit gezählt werden:
Das aktuell in Sicht befindliche Fraktal (1*siehe oben)
Temporärdaten für die Mustererkennung (potentiell oioioi)
RGB-Ausgabe (3*Fensterhöhe*Fensterbreite)
Sonstiger Verwaltungsoverhead, deutlich unter 100kB

[zeckensack]

Originally posted by ethrandil
EDIT: Ich hab mal die .bat mit 96-MB versucht, nu kommt er nicht über 96 mb mehr :)
Aaaber ich seh nur schwarz :eyes: Ich hab partout kein bild ... auch die F-Tasten gehen nicht. Wenn ichs normal starte gehts. Win2k, SP2, Radeon 8500, catalyst 3.0 In dem Konsolenfenster sollte direkt beim Start stehen, von wo er versucht die Palette zu laden. Wenn das nicht das Programm-Verzeichnis ist, dann isses schonmal schlecht.

Lass mich raten:
WinXP. C:\Eigene Dateien\blabubu ???

[ethrandil]

konsolenfenster:
Deep zoom by zeckensack *hrhr*

This was getting overly long, so have a look at the readme for controls.

memory limit is 96 megabytes
Loading places: brot2places
loading palette: brot2rainbow.pal
sys: wintk. Position der Paletten & eigentlich allem D:\Programme\mandel_extremefloat_dll
EDIT: Hmm, wenn ich manuell ne Palette lade gehts :/
NOCHNEDIT: Hab nu den absoluten Pfad inner bat. nu gayts. :)

[mh01]

Dein schlimmster Albtraum(:D) hätte da mal eine Frage:

Wie hoch darf die Auflösung eigentlich maximal sein?
Hintergrund dieser Frage ist die Tatsache, dass der Fensterinhalt ab einer bestimmten Festergröße (welche genau weiß ich nicht, habe auch keine Lust die einzelnen Pixel zu zählen;)) verschwindet, d. h. alles wird schwarz und in der Titelleiste steht sofort 'done'. Diese Maximalgröße ist sowohl in horizontaler, als auch in vertikaler Richtung gegeben.

MfG


Marc

Edit: Dreckfuhler

[zeckensack]

Originally posted by ethrandil
konsolenfenster:
Deep zoom by zeckensack *hrhr*

This was getting overly long, so have a look at the readme for controls.

memory limit is 96 megabytes
Loading places: brot2places
loading palette: brot2rainbow.pal
Fix (http://home.t-online.de/~zsack/brot.zip) Jopp. Hoffentlich. Bitte kurz ausprobieren.
'move' ist jetzt endlich clever. Dh daß bei der Navigation mit den Pfeiltasten tatsächlich bereits berechnete Bildteile wiederverwertet werden. Ich glaub ich hab's Doku-Update vergessen, von daher: SHIFT+Pfeiltasten für schnelles, nur Pfeiltasten für unschnelles Schieben
History auf 256 Plätze rauf :naughty:
Mal schaun, ich glaube kaum daß noch mehr sinnvoll ist ...

[zeckensack]

Originally posted by mh01
Dein schlimmster Albtraum(:D) hätte da mal eine Frage:

Wie hoch darf die Auflösung eigentlich maximal sein?
Hintergrund dieser Frage ist die Tatsache, dass der Fensterinhalt ab einer bestimmten Festergröße (welche genau weiß ich nicht, habe auch keine Lust die einzelnen Pixel zu zählen;)) verschwindet, d. h. alles wird schwarz und in der Titelleiste steht sofort 'done'. Diese Maximalgröße ist sowohl in horizontaler, als auch in vertikaler Richtung gegeben.

MfG


Marc

Edit: Dreckfuhler Sowas habe ich hier nicht gesehen.
Ich hab gerade 1600x1200 mit 8x8AA gebastelt, funzt :)

[ethrandil]

Aufnh ersten Blick: fixed :)

[mh01]

Hab jetzt doch mal gezählt (Photoshop rulez;)) - bis 1024 x 1024 macht er mit, sobald das Bild in einer Dimension 1025 Pixel erreicht ist alles schwarz...

MfG


Marc

[aths]

Wann ist die History endlich auf Platte speicherbar?

Zecki, warum richtest du es nicht so ein, dass die Bilder aus der History, sofern sie nicht mehr in den RAM passen, komprimiert auf Platte abgelegt werden?

[Lost Prophet]

meine vorschläge (bitten)


ein rücksetzten auf die standard-paletten-konfig (?) nach dem paletten-cycling.
edit2: hat sich erledigt: palette neu laden ;)
eine pause-taste
benötigte rechenzeit wird in sec, min, std, tagen ( ;D ) ausgegeben
bei einer 256er-history erschiene mir eine erhöhung des maximal-erlaubten speichers sinnvoll (mehr als 1024MB),
vielleicht falls möglich das man sogar auswählen kann auf welcher platte die auslagerungsdatei ist, falls die default-platte zu wenig platz hat)


das wärs glaub ich erstmal

dann noch eine frage

kann das sein, das du bei ungefähr XXXXXe-14 (15) auf die extremefloats schaltest, weil da is so eine art magische grenze ab der die dauer für die berechnung nach oben schnellt, die ich mir nicht anders erklären kann

edit:
aktuellstes beispiel: 7.6294e-14 auf 4.7684e-14 (gleicher mittelpunkt, iterations = 5712)

99.3 sec auf 8979.7 sec :D





die andern fragen die ich noch stellen wollt, hab ich vergessen ;)


cya axel

[zeckensack]

Originally posted by aths
Wann ist die History endlich auf Platte speicherbar?Jetzt! (http://home.t-online.de/~zsack/brot.zip)
Komplette History* speichern mit H. Ihr habt die Wahl zwischen 'alles was da ist', und 'für platzsparende Menschen, die gerne nochmal alles durchrechnen lassen wollen'. Laden mit L.
*Eigentlich der komplette Context, inklusive Paletten, Gamma-Einstellung, einem eigenen Generator-Typ pro Ansicht, Status des Previews und Speicherlimit. Das Speicherlimit einer geladenen Datei kann das auf der Befehlszeile angegebene überstimmen.
Paletten-Reset und ein Ende der Kopfschmerzen mit SHIFT+P

Extra-Spaßfaktoren:
Offizielle Erlaubnis von Tim Wegner erhalten, die Paletten zu verteilen
Pedantischerer LGPL-Header in jeder Datei, Changelogs angesetzt
Neue Interfaces: bc_save_all; bc_save_minimum; bc_load. Nimmt jeweils Dateinamen (schwere Design-Entscheidung ...)
C++-Wrapper für's DLL-Interface entsprechend erweitert
ein paar kleinere Fixes irgendwo

[zeckensack]

Originally posted by mh01
Hab jetzt doch mal gezählt (Photoshop rulez;)) - bis 1024 x 1024 macht er mit, sobald das Bild in einer Dimension 1025 Pixel erreicht ist alles schwarz...

MfG


Marc Es ist mir immer noch eine Brezel ;)

[zeckensack]

Originally posted by aths
Zecki, warum richtest du es nicht so ein, dass die Bilder aus der History, sofern sie nicht mehr in den RAM passen, komprimiert auf Platte abgelegt werden? Exakt das macht die virtuelle Speicherverwaltung von Windows. Warum das Rad neu erfinden?

[zeckensack]

Originally posted by Purple_Stain
meine vorschläge (bitten)


ein rücksetzten auf die standard-paletten-konfig (?) nach dem paletten-cycling.
edit2: hat sich erledigt: palette neu laden ;-)
eine pause-taste
benötigte rechenzeit wird in sec, min, std, tagen ( ;D ) ausgegeben
bei einer 256er-history erschiene mir eine erhöhung des maximal-erlaubten speichers sinnvoll (mehr als 1024MB),
vielleicht falls möglich das man sogar auswählen kann auf welcher platte die auslagerungsdatei ist, falls die default-platte zu wenig platz hat)

1)Dein Wunsch wurde trotzdem erhört. Großes P mit SHIFT :-)
2)Hmmm ... nein :D
3)" "
4)Meinst? Einer der Gründe für dieses hard limit ist daß Windows schonmal elegant die Grätsche macht, wenn man so große Dateien erzeugen und benutzen will. Ich könnte bis 2GB gehen (ja, auch auf Win98SE ;-) ), aber wollt ihr das wirklich? So schnell kannst du IMO garnicht durchblättern, wie die Bilder im Hintergrund wieder aufgebaut werden. Jedenfalls bei gemäßigten Rechenanforderungen :|
4b)siehe Antwort auf aths' Posting. Ich swappe nicht selbst.

das wärs glaub ich erstmal

dann noch eine frage

kann das sein, das du bei ungefähr XXXXXe-14 (15) auf die extremefloats schaltest, weil da is so eine art magische grenze ab der die dauer für die berechnung nach oben schnellt, die ich mir nicht anders erklären kann

edit:
aktuellstes beispiel: 7.6294e-14 auf 4.7684e-14 (gleicher mittelpunkt, iterations = 5712)

99.3 sec auf 8979.7 sec :DJa, das dürfte so ein Übergang sein. Es gibt aber keine feste Grenze dafür. Das hängt von der Fenstergröße, dem AA-Setting, und auch der Position ab (-2.0/0.0 ist anfälliger für numerische Probleme als -0.25/0.35). Wird also dynamisch bestimmt, bzw untersucht, ob normale Fließkommazahlen noch gehen.
die andern fragen die ich noch stellen wollt, hab ich vergessen ;-)


cya axel Kenn ich :D

[aths]

Originally posted by zeckensack
Exakt das macht die virtuelle Speicherverwaltung von Windows. Warum das Rad neu erfinden? Weil: Nach ausschalten virtueller RAM futsch. Jetzt mit der speicherbaren History bin ich aber vorläufig besänftigt :)

[Lost Prophet]

Originally posted by zeckensack

1)Dein Wunsch wurde trotzdem erhört. Großes P mit SHIFT :-)
2)Hmmm ... nein :-D
3)" "
4)Meinst? Einer der Gründe für dieses hard limit ist daß Windows schonmal elegant die Grätsche macht, wenn man so große Dateien erzeugen und benutzen will. Ich könnte bis 2GB gehen (ja, auch auf Win98SE ;-) ), aber wollt ihr das wirklich? So schnell kannst du IMO garnicht durchblättern, wie die Bilder im Hintergrund wieder aufgebaut werden. Jedenfalls bei gemäßigten Rechenanforderungen :-|
4b)siehe Antwort auf aths' Posting. Ich swappe nicht selbst.

Ja, das dürfte so ein Übergang sein. Es gibt aber keine feste Grenze dafür. Das hängt von der Fenstergröße, dem AA-Setting, und auch der Position ab (-2.0/0.0 ist anfälliger für numerische Probleme als -0.25/0.35). Wird also dynamisch bestimmt, bzw untersucht, ob normale Fließkommazahlen noch gehen.

Kenn ich :-D

also erstmal thx für die antworten, muss aber trotzdem noch ein bisschen nachhacken

1. *yeah, baby*
2. warum nicht??, wenn man grad mal für was rechenintensivees die volle leistung braucht, oder mal die restlichen berechnungen stoppen will um sich ein bisschen cycling zu geben, erschiene mir durchaus sinnvoll.
oder wie aths schon früher einmal angesprochen hat, die aktuelle history wird alls 5-10 min gespeichert und beim nächsten start wieder geladen (kein (fast) rechenzeitverlust)
3.was meinst du mit "........" "........" ? warum nicht :...(
4.Naja, nur jetzt rein theoretisch wenn man wirklich 256 bilder hat, kommt auf jedes (ca) 4 mb, was dann doch nicht so viel sein dürfte. Entweder die history ist zu lang (vom praktischen her suboptimal (;D)) oder die zugewiesene max speichermenge ist zu klein :|



zur antwort. naja, bis (ungefähr) XXe-15 gehts mit "normalen" und danach brauchst du fp24 (?) was afaik bis e-36 geht (hab ich irgendwo gelesen ???)
kann man da nicht so eine art zwischenschritt einführen? :D
naja trotzdem nochmal donk

cya axel

[Lost Prophet]

muss die liste noch mal verlängern :D

5. man kann auch einzelne bilder laden
6. beim ziehen wird das seitenverhältniss beibehalten
7. vorgefertige parameter-verknüpfung funzt nicht mit paletten

paletten werden mit der extension .lnk geöffnet, resultiert in äusserst eigenartiger und hässlicher palette
sowohl

........brot2 royal.pal -megs=1024

als auch

........brot2 -megs=1024 royal.pal

gehn palettentechnisch überhaupt nicht

megs gehn immer :|

fiel schbahs :D

edit: eine frage gayt noch: warum braucht das cycling unter 8xAA so lang, kann man das beschleunigen ??? :D

cya axel

[aths]

Originally posted by Purple_Stain
edit: eine frage gayt noch: warum braucht das cycling unter 8xAA so lang, kann man das beschleunigen ??? :DWeil jedes mal komplett neu gammakorrekt downgefiltert werden muss.

[peanball]

Ich find das Cycling auch ohne AA ziemlich langsam... ich könnte es aber nicht besser machen.
Tiefster Respekt vor Zeckis Coding-Künsten ;)

-erazor

[zeckensack]

Originally posted by Purple_Stain
2. warum nicht??, wenn man grad mal für was rechenintensivees die volle leistung braucht, oder mal die restlichen berechnungen stoppen will um sich ein bisschen cycling zu geben, erschiene mir durchaus sinnvoll.Nur damit wir uns richtig verstehen:
Du meinst cycling schonmal einschalten, wenn das akutelle Bild noch nicht fertig ist?
3.was meinst du mit "........" "........" ? warum nicht : ...(Ist ziemlich weit unten auf meiner Prioritätsliste ;)
4.Naja, nur jetzt rein theoretisch wenn man wirklich 256 bilder hat, kommt auf jedes (ca) 4 mb, was dann doch nicht so viel sein dürfte. Entweder die history ist zu lang (vom praktischen her suboptimal (;D)) oder die zugewiesene max speichermenge ist zu klein :|Ein GiB reicht mit Kompression für ~1.5 Milliarden Samples (konservativ geschätzt). Entsprechend 192 Bildern in 1600x1200 mit 2x2AA. Ich denke der beste Ansatzpunkt ist eine Verbesserung der Kompression, und nicht noch mehr brute force. Nicht viele Rechner können soviel Speicher überhaupt verwalten. Ich kann mich zB erinnern, daß es mal ein beliebter (und mittlerweile falscher) Tuning-Tip war, die Swap-Datei auf fix 200~300MB zu stellen.


zur antwort. naja, bis (ungefähr) XXe-15 gehts mit "normalen" und danach brauchst du fp24 (?) was afaik bis e-36 geht (hab ich irgendwo gelesen ???)
kann man da nicht so eine art zwischenschritt einführen? :D
naja trotzdem nochmal donk

cya axel Das Ding rechnet mit 64 Bit Fließkomma, solange (Vorsicht, Technik: ) bei der Interpolation der Parameter über das Sample-Raster keine Gleichheiten zwischen Nachbarn auftreten. Bis zu welchem Radius ich noch 'brauchbare Bilder' liefern könnte, ist mir ehrlich gesagt wurscht. Sobald ein einziges Pixel (oder AA-Sample) auf dem Bildschirm nachweisbar nicht einzigartig ist, wird alles in 224 Bit gerechnet.

[zeckensack]

Originally posted by Purple_Stain
muss die liste noch mal verlängern :D

5. man kann auch einzelne bilder laden
6. beim ziehen wird das seitenverhältniss beibehalten
7. vorgefertige parameter-verknüpfung funzt nicht mit paletten

paletten werden mit der extension .lnk geöffnet, resultiert in äusserst eigenartiger und hässlicher palette
sowohl

........brot2 royal.pal -megs=1024

als auch

........brot2 -megs=1024 royal.pal

gehn palettentechnisch überhaupt nicht

megs gehn immer :|Funzt blendend bei mir.
Was genau hast du gemacht? Eine Palette auf einen Shortcut gezogen?
Bitte mal die ersten paar Zeilen aus dem Konsolen-Fenster posten.

[zeckensack]

Originally posted by aths
Weil jedes mal komplett neu gammakorrekt downgefiltert werden muss. Exakt :)

[zeckensack]

Originally posted by [UPS]Erazor
Ich find das Cycling auch ohne AA ziemlich langsam... ich könnte es aber nicht besser machen.
Tiefster Respekt vor Zeckis Coding-Künsten ;)

-erazor Die Cycling-Geschwindigkeit ist inkrementell steuerbar, ergo: einfach mal C ein paar Sekunden gedrückt halten :)

Und wenn's ständig stockt, dann liegt's womöglich am Background processing, was ordentlich Leistung frißt. Testhalber mal mit B abschalten.

[aths]

Originally posted by zeckensack
Die Cycling-Geschwindigkeit ist inkrementell steuerbar, ergo: einfach mal C ein paar Sekunden gedrückt halten :)Ginge das noch mit VSync?

[zeckensack]

Originally posted by aths
Ginge das noch mit VSync? Im Treiberpanel :naughty:

Ich kann natürlich die entsprechende Extension benutzen, sofern verfügbar. Soll ich?
Ich kann aber nicht versprechen, ob das gefenstert überhaupt funktioniert.