Názory k článku
Obsah jednotlivých částí seriálu a galerie fraktálů

Tak tenhle seriálek, to je tedy materiálek... Fraktálním obrazcům se obdivuji už asi 10 let, první jsem objevil náhodou v programu FractInt tenkrát to jelo ve Win 3.11 na 286ce a monochromu. Nehledám v tom žádné praktické využití, jen tu krásu a podivuhodnou podobnost s přírodou.
Zvykl jsem si na Visual C++ 6.0 a všechny příklady se pokouším přepatlat do tohoto prostředí, pro grafiku používám funkce API.
Vypadá to taky dobře. Nebyla by nějaká transformační matice pro fraktální IFS větvičku? Z výkladu jsem to nějak nepochopil.

Taky jsem s FractIntem začínal na 286ce. Dokonce jsem si nakonec z výprodeje pro FractInt a programování koupil koprocesor 287 a nakonec byly výpočty rychlejší než na 386ce (40MHz) s emulátorem 387 :-)

Uvažoval jsem o tom vytvořit nějaký rozšiřitelný program na tvorbu fraktálů. Spíš něco na detailní zkoumání, tj. ve stylu FractIntu, ne XaoSu. Výpočetní smyčky samosebou v céčku, ale zatím nevím, co použít pro GUI.

Zkoušel jsem různé toolkity (FLTK, wxWidgets, QT, GTK), ale je to všechno takové molochoidní a kromě wxWidgets to také např. na Windows nevypadá nativně. Asi mi zbyly dvě možnosti: Windows verzi postavit nad API (taky mám rád VC6) a pro zbylé platformy použít QT/GTK, nebo GUI naskriptovat v TCL/TK.

Definici pro fraktální IFS větvičku dodám zítra, potřebné definiční soubory s maticemi mám doma.

Pro me je trosku omezujici podpora pouze XP a W2003. Na domacim pocitaci mam krome Linuxu jeste Windows 98 a nic dalsiho se mi kupovat nechce (nehlede na to, ze by to ten strojek taky nemusel utahnout :-). Ale mrknu se na to, GUI toolkity me zajimaji a i proto je me lito, ze vetsina z nich je takova nedotazena (snad krome Qt, ale to je o mnoho vic nez GUI toolkit).

Pánové, fraktály se mi líbí, ale spíš okrajově. Chtěl bych si přisadit něco k tomu GUI. Po letech používání nejrůznějších RADů a podobných nástrojů, jak v práci, tak pro zábavu, jsem dospěl k závěru, že jsou všechny do jednoho na H... Vyzkoušel jsem Delphi (skoro všechny verze), VC, VB, .NET. Pomocí všeho uděláte rychle okýnka a akce na klikání, ale nakonec zjistíte, že nic není dokonalé. .NET zavrhuju rovnou, jako něco naprosto nepoužitelného. U dalších postupně narazíte na problémy, které se projeví až po čase. Až na VC má většina nástrojů naprosto mizernou nebo žádnou prodporu pro lokalizaci (přepsání stringů do jiných jazyků). Při přechodu na novější verze Windows to najednou přestává fungovat, nebo jsou okénka hnusná a není na nich vidět všechno. Údržba kódu je čím dál tím težší, a běda, jak něco nedělá co má. Navíc většina RADů namastí do resourců i jinam spoustu věcí, o kterých nikdo nestojí.

Nakonec jsem dospěl k tomu, že absolutně nejbezpečnější je vytvořit GUI pomocí Windows API přímo. Při přechodu na Linux už jsem pak nic neřešil a rovnou sáhl po GTK+ 2.0. To je úplně v pohodě, aplikace zkompilovaná pod GTK běží bez překompilování na jiných distribucích a to pod GNOME, KDE i xFce, takže asi pod vším.

Na začátku to vypadá, že je to víc práce, ale ujišťuji vás, že se to vrátí, a to rychle. Takže pokud nestojíte o nějaká "fency" okýnka stylu WinAmp nebo Media Player, doporučuji pro Windows napsat okna pomocí API a zkompilovat MinGW-čkem a pro Linux napsat okna pomocí GTK+ a zkompilovat g++ -kem. Střeva pak budou moct být úplně stejná pro obě platformy, GUI bude rychlý (nejrchlejší) a poběží od 95 po Visty a od RetHatu po Xubuntu.

Nakonec, abych nevypadal, že tu planě plácám, tak pokud máte nějakou představu, jak by to GUI mělo vypadat, tak mi to pošlete a jám vám ty okýnka namastím.

Přeju hezký den.

Moc mě těší, že na tu věc má někdo podobný názor jako já. Na Windows jsem nakonec také skončil tam, kde jsem začal, tj. na čistém WinAPI. Trošku problém mám s dialogy, ani ne tak s jejich vytvářením (resource dělám ručně), ale potom se smyčkou zpráv a následným zpracováním dat. Ne že by to bylo nějak extra složité, spíš je to pracné a bojím se, aby ta aplikace neskončila jak některé další open-source aplikace: funkční, ale GUI zprasené (protože je jednodušší upravit algoritmy než šahat na GUI).

Samozřejmě okénku bych chtěl mít stejná, jako u ostatních nativních aplikací (+klasická menu a základní sadu widgetů), právě ty "výstřelky" uživatele pěkně matou, nekledě na složitější automatizaci těchto aplikací (třeba nejde poslat zprávu widgetu, který z hlediska WinAPI ani widget není).

Zapoměl jsem dodat, že na Unixech (Linux, SGI) jsem si většinou vystačil s Tcl/Tk (+volání céčkových programů), ale dnes už je problém s některými Linuxovými distribucemi, které Tcl/Tk v základní sadě neobsahují.

Tcl/Tk neznám, ale jak jsem se letmo podíval, co to je, tak bych do toho nešel. Moc to zavání vším tím, co jsem popsal v předchozím dopise, a co nechci. Jo, já RADy plošně neodsuzuju, jsou užitečné k rychlému napsání malé utilitky. Ale z vlastní zkušenosti už vím, že založit na RADu nějakou větší, komplexnější aplikaci, s ambicema na dlouhodobou údržbu a vývoj, je chyba. Rovněž je chyba vyvíjení vlastních kontrolů/widgetů. Dá se to, ale jen v krajní nouzi.

Ale zpátky k tomu problému. Samozřejmě, že GUI napsané v API představuje trochu víc kódu. Je potřeba to dobře strukturalizovat, třeba rozházet do víc souborů. Výhoda je, že v kódu pak není nic, co opravdu nepotřebuješ (pokud to teda někdo opravdu nezmastil), a když tam něco nefunguje, snáz se to najde a opraví.

Na X bych fakt doporučil to GTK+. Já to vyzkoušel na Xubuntu a jde to dobře. Je k tomu kvalitní dokumentace a spousta ukázkových příkládků, a strukturou se to dost podobá Windows API. Ve skutečnosti je to ještě jednodušší, protože do smyčky událostí se registruje pomocí callbacků, což umožňuje napsat o něco přehlednější kód. Těma callbackama už to trochu připomíná RADy, ale domnívám se, že GTK+ je nejnižší použitelná úroveň pro programování GUI (nic nižšího jsem už neobjevil). Jo a taky to jde lehce zkompilovat na 64bit.

A teď už nevím, co jsem vlastně chtěl napsat, tak končím.

Tcl/Tk je trošku jinde, než klasické RAD, ve kterých se GUI naklikává. Tady jde o programovací skriptovací jazyk (Tcl) s přidaným toolkitem (Tk), který se snaží (alespoň na Windows a trošku i na Mac OS X) tvářit nativně, i když běžný widget set dost rozšiřuje. Celé se to chová na velmi vysoké úrovni, vlastně jde o úplný opak API. Například je možné na canvas vkládat objekty, které je možné kdykoli změnit, přidat k nim callback funkce atd.

Tcl/Tk je ideální pro psaní aplikací, u kterých ještě není jasné, co mají přesně dělat (a takových aplikací je celkem dost), problém však bývá s instalací SW. Pro vnitrofiremní aplikace to však problém není, stejně jako pro rozsáhlé projekty, které stejně musí nakonfigurovat administrátor.

FLTK rozhodne neni molochoidni ( z dokumentace k 1.1:

* sizeof(Fl_Widget) == 64 to 92.
* The "core" (the "hello" program compiled & linked with a static FLTK library using gcc on a 486 and then stripped) is 114K.
* The FLUID program (which includes every widget) is 538k
)

Docela prijemne se s tim programuje, pokud clovek chce neco s cim autor nepocital, daji se zdrojaky snadno upravovat :)

Jediny problem je schizofrenie verzi - jako stabilni je oznacena 1.1, ale na verzi 2.0 se pracuje jiz nekolik let - sice aktivne, ale dlouho.

Napsal jsem ve FLTK sice jen jeden mensi programek - ale FLTK si urcite na veci ktere se maji rychle spoustet a zabirat malo pameti sve misto pod sluncem zaslouzi.

Nativne sice pod windows nebezi, ale az zas tak odlisne nevypada..

Zrovinka vcera jsem FLTK zkousel jak na Windows, tak i na Linuxu (Debian) a nevypada to spatne. Trosku u me ztraci tou ne-nativnosti, naopak se mi libi emulace GLUTu. Ja nevim, ale Hello world na 114kB je docela dost, ne? S nativnim widget setem (+nejakou nadstavbou nad nim) se da dostat pod 10kB :-) V tomto ohledu nejlepe vypada wxWindow, ale musi se vhodne zvolit, co s programem slinkovat.

wxWindows jsou vynikajici, osobne je mam ze vsech toolkitu nejradeji - ale nejsem si jisty, jestli jsou delane pro staticke linkovani. Bezne se pouzivaji na velke dynamicky linkovane aplikace a samotna knihovna (.so nebo .dll) par MB ma..

jestli chcete multiplatformovost a netrapi vas trochu vyssi naroky na pamet, pak doporucuju javu + swing - je to vcelku jednoduche. da se to i trochu nastavit, aby to vypadalo jako nativni windows aplikace.

Ano, se Swingem jsem par veci udelal, dokonce i se starym hnusnym AWT. Ale nejsem si jisty, jestli zrovna aplikace pro generovani fraktalu by mela byt v Jave. Teoreticky je na tom s rychlosti podobne jako neoptimalizovane cecko (nejake benchmarky jsem uz zkousel), ale spis me odrazuje pomalost aplikaci v Jave s GUI - napriklad veci od Oraclu ale i JEdit ci NetBeans rychlosti neoplyvaji (stejne jako jeden graficky editor, na ktery tady vysla recenze ci upoutavka. Na jmeno si nevzpominam, ale pomale to bylo strasne).

Ale pravda je, ze o Jave+Swing taky uvazuju. Asi si zkusim napsat nejaky testovaci programek a tu rychlost vyzkouset.

v jave programcim, neco malo i ve swingu, ale nic vetsiho s grafikou jsem jeste nedelal, takze s rychlosti nevim, asi bude lepsi to opravdu napred vyzkouset. Jasny je, ze java asi neni optimalni jazyk na grafiku, ale zase se to da nabusit relativne rychle, jedete to vsude kde funguje java a jazyk i vyvojovy prostredi jsou zadarmo(eclipse, netbeans).

Celkem zajimave na GUI vypada toto:
http://www.ultimatepp.org/

Jak jsem slíbil, tak dodávám transformační matice pro fraktální větvičku a další IFS fraktály. Formát odpovídá FractIntu, ale udělat si vlastní načítátko je vcelku jednoduché:

my_spiral { ; by Pavel Tisnovsky
  0.8265 -0.475 0.475 0.8265 0.0 0.0 0.9
  0.1740 -0.100 0.100 0.1740 0.2 1.0 0.1
}

dragon {
  .824074 .281482 -.212346  .864198 -1.882290 -0.110607 .787473
  .088272 .520988 -.463889 -.377778  0.785360  8.095795 .212527
  }

triangle1 {
  .5  0  0  .5  -0.5  0     .33
  .5  0  0  .5   0.5  0     .33
  .5  0  0  .5   0    0.86  .34
}

triangle2 {
  .5  0  0  .5  -0.5  0     .20
  .5  0  0  .5   0.5  0     .40
  .5  0  0  .5   0    0.86  .40
}

triangle3 {
  .5  0  0  .5  -0.5  0     .10
  .5  0  0  .5   0.5  0     .45
  .5  0  0  .5   0    0.86  .45
}

ctverec1  {
  .5  0  0  .5  -1  0     .25
  .5  0  0  .5   1  0     .25
  .5  0  0  .5   0  -1    .25
  .5  0  0  .5   0  1     .25
}

ctverec2  {
  .5  0  0  .5  -1  0     .10
  .5  0  0  .5   1  0     .30
  .5  0  0  .5   0  -1    .30
  .5  0  0  .5   0  1     .30
}

ctverec3  {
  .5  0  0  .5  -1  0     .04
  .5  0  0  .5   1  0     .32
  .5  0  0  .5   0  -1    .32
  .5  0  0  .5   0  1     .32
}

ctverec4  {
  .6  0  0  .6  -1  0     .25
  .6  0  0  .6   1  0     .25
  .6  0  0  .6   0  -1    .25
  .6  0  0  .6   0  1     .25
}

my_spiral2 { ; by Pavel Tisnovsky
  0.8265 -0.475 0.475 0.8265 0.0 0.0 0.40
  .5  0  0  .5  -1  0     .20
  .5  0  0  .5   1  0     .20
  .5  0  0  .5   0  1     .20
}

fern {
    0    0    0  .16 0   0 .02
   .85  .04 -.04 .85 0 1.6 .46
   .2  -.26  .23 .22 0 1.6 .03
  -.15  .28  .26 .24 0 .44 .03
  -.85 -.04 -.04 .85 0 1.6 .46
  }

coral {
0.307692 -0.531469 -0.461538 -0.293706 5.437621 8.719529 0.400000
0.307692 -0.076923 0.153846 -0.447552 -1.289028 4.205605 0.150000
0.000000 0.545455 0.692308 -0.195804 -4.911836 7.316535 0.450000
}
dragon2{
0.824074 0.281481 -0.212346 0.864197 -1.772710 0.137795 0.771268
-0.138580 0.283951 -0.670062 -0.279012 2.930991 7.338924 0.228732
}
feathe{
0.870370 0.074074 -0.115741 0.851852 -1.278016 0.070331 0.798030
-0.162037 -0.407407 0.495370 0.074074 6.835726 5.799174 0.201970
}
ferny{
-0.160000 -0.640000 0.433846 -0.110769 5.264632 8.111285 0.321070
0.603077 0.335385 -0.280000 0.880000 -2.757524 -0.799133 0.678930
}
flake {
-0.250000 0.750000 0.250000 0.250000 -3.412025 5.797619 0.333333
-0.250000 0.750000 0.250000 0.250000 -6.939442 2.270202 0.333333
-0.250000 0.750000 0.250000 0.250000 0.115392 2.270202 0.333333
}
fossil {
-0.017641 0.637128 0.352000 0.008000 -2.464790 8.587118 0.264315
0.603077 0.335385 -0.280000 0.880000 -1.759852 -0.659994 0.735685
}
leaf{
0.242424 -0.640152 -0.909091 -0.318182 4.613705 5.570360 0.698795
-0.090909 -0.556818 -0.484848 0.155303 -1.103621 5.655663 0.301205
}
leaf2{
0.424242 -0.651515 -0.484848 -0.344697 3.449256 2.891322 0.622449
0.030303 -0.439394 -0.636364 -0.022727 -1.396520 6.437606 0.377551
}
pincher {
0.771144 -0.484577 -0.418906 -0.724378 2.136904 7.581400 0.868575
-0.259304 -0.109453 -0.136119 0.171144 5.871343 0.808450 0.067604
0.308657 0.125373 0.265075 -0.073632 -5.649287 8.277147 0.063821
}
pull{
0.227195 -0.466437 0.688468 0.647160 0.187642 1.466229 0.572632
0.450947 -0.456110 0.325301 0.445783 4.939965 4.050190 0.427368
}
telephon {
0.824074 0.281481 -0.212346 0.864198 -2.274768 -0.147052 0.876993
-0.072222 0.422222 0.246296 0.059259 3.631163 7.337541 0.123007
}
tree1{
0.000000 0.000000 0.000000 0.600000 0.013606 -0.454544 0.443441
0.363636 0.581818 -0.454545 0.472727 -0.114619 3.329175 0.278280
-0.363636 -0.581818 -0.454545 0.472727 0.141832 3.329175 0.278280
}
tree2{
0.000000 0.000000 0.000000 0.600000 -0.159095 0.670061 0.445008
0.363636 0.481818 -0.454545 0.386061 -0.908361 4.762463 0.190237
-0.363636 -0.481818 -0.454545 0.392727 0.590171 4.708041 0.191520
-0.545455 0.027273 0.000000 -0.600000 -0.291561 5.924281 0.173235
}
z{
-0.548060 -0.181095 0.257313 -1.015920 0.818014 10.578471 0.844961
-0.135124 -0.432836 0.147065 -0.348259 2.110459 3.261798 0.155039
}


Dííííííííkýýýýýýýýý!!!
Část matic už jsem připatlal do cvičného příkladu 33_1, všechny fungujou. Teď když mám možnost nahlédnout i do toho "soukolí" kde se fraktály (nejenom IFS) tvoří, tak je to teprve fascinující.

zhodou okolností, práve dnes som natrafil na zaujímavý dokumentárny film o fraktáloch: http://video.google.com/videoplay?docid=-3034959314635185121&hl=en

Ve filmíku hezky dávají do souvislostí fraktály a okolní přírodu. Chce to jenom udělat si 53 minut času.

Doplnit propojení tohoto obsahu aktivními odkazy na příslušné díly seriálu. Pokoušel jsem se to dohledat, ale jde to těžko, názvy z obsahu nesouhlásí, číslování taky ne, spíš to vypadá na dovytvoření společného obsahu pro řadu jednotlivých článků a miniseriálů na téma fraktaly na pár let zpátky.

Já jsem ty odkazy chtěl dodělat, ale mám problém s tím, že sice mám "externí odkazy" na jednotlivé díly (tj. URL, které zobrazí prohlížeč), ale pokud do zdrojového kodu článku tyto odkazy natvrdo vypíšu, tak je redakční systém považuje za externí odkazy a přidá k nim šipečku.

Interní identifikátory jednotlivých dílů je zase složité získat z redakčního systému protože mi (ale možná něco dělám špatně) nefunguje filtrování na jednotlivé seriály, ale pouze setřídění podle názvů (to je v tomto případě na nic) nebo podle autora (to je lepší, ale mám tu smůlu, že toho paralelně píšu víc, takže se ta čísla pomíchala).

Jinak na konci článku je vždycky odkaz na obsah celého seriálu (samozřejmě jde o jeden šíleně dlouhý seriál - přes osmdesát dílů). Názvy někdy nesedí, protože jsme články místo číslování začali i v nadpisech pojmenovávat až někde od půlky.

Bylo to úžasné, dík :)

Ja vím, že už je to nuda, ale taktéž se připojuji s díky za kvalitní seriál, který by IMHO stál za vydání v knižní podobě. V kvalitní barevné křídě bych si ho milerád koupil. MMCh: Zdá se to je mně, nebo jsou v tomhle dílu fakt nejhezčí obrázky? :-)

Díky za pochvalu!

S těmi obrázky je to docela dobře možné, protože do předcházejících dílů (s výjimkou těch několika posledních) jsem tak v 60% vkládal screenshoty z demonstračních příkladů. Tady jsem se už trošku vyřádil (výběr zoomu, barevné palety, způsobu vybarvení atd.), ale pro některé obrázky (cca 10) jsem použil cizí soubory s parametry (do FractIntu).

V už konečně poslední části (příště) bude další série cca 40 obrázků; doma se mi už renderují. Bude to trvat několik nocí, protože některé obrázky jsou docela náročné na čas, protože pro odstranění aliasu jsou zdrojové obrázky několikrát větší než jejich zmenšeniny, které potom v rozlišení 800x600 vidíte v článku. Také Celeron 800 už není to nejvýkonnější PC, že :-)