Bu sayfadaki yazılar
Sayfanın metni
Sayfa 96
Bir coder olarak ilk demonuzu yapmak istediniz. Müzik ve grafikleri hazırlayacak birilerini buldunuz. Onlar uğraşırken siz OpenGL, Direct3D her neyse öğrendiniz. Sonra gelen materyallere göre bir tasarım belirlendi ve bunu hayata geçirmeye başladınız. Partları kodladınız. Beğenmediniz, baştan kodladınız. Gündüz vakti devam edesiniz gelmedi, parti tarihini hatırlayıp geceleri kodladınız. Demonuz, yola çıkma vaktinden ancak birkaç saat önce istediğiniz kıvama ulaştı.
Demonuzu partiye götürdünüz ve herkese izlettiniz. Daha dün kimse sizi duymamıştı, bugün herkes o demoyu kimin yaptığını merak ediyordu.
Bir sonraki partinin tarihini öğrenince “Bir kez daha mı?” diye sordunuz kendinize. İlk demonuzu yaparken ne kadar zaman alacağını kestirememiştiniz. Artık hem nelerden vazgeçmeniz gerektiğini biliyor hem de daha yoğun bir hayat yaşıyordunuz. Mümkün değil baştan benzer bir kod hazırlayamazdınız. Belki ileride devam ederdiniz…
7DX ve Nightshift’e ilgi çekici bir demoyla katılıp daha sonra bir daha adına rastlamadığımız coderların yaşadıkları ve düşündükleri az çok bunlar diye tahmin ediyorum. Bir demoyu yapmak bile o kadar çaba isterken, yabancı gruplar bir senede nasıl üç dört demo birden çıkarıyorlar? İşin içinde uzun zamandır olsalar bile, bir demoyu baştan sonra tekrar yazmaları gerçekten çok zamanlarını alacaktır.
Bu kısıtlama coderın yeteneklerini de aşıp, fiziksel bir sınır haline gelebilir. Yani gece gündüz hatasız çalışsanız bile, o kalitede ürünler o kadar kısa zamanda sıfırdan nasıl hazırlanır? Bu yazıda bunun cevabını arayacağız.
Her şeyden önce ufak bir not: Yazıda önereceğim yöntemlerin hepsini kullanmadım ama tamamı uygulama planımın içinde. O yüzden benzer fikirler ya da eleştirileriniz olursa paylaşmanız benim açımdan da faydalı olacaktır. Belki de birkaç sene sonra “bu yöntemler nerede işe yaradı nerede yaramadı” ekseninde bir başka yazı yazarım.
SERİ ÜRETİM
Seri üretim (ya da rapid production) benzer projelerin ortak yönlerini kullanarak bunları daha kısa sürelerde bitirme işidir. Amacımız hazırlayacağımız demoların aldıkları zamanı giderek düşürmek ve elde ettiğimiz bu ek zamanı kendimizi geliştirmek için kullanmak olacağı için, seri üretimin demolarda nasıl uygulanabileceğini bilmek istiyoruz.
İlk demomuz için altı ay uğraşmış olabiliriz, bu her demoya aynı süreyi adayacağımız anlamına gelmez. En azından bir altı ay daha uğraşırsak, yeni demomuzun ilkini fersah fersah aşmış olması gerekir. Ya da aynı kalitede bir başka demoyu bir ay içinde bir diğer partiye yetiştirebilmeliyiz.
Aslında bahsedeceğim şey tecrübeli olanlarınızın bildiği gibi yeniden kullanım (reuse). Tabii ki bunun, ilk demonun kodunda bir iki parametreyi değiştirip ikinci bir demo yapmayla alakası olmayacak. Asıl hedefimiz, sıfırdan bir sistem tasarlayıp, her demoda bu sistemi bir adım ileri götürmek.
Giderek kalitesi artan ve üretim zamanı düşen demolar elde etmek istiyorsak, kullanabileceğimiz iki farklı bakış açısı var.
Klavyeyle gezinmek için ← ve → tuşları.
Sayfa 97
Önceki demolardan hangi kodu kullanıp bu adımı aşabilirim.
Bu adımı nasıl çözersem sonraki demolarıma yardımcı olur.
Plan yapmanın her zaman ileriye yönelik olduğunu düşünürsek, ilk yöntemin sakat olduğunu fark edebiliriz. Bu yüzden izlememiz gereken yöntem ikincisi.
DEMO MOTORU
Öncelikle hedefimizi bir tek demo bitirme işinden biraz öteye koyuyoruz. Sayesinde farklı farklı demolar yapabileceğimiz bir altyapı hazırlamalıyız. Demo üretimini sıfırdan kodlanan projeler yerine, hazır rutinlerin birleştirilmesi işine çevirmemiz gerekiyor. İşte bu rutinleri topladığımız sisteme demo motoru adını vereceğiz.
Demo motoruna, bir demonun üretimi esnasında anahtar işleri yapmamızı sağlayacak bir kütüphane gözüyle bakabiliriz. Bu kütüphaneyi büyük ihtimalle sadece kendimiz kullanacağımız için tasarımını gönlümüzce yapmakta özgürüz. Ama yine de göz önünde bulundurmamız gereken bazı şeyler var.
Öncelikle yapacağımız şey olan demoları tanımlayalım. Amacımız gerçek zamanlı olarak çalışacak, görüntünün algoritmik olarak üretileceği bir animasyon hazırlamak ve bu animasyonun üstüne bir müzik eklemek. Müzik, standart bir demoda gerçek zamanlı hesaplanmayacağı için en az dert etmemiz gereken kısım. Dolayısıyla motorumuzun asıl amacı, çizimleri yapmamıza ve görüntüleri oluşturmamıza yardımcı olmak.
Motorumuzu bu çıkarımlar çerçevesinde üçe ayıracağız:
Çizim için kullanılacak belleğin (framebuffer) oluşturulması ve yönetilmesi.
Animasyonun akış kontrolü (timeline).
Çizim işlemlerini kolaylaştıracak bir alt kütüphane (renderer).
Bu kısımları işinin hakkıyla halleden ve görevleri ile ilgili geriye iş bırakmayan kodlar hazırladığımızda motorumuz bitmiş olacak. Bu kodları daha sonra sadece motoru geliştirmek için elleyeceğiz. Demolar ise sırtlarını demo motoruna yasladıkları için sorun çıkarmadan üretilebilecekler.
Framebuffer
Framebuffer ekranda çizilecek piksellerle temasa geçebileceğimiz son yer. Bu belleğin tanımlanması, oluşturulması ve yönetilmesini çalıştığımız platforma göre işletim sistemine bırakabilir ya da elimizle kontrol edebiliriz. İlkini yaptığımızı varsaysak bile, örneğin Windows altında bir OpenGL framebuffer'ı oluşturuyor olsak bile, yazmamız gereken satırlarca kod vardır.
Eğer deneysel takılmak gibi bir amacımız yoksa, yazacağımız her demoda aynı tipte (32bit renk, 16bit derinlik vs.) bir bellek kullanacağız. Haliyle, bu kodu her seferinde baştan yazmamız anlamsız. Bir pencere oluşturup onu bir framebuffer'a bağlayan bir fonksiyon yazmak ve bu fonksiyonu her demonun başında çağırmak iş yükünü hafifletecektir. İşin alt düzey kısmıyla ilgili yapılacak her işi aşağıdaki örnekteki gibi birkaç fonksiyona indirgersek ömrümüzden birkaç yıl kazanabiliriz.