[title = 1998 Sonras]
[b]Yeni Bir a[/b]

Windows 95'in k PC'de grafik programlama asndan fazla bir yenilik getirmemiti. nk grafik arabirim zerinde alan programlar, ekran ve ses kartlarna dorudan eriime sahip DOS programlarndan daha hzl olamyordu. Microsoft'un bu sorunu zmek iin hazrlad ktphane DirectX de, istenen performans vermekte zorluklar yayordu. Programclar 3 sene sonra daha hzl bir platform olan Windows 98 ve DirectX'in daha hzl srmleriyle tantlar. DOS coderlarnn kendilerinin gerekletirdii matris evirimleri ve poligon doldurma rutinleri artk DirectX'e braklmt. Fakat bu ilemler yine de ana ilemci zerinden yaplyor (poligon doldurma haricinde) ve ayn anda birden ok program altran bu platform zerinde almak, DOS programlamaya nazaran ok fazla avantaj salamyordu.
[img = LFT data/articles/1998_sonrasi/kasparov.jpg]Fakat PC demoscene'in ehresi 1999'da GeForce256 ekran kartlarnn kmasyla tamamen deiti. Bu kartn zellii matris evrimi ve klandrma gibi zaman alan ilemlerin, ekran kartnn zerinde bulunan ek bir ilemci (GPU) sayesinde paralel bir mantkla yaplabilmesiydi. Baka bir deyile grafik ilemleri Windows altnda alan dier programlardan etkilenmeden hzlca yaplabiliyordu. Bu yenilik multitasking olmasna ramen Windows'u, DOS ve Amiga ile yarabilir seviyeye getirecekti.

Bu dnemde yaynlanm en nemli demo olan Kasparov/Elitegroup eski tr ekran kartlar iin yazlm bir demodur. Geometri ve izim kodlar demo coderlar tarafndan hazrland. Kasparov, uzun ve ayrntl 3D sahnelerden (flybye) ibaret. PC zerinde takdir etmeniz gereken en son basit flybye Kasparov'dur. Daha sonraki yllarda kan ve basit geometrileri izmekten ibaret demolarn kod asndan ok fazla bir ey ifade etmediini eminim hepiniz biliyorsunuzdur.

Ertesi yl, yani 2000'de, daha zamann 3D motorlar GeForce256'y zorlamaya balamadan, o kart ikiye katlayan GeForce2 piyasaya srld. Bu yllarda PC coderlar ekran kart teknolojisinin gerisinde kaldklar iin sulanacaklard. Bununla beraber demo gruplar Haujobb'n nderliinde, kodun arka plana iten "dizayn" demolar karmaya balad. Ekranda istenildii kadar poligon baslabildii iin, bu yla damgasn 64k demolar vurdu, ama onlardan yaznn ilerleyen ksmnda bahsedeceiz. 2000 ayrca son nemli software demosu olan Spot/Exceed'in yaynland yl olmas itibari ile de nemini koruyor.

[b]PC'de 3D Programlamann Oluru Nedir?[/b]

PC'de demo programlama 2000'den bu yana ok fazla deimedi. Demolar bir ka sene iinde ekran kartlarn zorlamaya balad ve zorluklarn stesinden gelmek iin yeni araylar balad. Bu zorluklar anlamak iin biraz da detaylardan bahsedelim.

Ekran kart ekrana bir poligon basarken, ncelikle ald poligonun kelerini belli matris hesaplar ile deitirir, normal vektrleri yardm ile klandrma hesaplar yapar ve sonu olarak her kenin ekranda hangi piksele geldii ve hangi renkle izilmesi gerektiine karar verir. Bu ilemlerin tmne "vertex ilemleri" ad verilir. Bu ilemlerde coder olduka geni bir zgrle sahiptir. Poligonun kelerini, renklerini kendisi belirler, isterse kendi matris evrimlerini kendisi yapar, objelerin kelerini istedii gibi oynayarak onlar istedii hale getirebilir. stedii yere klar koyarak objelerin nasl grnmesi gerektiine az ok karar verebilir. PC demolarnda greceiniz renk oyunlar, eilip bzlen cisimler vs. codern kendi rndr.

Bu tr efektlerdeki tek sorun ok fazla poligon kullanldndaki yavalamadr. Bunun stesinden gelmek iin objeleri ekran kartnn hafzasna yerletirme yolu izlenebilir. Bu yolun arts byk objelerin ana bellekten ekran kartna aktarm her framede yaplmad iin daha hzl olmasdr. Eksisi ise ekran kartnn belleine dorudan eriimin bulunmamasdr. Yani ekran kartna alnan bir objenin sonradan deitirilmesi mmkn deildir. Kolayca rneklemek gerekirse ok fazla poligonlu bir ehri ekranda durur halde basp etrafnda uan bir kamerayla dolamak kolaydr. Lakin Hem bu ehri basp hem de binalarn saa sola eilmesini salamak zordur.

lk bakta tm izim ilemlerini ekran kart yapyor olduu iin codern yapabilecei bir ey olmadn dnebiliriz. Yani eilip bklebilen binalara sahip ehri gren insan, bunu baarann ekran kart olduunu zannedecektir. Fakat codern bunu baarmas iin software renderingte de gereken baz optimizasyonlara gitmesi gerekmektedir. Neler yapabileceine bir rnek vermek gerekirsek, eilip bklen her binay her zaman iine alacak prizmalara, kendisi matris evrimleri uygulayarak ekranda grnp grnmediini hesaplayabilir. Normalde bunu ekran kart da yapmaktadr fakat binann her poligonu iin ayr bir test uygular. Coder bu tr bir optimizasyonla binann tmnn birden test edilmesini salayabilir. Tabiki bu ok basit bir yordamdr ve sadece ekrann iinde olup olmamas deil, dier binalarn arkasna dp dmemesini de test edecek ekilde gelitirilebilir. Hatta coder, bu prizmalarn evrim ilemlerini prizmalar ekrana izdirmeden, ekran kartna yaptrmay deneyebilir ama bu yntemin pek de kolay olacan zannetmiyorum.

Demek istediim bir PC demosunda ekranda yz binlerce poligon baslabilmesinin tek mimar ekran kartlar ve hzl konfigrasyonlar deildir. Kullanlan grafik ktphanesinde bulunmayan ve o demo iin zel, teknikler gelitirmek codern elindedir. Piyasada bu ilemleri gerekletirebilen hazr ktphaneler de bulunmaktadr, fakat genel amal olduklar iin hem daha yavatrlar, hemde kodda ok fazla yer kaplarlar.

imdi ekran kartnn yapt ilere geri dnelim. Her kenin hangi piksele geldii bulunduktan ve kelerin renkleri belirlendikten sonra, bu keler arasndaki pikseller ekran kart tarafndan doldurulur. Eer dz bir doldurma istenmise her piksel son kenin rengine sahip olur, eer yumuak bir doldurma istenmise piksel btn kelerin arlkl bir ortalamasyla elde edilen renge sahip olur. Daha sonra bu renk, istee bal bir veya daha fazla dokunun gerekli renkleri ile arplabilir. Bu ilemlerin tmne de "piksel ilemleri" ad verilir.

Piksel ilemlerinin en nemli zellii, codern bu ilemler zerinde hemen hemen hi bir esneklie sahip olmamasdr. Standart yntem ile sadece poligon doldurma tipini (dz-yumuak) ve dokular seebilir. Fakat baka trl, ekranda herhangi bir pikselin hangi renge sahip olacana gnlnce karar veremez. PC demolarnda 2D'nin lmesinin ana sebebi budur. Coder, plazma ya da blur gibi tamamen 2D doaya sahip ilemleri poligonlar ve dokularla 3D'de taklit etmeye alr. lk akla gelen yntem, her piksel iin bir piksel bykle sahip olacak bir kare poligon belirleyip bu poligonlarn rengini deitirmek olabilir. Fakat yksek bir znrlkte bunu yapmak olduka zordur. Baarlrsa bile o framede daha fazla ey yapmak iin sre kalacan sanmyorum.
[img = LFT data/articles/1998_sonrasi/wecell.jpg]Ksacas hardware rendered demolarda 2D efektler, aslnda tm piksel efektleri zordur. En uuk rnekle, animasyon kullanmadan kaliteli Mandelbrot fraktallar izebilmek olduka takdir edilecek bir eydir. (Bu yzden zaten 3D fraktallar daha yaygndr.) Ayrca piksellere eriiminiz olmad iin, PC demolarnda hem vektr grafikler kullanp, hem de gze olduka hitap edecek grntler almak zordur. 2004 ylnda yaynlanan We Cell/Kewlers, ekran kartnn sadece 2D resim izmeye izin veren accumulation buffern kullanarak 3D'den uzak durmu ve ferah grntler sunmutur. Bir baka deyie %100 spritelardan oluan bir demodur.

Piksel ilemleri hardware renderingte bu kadar zorsa coderlar neden hala bu yolda srar etmektedirler? Gnmzde yazlabilecek en optimize, en hzl poligon basma rutininin bile, ekran kartnda donanm olarak bulunan ilemleri gemesi mmkn grnmemektedir. Ayrca CPU'dan bamsz alt iin, ekran kartlarn kullanmamak platformdan yarm verim almak anlamna gelecektir. Ama maalesef ekran kartlar da codera maksimum esneklii salamamakta. Bu sorunu zmeye yardmc olmak iin programlanabilir ekran kartlar piyasaya kmtr.

[b]Back to Oldskool ![/b]

Programcnn yazd kodlarla nasl alacan belirledii ekran kartlar ilk olarak 2001 ylnda gzkmeye balad. Fakat o yllarda yapabildikleri eyler ok fazla deildi. imdi neler yapabildiini ve ilerde neler yapabileceini anlamak iin tekrar detaylar konualm.

Ekran kartlarndaki vertex ve piksel ilemlerinden ve bu ilemlere codern ne kadar hakim olduundan bahsettik. Coderdan monitre giden yolda ilk karmza kan vertex ilemleri idi. Bunlar, gayet basit geometrik ilemlerdi ve codern istedii ktya uygun vertexleri hazrlamas kolayd. Ama kstlayc unsur bu vertex ve poligonlarn baslma hz idi.

Yeni nesil ekran kartlar, normal vertex ilemlerinin yanna bir de coderdan ald zel bir kod parasn yerletirerek "izim borusundan" ilerleyen vertexlere, mdahale etme ans tand. rnein bir kenin ald k belirlendikten sonra vertexi bu a gre deitirip bir tr serap efekti elde edebilirsiniz. Ya da bir dinozorun zerindeki ayrntl deri bilgisini (trtklar yarklar vs.) ekran kart belleine attktan sonra bunu, derisiz ve dk poligona sahip bir dinozorun zerine yaptrabilirsiniz. Yksek poligon ama statik bir deri ve dk poligon ama hareketli bir dinozor meshi ile yksek poligon ve hareketli bir dinozor izmeniz mmkn hale gelebilir. Buradaki en nemli nokta bu gibi kodlar codern tamamen kendisinin yazp, ekran kartna ilenmek zere yollamas. Bu kodlara "vertex shader" ad veriliyor.

Sonraki aama olan piksel ilemlerinin de yanna "pixel shader" ya da "fragment shader"larnz koyarak piksellerin nasl baslacan bir dereceye kadar programlayabilirsiniz. Bu sayede rnein ayrntl gzkmesi iin ayrntl bir meshte tuttuunuz objeyi dk poligonlu bir meshte tutup, daha sonra piksel shadernz ile ayrntl hale getirebilirsiniz (klandrma, bump mapping gibi tekniklerle). 
[img = LFT data/articles/1998_sonrasi/fairplaytothequeen.jpg]Shaderlarn 2001'de ortaya ktndan bahsettik, fakat yukarda bahsettiim rnekleri yapabilmek iin daha fazlasn beklemek gerekti. Artk ekran kart programlama nmzde yeni bir ufuk gibi duruyor. Daha nceleri "GLSL" ya da "C for Graphics" gibi dillerle yazlan shaderlara artk Assembly desteinin de gelmesi ile grafik programlama, efektleri tamamen codern yazd eski gnlere geri dnyor. Geometrik evrimler, poligon basma gibi iler ekran kartna braklp grafik programlamaya yeni balayanlara kolaylk salanrken, daha fazla esneklik isteyenlere de kendi shaderlarn yazma ve yeni rendering teknikleri kefetme olana salanyor.

imdiye dek shaderlarn kullanld birok demodaki shader zellikleri, daha nceden elde bulunan gerelerle de (poligon + doku) yaplabilir gibi duruyor. Fakat geen sene kan Fair Play to the Queen/Candela demosundaki metaballar, shaderlar ile yazlm bir raytracer kullanmadan yapmak mmkn deil gibi gzkyor. Ayrca aramzda hrsl PC demo coderlar varsa Plastic'in motoruna yaklamann da baka trl mmkn olmadn sylemek istiyorum. :)

imdiye kadar ekrana yaplan izimler iin temel yntemlerden ve bu yntemlerin hangi aamalarnn ne derece zor/kolay olduundan bahsettik. Esasna baklrsa PC'de hz optimizasyonu ok da zerinde durulan bir konu deil. nk bugn yazdnzda 20fps alan bir efekti, 60 fps altrabilecek konfigurasyonlarn 2-3 yl iinde treyeceine garanti gzyle bakabiliriz. Ekran kart belleklerinin bile ok zerine kacak sayda poligon basmak istemediimiz srece, izimde hz optimizasyonu ok fazla nemli deil. Asl hz problemi bu izim ncesinde gerekletirdiiniz hesaplamalarda beliriyor. rnein bir demoda ekranda yzlerce kp dnerken bir yavalama fark ediyorsanz bunun sebebi, kplerin iziminin yava olmasndan deil, kplerin hareketlerini belirliyen kodun yava olmasndan kaynaklanmaktadr.

Baka bir rnek olarak, bir metaball efektinde hz faktr izilen poligon saysyla ok az ilikilidir. Esasnda metaballar poligonlarla oluturuyorsak, en nemli yavalatc faktr yaplan matematiksel hesaplarn detayndadr. ok detayl bir hesap ok kaliteli bir grnt sunacakken olduka yava olabilir. Tersi ekilde hzl bir metaball efekti de belki kaliteden dn kaybettii iin bu zellie sahip olmu olabilir (Nested'dakiler gibi). (Aslnda bloblarn znrlnn kbyle orantl sayda ilem gerekmektedir.) yi bir kodu ktsnden ayran zellii, hz-kalite arpmnn daha yksek olmasdr (tm platformlarda olduu gibi).

[b]64kb Herkese Yeter[/b]

Bir demoda kodun kalitesini belirleyen tek eyin hz olmadn rendik. PC'de hz konusunda coderlar bir nebze rahat olduu iin boyut optimizasyonuna yneldiler. Normal bir demo iin kodun boyutu bir ey ifade etmediinden, tm bir demoyu eskiden olduu gibi belli boyut limitleri ierisine sktrmaya altlar.

PC coderlarnn yukarda bahsettiim boluu yaad 2000 ylnda, PC'de iki adet klasik 64k yaynland. Bunlardan ilki daha ok DOS rnlerinin takipisi ve tamamen software rendered olan Heaven Seven/Exceed. Bu 64k, tamamen asm ile yazlm gerek zamanl bir raytracer, tasarm, mzii ve anlatlmas g ruhu ile sadece PC deil tm platformlarn en iyi rnlerinden biri. Dier 64k ise, Kasparov'da imzas bulunan scenerlarn da iinde bulunduu tecrbeli coder ve mzisyenlerin almas olan The Product/Farbrausch.

Demolarda Spot'un bir devrin sonu, Kasparov'un sonraki devrin balangc olmas gibi; 64klarda da Heaven Seven DOS introlarnn sonu, The Product (fr08) Windows introlarnn balangc oldu. (Burada ilk ve son derken, release edilmekten ok akmlarn ynlerinden bahsediyoruz tabi ki.)

Peki kodu bu kadar kk yapmann yollar nelerdir? Kaypsz sktrma (yani datalar ve exenizi zipleme), sizi bir yere kadar gtrebilir. Oradan sonra nnzde iki seenek bulunmaktadr.

Bu seeneklerden ilki kaypl sktrmadr. Kaypl sktrma, sktrlacak bilginin %100 geri dnlebilir olmad durumlarda uygulanabilir. rnein bir resmi kaypl sktrp tekrar atnz vakit, resme benzer bir grnt elde edebilirsiniz. Fakat exe iindeki opcodelara byle bir sktrma uygulamak mmkn deildir. nk opcodelarda geri dnlen bilginin ncekiyle tamamen ayn olmas gerekir. 
[img = LFT data/articles/1998_sonrasi/theproduct.jpg]rnein fr08'de tm dokular, obje bilgileri ve ses samplelar kaypl sktrma ile saklanmtr. Bu bilgilerin orijinallerini, duyularla ok kolay yakalayamayacamz yksek frekanslarn "kaybederek" daha dk boyutlara indirebiliriz. Bu konun temelinde mhendislikte ok nemli bir alan olan Fourier teorisi yatmaktadr. Codern kaypl sktrma ve tekrar geri ama kodu yazabilmesi iin teoriye hakim olmas gerekmez. Ama "Kaybedilen ey ne olacak?", "Bu bilgi ne kadar klecek?" gibi sorulara cevap verebilmesi iin, teori hakknda biraz bilgi, biraz da deneyim sahibi olmas gerekir.

Fakat coderlarn ou, kartlarn buna deil de, sonraki seenee oynamaktadrlar. Bu dier seenek, bilgileri demonun balangcnda (ya da gerekiyorsa gerek zamanl olarak) ie uygun algoritmalar sayesinde oluturmaktr. Doruk noktasna demoscene ile ulaan ve "procedural generation" denilen bu yordamda kod iinde bilgi deil, bilgiyi oluturacak yntemler tutulur. rnein iinize uygun bir obje oluturucu yazdktan sonra bu kodun ufak parametrelerini oynayp, farkl objeler elde etmeniz mmkndr. Yahut benzer ekilde bir texture generator'n parametrelerinde deiiklikler yapp saysz doku elde etmek mmkn olabilir.

Kaypl sktrma bu yntemin rneklerinden biri gibi duruyor. Ama hem endstride ok nemli bir yere sahip olduu, hem de yllardr gelitirildikten sonra artk kvama geldii iin bu sonrakinden ayr tuttum. ki yntemi karlatrrsak; ilkinde konuya hakim olmak biraz zordur, ikincisinde ise algoritmalar codern duruma uygun olarak kendisinin karmas gerekmektedir. Fakat bir ok 64k'da doku oluturmaya yarayan Perlin Noise algoritmas kullanlmaktadr. Eer coder bu algoritmaya bir eyler katmamsa, bunu demodaki dokularn ya ok "bulutsal" ya da ok "tahtasal" olmasndan anlayabilirsiniz.

Ses sktrmada ise sesin dalga yaps yznden ilk tercih (Fourier) ou zaman daha mantkl. Ama yntemin doas yznden ok fazla frekansa sahip samplelar kodu kabartmadan retmek pek kolay deil. rnein insan sesini 64k iine sdrmak iin, Candytron/Farbrausch'taki gibi tek tek heceleri sktrp sonra bunlar birletirme gibi yntemlere gerek duyulur.

Bu yntemlerin ne denli gerekli olduunu anlamak iin ufak bir ka hesap yapalm. rnein elimizde 3000 genli ve 1500 keli bir objemiz olsun. Eer standart d herhangi bir yola girmezsek, tm keler iin 1500*3=4500 tane koordinata ve bu koordinatlar tutmak iin 4500*4byte=18000byte, yani 18kb alana ihtiyacmz bulunmakta. Daha bu sayya genlerin hangi kelere sahip olduu bilgisini eklemedik bile.

Ya da 400*250 24bit bir logomuz olsun. Tm logo iin 400*250*24bit=2400000bit yani 300kb alana ihtiyacmz olacak. Bu byklkteki bir logoyu bmp olarak kaydetseydik diskte bu kadar yer kaplayacakt. Kendiniz bu byklkte eitli resimler bulup nce png (kaypsz) sonra da jpg (kaypl) sktrarak deneyler yapabilir, sonularn dosya boylar ve grnt kalitelerini karlatrarak sktrma yntemleri hakknda fikir edinebilirsiniz.

Yukardaki iki rnekten anladmz gibi :) ayrntl ve de girintisi knts ok olan (yksek frekanslara sahip) bir meshi 64k iine yerletirmek ok kolay deil. Ayn ekilde, ok da byk olmayan ve algoritmik olarak oluturmas imkansz olan resimleri (rnein logolar) kayptan dn vermeden kk boyutlara drmek marifet isteyen bir i. Bir 64k'da bir logo grdmzde, yahut bir 4k'da hareket eden bir robot grdmzde, alann ounun bu elemanlara gittiini anlayabiliriz. Bu durumda intronun geri kalanna aslnda ok daha az yer kaldn kolayca karabiliriz.

Tabi ki statik bilgileri sktrarak-kendiniz oluturarak da sadece bir yere kadar gidebilirsiniz. nk geriye demonun motorunu, partlarn kodlar vs. iin de yer kalmal. Ama bu ksmlar da daha kk tutmann bir yolu var. Bu yolu iki analoji ile anlayalm.

rnein bir coder, demodaki her obje iin farkl bir izim rutini, her resim iin ayr ayr alanlar belirtiyor, her dokunun oluturulma kodu birbirinden farkl tutuyor ise o codern ba ok aryacaktr. nk ufak bir intro oluturmas gerekten zor gzkmektedir.

kinci bir coder ise bunun tam tersini yapyor, yani tm objeleri hatta resimleri ayn rutin zerinden basyorsa, hatta abartp dokular da bu rutinle oluturuyorsa (dokuya izim yaparak) bu coder ok kk introlar hazrlayabilir. Fakat introsu srekli tekrarlardan ibaret olmakla sulanacaktr. Intronun tamamndaki elementler birbirine benzedii iin (tasarm amacyla kastl olarak yaplmamsa) izleyicide olumlu etki brakmayacaktr.

lk codern yapt 64k intro ekranda birka yaz basp, bunu bir ka efektle desteklemekle snrl kalacakken; ikinci codern yapt 64k intro ise sadece benzer elementlerle (hep kpler, hep gezegenler gibi) snrl kalacak ve zaten dzinelercesi bulunan vasat introlar arasnda yerini alacaktr.

imdi bir ounuz "yi coder, bu ikisi arasnda uyumlu bir denge salayandr." benzeri bir laf etmemi bekliyor ama yanlyorsunuz. :) Bundan daha iyi bir yol, tm kodu mmkn olduunca ortak rutinler stnde yazp, bu rutinlerin ileyiini az sayda parametre ile radikal bir biimde deitirmektir. rnein dalga reten bir kodun amac softsynth iin sktrlm samplelar amak iken, ufak bir uyar ile birden texture generator haline gelebilir. (ok abarttm biliyorum :) ama o kadar da sama bir fikir deil.) Eer introda srekli yenilenen bir ak, intronun farkl yerlerinde farkl sesler, farkl efektlerle karlayorsanz; bir baka deyile bu rne intro dememizin tek sebebi 64kb'tan kk olmas ise, o zaman izlediiniz ey gerekten takdir edilesi bir demo olacaktr, ki saylar belki gerekten de iki elin parmaklarn gemiyordur.

Bu anlattklarm kk boyutlarda demolar yapmann ana unsurlar. Lafta hepsi kolay anlalr ve yaplabilir gibi gzkyor ama ben kendim tm bunlar hesaba katan ciddi bir 64k projesine balamay dnsem, nce bir fincan kahve ier, sonra bu fikrimi tekrar dnrdm sanrm. :) Zaten ok basit denmesine ramen fr08'i hala en iyi Windows 64k demosu yapan ey de bitmi ve alyor olarak karmzda durmas. (Heaven Seven' tenzih ederim.) ki demo da halen bir ok adan geilebilmi deil.

[b]PC Coding Sadece izim ve Dk Boyutlardan m baret?[/b]

Bir PC demosunun yapmnda gerek izim, gerekse kk boyutlar elde etme konusunda izlenilen genel yollardan, karlalan zorluklardan vs. bahsettik. Fakat bir demoyu bir dierinden farkl klan ey aslnda bunlarla snrl deil. Demoda kodun bu ynlerini destekleyecek baz baka unsurlar olabilir.

rnein baz demolarda iskelet animasyonlar bulunmakta. Motion capture ile elde edilmi hareketleri saymazsak, (ki codern buradaki grevi gerekten soruturulur) yumuak ekilde ilerleyen, ayrntl ve fazla tekrar olmayan insan, robot vs. hareketleri de demonun koduna verilecek deerlendirme notunu artrc elerden. 
[img = LFT data/articles/1998_sonrasi/resonance.jpg]Hareket esnasnda oynayan tm eklemlerin tek ya da iki yndeki deerlerinin her sre deeri iin hesaplanmas gerekiyor. Eer hareket eden cisimdeki eklem says ok fazlaysa, bu hareketlerle uramak gerekten zorlayc olabilir. zellikle hareket ettirilen cisim insansa, aldnz sonuta bir gerekilik pay da arayacanz iin iiniz daha da zorlayor. Elde edilen insan hareketi saniyede bir tekrarlayan kol ve bacak sallama halinde ise, hareketin stnde ok fazla uralmam yahut hareket motorunun henz tam pimemi olduunu anlyoruz. Ancak The Popular Demo/Farbrausch'taki gibi ayrntl ve uzun insan hareketlerini oluturabilmenin byk uralar gerektirdiini bilmeliyiz.

Eer kendimizi canllarla snrlandrmaz isek; eklem seimi, hareketlerdeki hzlar vs. konularda daha fazla esneklik elde ediyoruz. Bu alanda gerekten gzel rnekler grmek istiyorsanz, Portal Process'in demolarn izleyip robotlarn hareketlerini inceleyin.

Demoya art kazandrabilecek bir dier unsur da fizik efektleri. Tabi fizik dediimiz zaman bir ok efekt akla gelebilir, ama burada bahsettiim (ve asl zorluu ieren) objeler arasndaki arpmalar, yerekimi vb. kodlar. Demolar zaman tabanl olduu iin (her framede saate bakarak ekranda gsterilen eyleri hesapladmz iin) fizik kodlarn ayr ilemlerden geirmek gerekiyor. Demonun geri kalan fps bamsz olsa bile, kuvvet veya hz hesaplarnda fps'yi dikkate almak ve gerekirse belli deerlerde sabitlemek gerekiyor.

arpmalardaki bir dier zorluk da objelerin yaplar karklatnda ortaya kyor. Kplerin yahut krelerin arpmalarn kontrol etmek, daha kark objelerin arpmalarn kontrol etmekten nispeten daha kolay oluyor. Ama zaten demolarda arpan kpler ya da sallanan zincirlerden daha kark efektler grmedim. Yaplmlar arasnda en iyilerini Fairlight demolarn tarayarak kolayca bulabilirsiniz.

[b]Sonu[/b]

Her eyi zetlemek gerekirse, bir PC demosunu kod asndan deerlendirirken u noktalarn kesinlikle ele alnmas gerekiyor:

-Windows birden fazla programn ayn anda alt bir platformdur ve demolar, izim harici ilemlerinde CPU'yu dier programla paylamak zorundadr. Bu yzden rendering d efektlerin ve hesaplamalarn hzl almalar iin iyi optimize edilmeleri gerekiyor.

-Ekrana yaplan izimler ayr bir ilemci ile yaplyor. Baslan poligon says ok nadir durumlarda kstlayc bir unsur. Fakat bunun stesinden gelmenin yollar mevcut (coder tamamen GPU ve ktphanelere bal deil). Ayrca coderlarn ekrandaki piksellere direk mdahalesi olduka zor ve mmkn olduu durumlarda olduka yava.

-Ekran kartlarnn sunduu temel ilevler zerinde deneysel taklmak pek mmkn deil. Sonular karttan karta, hatta ayn kartn srcsnden srcsne deiebilir. Bu yzden ekran kartlarnn hardware zelliklerine bal kalmamalar iin coderlara shader programlama imkan sunulmu durumda.

-64k introlarda ama 64k'ya sd kadar bilgi doldurmak deil, byk bir demoyu 64k limitinde yapabilmek. Kk boyutlarda almak PC programlamadaki en byk zorluklardan biri.

-Demo, sadece ekrana baslan nesnelerden ibaret deil. Demodaki nesnelerin animasyonlar, fiziksel olaylar, zamanlama, geiler, uyumluluk (ki PC'de olduka nemli bir konu) ve kmeyen demolar yazabilmek de codern yeteneklerine bal.

-Bir demoda kod her zaman n planda olmayabilir. Bir hikaye anlatan ya da iyi bir tasarma sahip demolarda kod halen yukardaki kriterleri gizlice salyor olabilir. Atraksiyondan uzak salam bir demo motoru ile bol efekt ve atraksiyonlu ama uyumluluu dk, zar zor kmeden durabilen bir demo kodu arasndaki seim size kalm.

Bu yaz, PC demolarnn kodlarn deerlendirmede kullanlacak anahtar noktalar sunmann yan sra, PC coding iin ciddi planlar olanlara da dnmeleri gereken ynleri gsteren bir tavsiye kimliine de sahip oldu. Takdir ksm umarm yardmc olmutur. Tavsiye ksmn ise kendim bizzat uyarak snayacam :) 