Bu sayfadaki yazılar
Sayfanın metni
Sayfa 113
Eğer kendimizi canlılarla sınırlandırmaz isek; eklem seçimi, hareketlerdeki hızlar vs. konularda daha fazla esneklik elde ediyoruz. Bu alanda gerçekten güzel örnekler görmek istiyorsanız, Portal Process'in demolarını izleyip robotların hareketlerini inceleyin.
Demoya artı kazandırabilecek bir diğer unsur da fizik efektleri. Tabi fizik dediğimiz zaman bir çok efekt akla gelebilir, ama burada bahsettiğim (ve asıl zorluğu içeren) objeler arasındaki çarpışmalar, yerçekimi vb. kodlar. Demolar zaman tabanlı olduğu için (her framede saate bakarak ekranda gösterilen şeyleri hesapladığımız için) fizik kodlarını ayrı işlemlerden geçirmek gerekiyor. Demonun geri kalanı fps bağımsız olsa bile, kuvvet veya hız hesaplarında fps'yi dikkate almak ve gerekirse belli değerlerde sabitlemek gerekiyor.
Çarpışmalardaki bir diğer zorluk da objelerin yapıları karışıklaştığında ortaya çıkıyor. Küplerin yahut kürelerin çarpışmalarını kontrol etmek, daha karışık objelerin çarpışmalarını kontrol etmekten nispeten daha kolay oluyor. Ama zaten demolarda çarpışan küpler ya da sallanan zincirlerden daha karışık efektler görmedim. Yapılmışlar arasında en iyilerini Fairlight demolarını tarayarak kolayca bulabilirsiniz.
Sonuç
Her şeyi özetlemek gerekirse, bir PC demosunu kod açısından değerlendirirken şu noktaların kesinlikle ele alınması gerekiyor:
-Windows birden fazla programın aynı anda çalıştığı bir platformdur ve demolar, çizim harici işlemlerinde CPU'yu diğer programla paylaşmak zorundadır. Bu yüzden rendering dışı efektlerin ve hesaplamaların hızlı çalışmaları için iyi optimize edilmeleri gerekiyor.
-Ekrana yapılan çizimler ayrı bir işlemci ile yapılıyor. Basılan poligon sayısı çok nadir durumlarda kısıtlayıcı bir unsur. Fakat bunun üstesinden gelmenin yolları mevcut (coder tamamen GPU ve kütüphanelere bağlı değil). Ayrıca coderların ekrandaki piksellere direk müdahalesi oldukça zor ve mümkün olduğu durumlarda oldukça yavaş.
-Ekran kartlarının sunduğu temel işlevler üzerinde deneysel takılmak pek mümkün değil. Sonuçlar karttan karta, hatta aynı kartın sürücüsünden sürücüsüne değişebilir. Bu yüzden ekran kartlarının hardware özelliklerine bağlı kalmamaları için coderlara shader programlama imkanı sunulmuş durumda.
-64k introlarda amaç 64k'ya sığdığı kadar bilgi doldurmak değil, büyük bir demoyu 64k limitinde yapabilmek. Küçük boyutlarda çalışmak PC programlamadaki en büyük zorluklardan biri.
-Demo, sadece ekrana basılan nesnelerden ibaret değil. Demodaki nesnelerin animasyonları, fiziksel olaylar, zamanlama, geçişler, uyumluluk (ki PC'de oldukça önemli bir konu) ve çökmeyen demolar yazabilmek de coderın yeteneklerine bağlı.
-Bir demoda kod her zaman ön planda olmayabilir. Bir hikaye anlatan ya da iyi bir tasarıma sahip demolarda kod halen yukarıdaki kriterleri gizlice sağlıyor olabilir. Atraksiyondan uzak sağlam bir demo motoru ile bol efekt ve atraksiyonlu ama uyumluluğu düşük, zar zor çökmeden durabilen bir demo kodu arasındaki seçim size kalmış.
Klavyeyle gezinmek için ← ve → tuşları.
Sayfa 112
İlk coderın yaptığı 64k intro ekranda birkaç yazı basıp, bunu bir kaç efektle desteklemekle sınırlı kalacakken; ikinci coderın yaptığı 64k intro ise sadece benzer elementlerle (hep küpler, hep gezegenler gibi) sınırlı kalacak ve zaten düzinelercesi bulunan vasat introlar arasında yerini alacaktır.
Şimdi bir çoğunuz "İyi coder, bu ikisi arasında uyumlu bir denge sağlayanıdır." benzeri bir laf etmemi bekliyor ama yanılıyorsunuz. :) Bundan daha iyi bir yol, tüm kodu mümkün olduğunca ortak rutinler üstünde yazıp, bu rutinlerin işleyişini az sayıda parametre ile radikal bir biçimde değiştirmektir. Örneğin dalga üreten bir kodun amacı softsynth için sıkıştırılmış sampleları açmak iken, ufak bir uyarı ile birden texture generator haline gelebilir. (Çok abarttım biliyorum :) ama o kadar da saçma bir fikir değil.) Eğer introda sürekli yenilenen bir akış, intronun farklı yerlerinde farklı sesler, farklı efektlerle karşılaşıyorsanız; bir başka deyişle bu ürüne intro dememizin tek sebebi 64kb'tan küçük olması ise, o zaman izlediğiniz şey gerçekten takdir edilesi bir demo olacaktır, ki sayıları belki gerçekten de iki elin parmaklarını geçmiyordur.
Bu anlattıklarım küçük boyutlarda demolar yapmanın ana unsurları. Lafta hepsi kolay anlaşılır ve yapılabilir gibi gözüküyor ama ben kendim tüm bunları hesaba katan ciddi bir 64k projesine başlamayı düşünsem, önce bir fincan kahve içer, sonra bu fikrimi tekrar düşünürdüm sanırım. :) Zaten çok basit denmesine rağmen fr08'i hala en iyi Windows 64k demosu yapan şey de bitmiş ve çalışıyor olarak karşımızda durması. (Heaven Seven'ı tenzih ederim.) İki demo da halen bir çok açıdan geçilebilmiş değil.
PC Coding Sadece Çizim ve Düşük Boyutlardan mı İbaret?
Bir PC demosunun yapımında gerek çizim, gerekse küçük boyutlar elde etme konusunda izlenilen genel yollardan, karşılaşılan zorluklardan vs. bahsettik. Fakat bir demoyu bir diğerinden farklı kılan şey aslında bunlarla sınırlı değil. Demoda kodun bu yönlerini destekleyecek bazı başka unsurlar olabilir.
Örneğin bazı demolarda iskelet animasyonlar bulunmakta. Motion capture ile elde edilmiş hareketleri saymazsak, (ki coderın buradaki görevi gerçekten soruşturulur) yumuşak şekilde ilerleyen, ayrıntılı ve fazla tekrarı olmayan insan, robot vs. hareketleri de demonun koduna verilecek değerlendirme notunu artırıcı öğelerden.
Hareket esnasında oynayan tüm eklemlerin tek ya da iki yöndeki değerlerinin her süre değeri için hesaplanması gerekiyor. Eğer hareket eden cisimdeki eklem sayısı çok fazlaysa, bu hareketlerle uğraşmak gerçekten zorlayıcı olabilir. Özellikle hareket ettirilen cisim insansa, aldığınız sonuçta bir gerçekçilik payı da arayacağınız için işiniz daha da zorlaşıyor. Elde edilen insan hareketi saniyede bir tekrarlayan kol ve bacak sallama halinde ise, hareketin üstünde çok fazla uğraşılmamış yahut hareket motorunun henüz tam pişmemiş olduğunu anlıyoruz. Ancak The Popular Demo/Farbrausch'taki gibi ayrıntılı ve uzun insan hareketlerini oluşturabilmenin büyük uğraşlar gerektirdiğini bilmeliyiz.