[title = SER DEMO RETM 1  DEMO MOTORLARI]

Bir coder olarak ilk demonuzu yapmak istediniz. Mzik ve grafikleri hazrlayacak birilerini buldunuz. Onlar urarken siz OpenGL, Direct3D her neyse rendiniz. Sonra gelen materyallere gre bir tasarm belirlendi ve bunu hayata geirmeye baladnz. Partlar kodladnz. Beenmediniz, batan kodladnz. Gndz vakti devam edesiniz gelmedi, parti tarihini hatrlayp geceleri kodladnz. Demonuz, yola kma vaktinden ancak birka saat nce istediiniz kvama ulat.

Demonuzu partiye gtrdnz ve herkese izlettiniz. Daha dn kimse sizi duymamt, bugn herkes o demoyu kimin yaptn merak ediyordu.

Bir sonraki partinin tarihini renince Bir kez daha m? diye sordunuz kendinize. lk demonuzu yaparken ne kadar zaman alacan kestirememitiniz. Artk hem nelerden vazgemeniz gerektiini biliyor hem de daha youn bir hayat yayordunuz. Mmkn deil batan benzer bir kod hazrlayamazdnz. Belki ileride devam ederdiniz

7DX ve Nightshifte ilgi ekici bir demoyla katlp daha sonra bir daha adna rastlamadmz coderlarn yaadklar ve dndkleri az ok bunlar diye tahmin ediyorum. Bir demoyu yapmak bile o kadar aba isterken, yabanc gruplar bir senede nasl  drt demo birden karyorlar? in iinde uzun zamandr olsalar bile, bir demoyu batan sonra tekrar yazmalar gerekten ok zamanlarn alacaktr.

Bu kstlama codern yeteneklerini de ap, fiziksel bir snr haline gelebilir. Yani gece gndz hatasz alsanz bile, o kalitede rnler o kadar ksa zamanda sfrdan nasl hazrlanr? Bu yazda bunun cevabn arayacaz.

Her eyden nce ufak bir not: Yazda nereceim yntemlerin hepsini kullanmadm ama tamam uygulama planmn iinde. O yzden benzer fikirler ya da eletirileriniz olursa paylamanz benim amdan da faydal olacaktr. Belki de birka sene sonra bu yntemler nerede ie yarad nerede yaramad ekseninde bir baka yaz yazarm.

[b]SER RETM[/b]

Seri retim (ya da rapid production) benzer projelerin ortak ynlerini kullanarak bunlar daha ksa srelerde bitirme iidir. Amacmz hazrlayacamz demolarn aldklar zaman giderek drmek ve elde ettiimiz bu ek zaman kendimizi gelitirmek iin kullanmak olaca iin, seri retimin demolarda nasl uygulanabileceini bilmek istiyoruz.

lk demomuz iin alt ay uram olabiliriz, bu her demoya ayn sreyi adayacamz anlamna gelmez. En azndan bir alt ay daha urarsak, yeni demomuzun ilkini fersah fersah am olmas gerekir. Ya da ayn kalitede bir baka demoyu bir ay iinde bir dier partiye yetitirebilmeliyiz.

Aslnda bahsedeceim ey tecrbeli olanlarnzn bildii gibi yeniden kullanm (reuse). Tabi ki bunun, ilk demonun kodunda bir iki parametreyi deitirip ikinci bir demo yapmayla alakas olmayacak. Asl hedefimiz, sfrdan bir sistem tasarlayp, her demoda bu sistemi bir adm ileri gtrmek.

Giderek kalitesi artan ve retim zaman den demolar elde etmek istiyorsak, kullanabileceimiz iki farkl bak as var.
nceki demolardan hangi kodu kullanp bu adm aabilirim.
Bu adm nasl zersem sonraki demolarma yardmc olur.

Plan yapmann her zaman ileriye ynelik olduunu dnrsek, ilk yntemin sakat olduunu fark edebiliriz. Bu yzden izlememiz gereken yntem ikincisi.

[b]DEMO MOTORU[/b]

ncelikle hedefimizi bir tek demo bitirme iinden biraz teye koyuyoruz. Sayesinde farkl farkl demolar yapabileceimiz bir altyap hazrlamalyz. Demo retimini sfrdan kodlanan projeler yerine, hazr rutinlerin birletirilmesi iine evirmemiz gerekiyor. te bu rutinleri topladmz sisteme demo motoru adn vereceiz.

Demo motoruna, bir demonun retimi esnasnda anahtar ileri yapmamz salayacak bir ktphane gzyle bakabiliriz. Bu ktphaneyi byk ihtimalle sadece kendimiz kullanacamz iin tasarmn gnlmzce yapmakta zgrz. Ama yine de gz nnde bulundurmamz gereken baz eyler var.

ncelikle yapacamz ey olan demolar tanmlayalm. Amacmz gerek zamanl olarak alacak, grntnn algoritmik olarak retilecei bir animasyon hazrlamak ve bu animasyonun stne bir mzik eklemek. Mzik, standart bir demoda gerek zamanl hesaplanmayaca iin en az dert etmemiz gereken ksm. Dolaysyla motorumuzun asl amac, izimleri yapmamza ve grntleri oluturmamza yardmc olmak.

Motorumuzu bu karmlar erevesinde e ayracaz:
[b]izim iin kullanlacak bellein (framebuffer) oluturulmas ve ynetilmesi.
Animasyonun ak kontrol (timeline).
izim ilemlerini kolaylatracak bir alt ktphane (renderer).[/b]

Bu ksmlar iinin hakkyla halleden ve grevleri ile ilgili geriye i brakmayan kodlar hazrladmzda motorumuz bitmi olacak. Bu kodlar daha sonra sadece motoru gelitirmek iin elleyeceiz. Demolar ise srtlarn demo motoruna yasladklar iin sorun karmadan retilebilecekler.

[b]Framebuffer[/b]

Framebuffer ekranda izilecek piksellerle temasa geebileceimiz son yer. Bu bellein tanmlanmas, oluturulmas ve ynetilmesini altmz platforma gre iletim sistemine brakabilir ya da elimizle kontrol edebiliriz. lkini yaptmz varsaysak bile, rnein Windows altnda bir OpenGL framebuffer oluturuyor olsak bile, yazmamz gereken satrlarca kod vardr.

Eer deneysel taklmak gibi bir amacmz yoksa, yazacamz her demoda ayn tipte (32bit renk, 16bit derinlik vs.) bir bellek kullanacaz. Haliyle, bu kodu her seferinde batan yazmamz anlamsz. Bir pencere oluturup onu bir framebuffera balayan bir fonksiyon yazmak ve bu fonksiyonu her demonun banda armak i ykn hafifletecektir. in alt dzey ksmyla ilgili yaplacak her ii aadaki rnekteki gibi birka fonksiyona indirgersek mrmzden birka yl kazanabiliriz.
[b]
// Demonun banda.
Framebuffer::Create(640, 480, BufferType::DoubleBuffer) ;

// Her frame sonunda.
Framebuffer::Swap() ;

Timeline
[/b]
Demonuzda tm zamanlama ilerini her framede bir artrdnz bir tamsay zerinden yapabilirsiniz. stediiniz hz elde edip baka bir bilgisayarda yaptnz eyi denediinizde, elde edeceiniz ey sadece hsran olacaktr.

Eer donanm kesin kurallarla tanmlanm bir platformda almyorsak, framelerin farkl konfigrasyonlarda farkl sreler alacan bilmemiz gerek. Dahas tek konfigrasyonda bile tm demo boyunca sabit bir frame hz hayalleri kurmayalm.

Yapmamz gereken, tm zamanlama ilerini sabit bir saat kaynana gre senkronlamak ve elle tuttuumuz sayalardan medet ummamak. Bunun iin, bu saydaki derleme yazsnda bulunan Timer gibi bir snf kullanabiliriz.

Geriye sadece belli iki sre aralnda belli partlar altran fonksiyonlar armak kalyor. Bunun iin her frame banda, demo banda balattmz sayacmza bakp hangi partlar izmemiz gerektiini anlamalyz. En basit yntem tabi ki yle bir ey:
[b]
if(sure >=  5.0f && sure <= 12.0f) GirisParti() ;
if(sure >= 11.2f && sure <= 16.6f) Gecis1() ;
...
[/b]
Aslnda bu yntem gayet de ie yaryor ama ileri biraz daha kolaylatrabiliriz. Tm partlarn fonksiyon adreslerini, partlarn balang ve biti sreleriyle birlikte bir listede tutup, bu listeyi bir fonksiyona sayacn o anki deeriyle yollayabiliriz. Bu fonksiyonun amac sayaca bakp hangi partlarn almas gerektiini anlamak ve ilgili fonksiyonlar armak olacak.

Baz partlarn zaman araln negatif saylara ekip, rnein -1 zamanyla bunlarn almasn salayabiliriz. Bunu, loadingte yapmanz gerekenleri yaptracak bir ksayol olarak da dnebilirsiniz. Tabi ki birok if satr yazmak yerine ileri daha da kolaylatracak her trl yntem makbuldr.

Ayrca her partn kendi balang srelerine gre hangi konumda bulunduklarn bilmeleri iyi olabilir. Bunu, part fonksiyonlarn bu sreyi alacak ekilde tanmlayp, arldklar zaman demo sresi  part balangcn bu fonksiyona yollayabilirsiniz. Bu sayede gstereceiniz her trl animasyonun zamanlamasnn fps bamsz olmasn garantileyebilirsiniz.

Motorun timeline ksmnn hazrlanmas belki de en karmak iimiz olacak. Kavramlar oturtmak iin Flash gibi animasyon hazrlama programlarnn timeline kavramlarn inceleyebiliriz. Hazrlayacamz sistem bunlardan ok farkl olmayacak.

[b]Renderer[/b]

nanlmaz OpenGL, Direct3D vs. biliyoruz. Bu ktphaneleri kullanarak sper efektler hazrlyoruz. Pek gzel, pek ho. Tamamen farkl bir demoda, bambaka bir efekt iin yeniden dokuya izim yapmamz gerekti. Yani ekrana deil direk ekran kartnn bellek alanlarnda bir yere izeceiz. Ne yapyoruz peki? Eski koddan alp aynen kopyala yaptr. Sonra uymayan deiken isimlerini dzeltelim. Denedik, almad. Farkl bir doku tipi kullanmz, farkl bir izim modundayz. Neleri deitirmemiz lazm? Hmm, tamam oldu gibi. O da nesi? Farkl znrlk olduu iin tm oranlama hesaplar yanl!

OpenGL, Direct3D gibi ktphaneler ekran kartnn en temel zelliklerini kullanmanz salayan son derece alt dzey ktphanelerdir. glBegin(GL_TRIANGLES)larla, d3dDevice->SetTransform(D3DTS_WORLD, &matrix)lerle demo yazmaya almann, kanmca tamamem assembly kullanmaktan ok fark yoktur.

Bir obje evirme ii iin Direct3Dde  fonksiyon, Ekrana bir sprite izmek iin OpenGLde ondan fazla fonksiyon armak abesliktir. Bu ktphaneler zaten kendilerini olduk olmadk yerlerde armayacanz dncesi ile tasarlanmlardr. Size sunduu fonksiyonlarn amac kendi grafik ktphanenizin yap talarn oluturmaktr.

Dolaysyla bu alt dzey ktphaneleri daha verimli kullanmanz salayacak, onlar wrap edecek bir st dzey sistem tasarlamalsnz. Bu sistem de en basit ekilde birok global fonksiyondan oluan basit bir ktphane olacak.

Bu ktphanenin ana ilevi, demolarnz yazarken sk kullanacanz izim ilemlerini size tek fonksiyonla salamak olacak. Bunun yan sra doku, obje gibi sk kullanacanz tipleri tanmlamak da yararl olacaktr.
[b]
DrawSprite(logo, logoCercevesi) ;
Rotate(5.0f * time, 0.0f, 1.0f, 0.0f) ;
RenderState state = Renderer::Texture | Renderer::DepthTest ;
DrawMesh(kup, state) ;
[/b]

Motorun bu ksm, grafik programlama yapacanz belki de yegane yer olacak. izim ktphanelerinin size sunduu imkanlarn dna kmamak iin hibir sebebiniz olmayacak. Kendi renk snflarnz oluturabilir, bunlarn kendi aralarnda ilgin birleme kurallarn belirleyebilirsiniz. Mesh maniplasyonundan balayp dokular zerinde grnt ileme gibi ufuklara yelken aabilirsiniz.

[b]Demo Motoru zerine Son Szler[/b]

Eer bu  ana ksm hakkyla bitirip yanna ek ktphanelerle mzik almay da eklerseniz ortalamann epey zerinde bir demo sistemine sahip olacaksnz. Bu sistemi kullanarak yaptnz demolar, sfrdan kodlanan demolardan ok daha az zaman alacaktr. Dahas iin teknik ayrntlar yerine direk demoya odaklanacanz iin ortaya kacak rnler de daha kaliteli olacaklardr.

Demo motoru bir kez yazp lene kadar kullanacanz bir sistem deildir. Daha dorusu, hibir sistemin tm zamanlara uygun olma gibi bir zellii olamaz. Siz kendinizi gelitirdike motorunuzu da gelitirecek; daha hzl, daha esnek ve daha gl hale getireceksiniz. zellikle renderer diye bahsettiimiz ksm zerinde belki demolar kadar vakit harcamanz gerekebilir. Siz tam kvamnda bir izim ktphanesi yazsanz bile, teknoloji sizden hzl gidecei iin bu ksm yenileme ihtiyac duyacaksnz. Ama tecrbelerim ile syleyebilirim ki; yeni bir demoda, hem motora hem demoya ayracanz toplam sre, ilk demonuz iin harcadnz sreyle kyaslanamayacak kadar ksa olacak.

Demoscenede coder olmayan (mzisyen, artist vb.) arkadalarda bazen yle bir nyargya rastlyorum. Farkl iki rnde ayn kodu kullanmay ho karlamyorlar. Bu sanrm code reuse ve effect recycling kavramlarnn kartrlmasndan kaynaklanyor.

Effect recycling, yani bir efekti stp stp izleyenlere sunma, PC de iinde olmak zere her trl platformda grlebilecek bir olay. Bunu bir part iki farkl demoda kullanmak olarak da grebiliriz.

Code reuse, yazlan kodun benzer amalar iin tekrar tekrar kullanm ise, demo motoru yazmann ta kendisidir. Bu i kesinlikle nceki projelerden kod kopyalayp yaptrmak deildir. Aksine kopyala yaptrmaktan kanmak iin yeniden kullanabilir, tm sistemler tasarlama sorunudur. Yazlm gibi mhendislik alanlarnda yeniden kullanlabilirlik, bir rnde hedeflenen zelliklerden biri; yeniden kullanlabilir rn tasarlayabilmek ise bir mhendislik yetenei olarak kabul edilir.

Karlatnz bir problemin zmn, benzer tm problemlerde ie yarayabilecek ekilde gelitirmek ou zaman kolay deildir. Yeniden kullanlabilirlik her ne kadar seri retim iin art olsa da, rn boyu ve verimliliini olumsuz ynde etkileyen bir etmendir. Bir demo sistemi tasarlamak bile, terazinin dengesini kararl noktada tutabilme yeteneini olduka gelitirecektir.

Yeniden kullanlabilir kod yazabilmek bir codern elde etmesi gereken vasflardan biri olsa da, demo sistemini koddan bamsz hale getirmek de mmkndr. Lakin bunlardan bir sonraki sayda bahsedeceiz. Seri Demo retimi 2  Demomakerlarda grmek zere, esen kaln efendim.
