1998 Sonrası

• Grafik ve çizim
• Demo sahnesi

Yeni Bir Çağ

Windows 95'in çıkışı PC'de grafik programlama açısından fazla bir yenilik getirmemişti. Çünkü grafik arabirim üzerinde çalışan programlar, ekran ve ses kartlarına doğrudan erişime sahip DOS programlarından daha hızlı olamıyordu. Microsoft'un bu sorunu çözmek için hazırladığı kütüphane DirectX de, istenen performansı vermekte zorluklar yaşıyordu. Programcılar 3 sene sonra daha hızlı bir platform olan Windows 98 ve DirectX'in daha hızlı sürümleriyle tanıştılar. DOS coderlarının kendilerinin gerçekleştirdiği matris çevirimleri ve poligon doldurma rutinleri artık DirectX'e bırakılmıştı. Fakat bu işlemler yine de ana işlemci üzerinden yapılıyor (poligon doldurma haricinde) ve aynı anda birden çok programı çalıştıran bu platform üzerinde çalışmak, DOS programlamaya nazaran çok fazla avantaj sağlamıyordu.

Fakat PC demoscene'in çehresi 1999'da GeForce256 ekran kartlarının çıkmasıyla tamamen değişti. Bu kartın özelliği matris çevrimi ve ışıklandırma gibi zaman alan işlemlerin, ekran kartının üzerinde bulunan ek bir işlemci (GPU) sayesinde paralel bir mantıkla yapılabilmesiydi. Başka bir deyişle grafik işlemleri Windows altında çalışan diğer programlardan etkilenmeden hızlıca yapılabiliyordu. Bu yenilik multitasking olmasına rağmen Windows'u, DOS ve Amiga ile yarışabilir seviyeye getirecekti.

Bu dönemde yayınlanmış en önemli demo olan Kasparov/Elitegroup eski tür ekran kartları için yazılmış bir demodur. Geometri ve çizim kodları demo coderları tarafından hazırlandı. Kasparov, uzun ve ayrıntılı 3D sahnelerden (flybye) ibaret. PC üzerinde takdir etmeniz gereken en son basit flybye Kasparov'dur. Daha sonraki yıllarda çıkan ve basit geometrileri çizmekten ibaret demoların kod açısından çok fazla bir şey ifade etmediğini eminim hepiniz biliyorsunuzdur.

Ertesi yıl, yani 2000'de, daha zamanın 3D motorları GeForce256'yı zorlamaya başlamadan, o kartı ikiye katlayan GeForce2 piyasaya sürüldü. Bu yıllarda PC coderları ekran kartı teknolojisinin gerisinde kaldıkları için suçlanacaklardı. Bununla beraber demo grupları Haujobb'ın önderliğinde, kodu arka plana iten "dizayn" demoları çıkarmaya başladı. Ekranda istenildiği kadar poligon basılabildiği için, bu yıla damgasını 64k demolar vurdu, ama onlardan yazının ilerleyen kısmında bahsedeceğiz. 2000 ayrıca son önemli software demosu olan Spot/Exceed'in yayınlandığı yıl olması itibari ile de önemini koruyor.

PC'de 3D Programlamanın Oluru Nedir?

PC'de demo programlama 2000'den bu yana çok fazla değişmedi. Demolar bir kaç sene içinde ekran kartlarını zorlamaya başladı ve zorlukların üstesinden gelmek için yeni arayışlar başladı. Bu zorlukları anlamak için biraz da detaylardan bahsedelim.

Ekran kartı ekrana bir poligon basarken, öncelikle aldığı poligonun köşelerini belli matris hesapları ile değiştirir, normal vektörleri yardımı ile ışıklandırma hesapları yapar ve sonuç olarak her köşenin ekranda hangi piksele geldiği ve hangi renkle çizilmesi gerektiğine karar verir. Bu işlemlerin tümüne "vertex işlemleri" adı verilir. Bu işlemlerde coder oldukça geniş bir özgürlüğe sahiptir. Poligonun köşelerini, renklerini kendisi belirler, isterse kendi matris çevrimlerini kendisi yapar, objelerin köşelerini istediği gibi oynayarak onları istediği hale getirebilir. İstediği yere ışıkları koyarak objelerin nasıl görünmesi gerektiğine az çok karar verebilir. PC demolarında göreceğiniz renk oyunları, eğilip büzülen cisimler vs. coderın kendi ürünüdür.

Bu tür efektlerdeki tek sorun çok fazla poligon kullanıldığındaki yavaşlamadır. Bunun üstesinden gelmek için objeleri ekran kartının hafızasına yerleştirme yolu izlenebilir. Bu yolun artısı büyük objelerin ana bellekten ekran kartına aktarımı her framede yapılmadığı için daha hızlı olmasıdır. Eksisi ise ekran kartının belleğine doğrudan erişimin bulunmamasıdır. Yani ekran kartına alınan bir objenin sonradan değiştirilmesi mümkün değildir. Kolayca örneklemek gerekirse çok fazla poligonlu bir şehri ekranda durur halde basıp etrafında uçan bir kamerayla dolaşmak kolaydır. Lakin hem bu şehri basıp hem de binaların sağa sola eğilmesini sağlamak zordur.

İlk bakışta tüm çizim işlemlerini ekran kartı yapıyor olduğu için coderın yapabileceği bir şey olmadığını düşünebiliriz. Yani eğilip bükülebilen binalara sahip şehri gören insan, bunu başaranın ekran kartı olduğunu zannedecektir. Fakat coderın bunu başarması için software renderingte de gereken bazı optimizasyonlara gitmesi gerekmektedir. Neler yapabileceğine bir örnek vermek gerekirsek, eğilip bükülen her binayı her zaman içine alacak prizmalara, kendisi matris çevrimleri uygulayarak ekranda görünüp görünmediğini hesaplayabilir. Normalde bunu ekran kartı da yapmaktadır fakat binanın her poligonu için ayrı bir test uygular. Coder bu tür bir optimizasyonla binanın tümünün birden test edilmesini sağlayabilir. Tabii ki bu çok basit bir yordamdır ve sadece ekranın içinde olup olmaması değil, diğer binaların arkasına düşüp düşmemesini de test edecek şekilde geliştirilebilir. Hatta coder, bu prizmaların çevrim işlemlerini prizmaları ekrana çizdirmeden, ekran kartına yaptırmayı deneyebilir ama bu yöntemin pek de kolay olacağını zannetmiyorum.

Demek istediğim bir PC demosunda ekranda yüz binlerce poligon basılabilmesinin tek mimarı ekran kartları ve hızlı konfigürasyonlar değildir. Kullanılan grafik kütüphanesinde bulunmayan ve o demo için özel teknikler geliştirmek coderın elindedir. Piyasada bu işlemleri gerçekleştirebilen hazır kütüphaneler de bulunmaktadır, fakat genel amaçlı oldukları için hem daha yavaştırlar, hem de kodda çok fazla yer kaplarlar.

Şimdi ekran kartının yaptığı işlere geri dönelim. Her köşenin hangi piksele geldiği bulunduktan ve köşelerin renkleri belirlendikten sonra, bu köşeler arasındaki pikseller ekran kartı tarafından doldurulur. Eğer düz bir doldurma istenmişse her piksel son köşenin rengine sahip olur, eğer yumuşak bir doldurma istenmişse piksel bütün köşelerin ağırlıklı bir ortalamasıyla elde edilen renge sahip olur. Daha sonra bu renk, isteğe bağlı bir veya daha fazla dokunun gerekli renkleri ile çarpılabilir. Bu işlemlerin tümüne de "piksel işlemleri" adı verilir.

Piksel işlemlerinin en önemli özelliği, coderın bu işlemler üzerinde hemen hemen hiçbir esnekliğe sahip olmamasıdır. Standart yöntem ile sadece poligon doldurma tipini (düz-yumuşak) ve dokuları seçebilir. Fakat başka türlü, ekranda herhangi bir pikselin hangi renge sahip olacağına gönlünce karar veremez. PC demolarında 2D'nin ölmesinin ana sebebi budur. Coder, plazma ya da blur gibi tamamen 2D doğaya sahip işlemleri poligonlar ve dokularla 3D'de taklit etmeye çalışır. İlk akla gelen yöntem, her piksel için bir piksel büyüklüğe sahip olacak bir kare poligon belirleyip bu poligonların rengini değiştirmek olabilir. Fakat yüksek bir çözünürlükte bunu yapmak oldukça zordur. Başarılırsa bile o framede daha fazla şey yapmak için süre kalacağını sanmıyorum.

Kısacası hardware rendered demolarda 2D efektler, aslında tüm piksel efektleri zordur. En uçuk örnekle, animasyon kullanmadan kaliteli Mandelbrot fraktalları çizebilmek oldukça takdir edilecek bir şeydir. (Bu yüzden zaten 3D fraktallar daha yaygındır.) Ayrıca piksellere erişiminiz olmadığı için, PC demolarında hem vektör grafikler kullanıp, hem de göze oldukça hitap edecek görüntüler almak zordur. 2004 yılında yayınlanan We Cell/Kewlers, ekran kartının sadece 2D resim çizmeye izin veren accumulation bufferını kullanarak 3D'den uzak durmuş ve ferah görüntüler sunmuştur. Bir başka deyişe %100 spritelardan oluşan bir demodur.

Piksel işlemleri hardware renderingte bu kadar zorsa coderlar neden hala bu yolda ısrar etmektedirler? Günümüzde yazılabilecek en optimize, en hızlı poligon basma rutininin bile, ekran kartında donanım olarak bulunan işlemleri geçmesi mümkün görünmemektedir. Ayrıca CPU'dan bağımsız çalıştığı için, ekran kartlarını kullanmamak platformdan yarım verim almak anlamına gelecektir. Ama maalesef ekran kartları da codera maksimum esnekliği sağlamamakta. Bu sorunu çözmeye yardımcı olmak için programlanabilir ekran kartları piyasaya çıkmıştır.

Back to Oldskool!

Programcının yazdığı kodlarla nasıl çalışacağını belirlediği ekran kartları ilk olarak 2001 yılında gözükmeye başladı. Fakat o yıllarda yapabildikleri şeyler çok fazla değildi. Şimdi neler yapabildiğini ve ilerde neler yapabileceğini anlamak için tekrar detayları konuşalım.

Ekran kartlarındaki vertex ve piksel işlemlerinden ve bu işlemlere coderın ne kadar hakim olduğundan bahsettik. Coderdan monitöre giden yolda ilk karşımıza çıkan vertex işlemleri idi. Bunlar, gayet basit geometrik işlemlerdi ve coderın istediği çıktıya uygun vertexleri hazırlaması kolaydı. Ama kısıtlayıcı unsur bu vertex ve poligonların basılma hızı idi.

Yeni nesil ekran kartları, normal vertex işlemlerinin yanına bir de coderdan aldığı özel bir kod parçasını yerleştirerek "çizim borusundan" ilerleyen vertexlere, müdahale etme şansı tanıdı. Örneğin bir köşenin aldığı ışık belirlendikten sonra vertexi bu ışığa göre değiştirip bir tür serap efekti elde edebilirsiniz. Ya da bir dinozorun üzerindeki ayrıntılı deri bilgisini (tırtıklar yarıklar vs.) ekran kartı belleğine attıktan sonra bunu, derisiz ve düşük poligona sahip bir dinozorun üzerine yapıştırabilirsiniz. Yüksek poligon ama statik bir deri ve düşük poligon ama hareketli bir dinozor meshi ile yüksek poligon ve hareketli bir dinozor çizmeniz mümkün hale gelebilir. Buradaki en önemli nokta bu gibi kodları coderın tamamen kendisinin yazıp, ekran kartına işlenmek üzere yollaması. Bu kodlara "vertex shader" adı veriliyor.

Sonraki aşama olan piksel işlemlerinin de yanına "pixel shader" ya da "fragment shader"larınızı koyarak piksellerin nasıl basılacağını bir dereceye kadar programlayabilirsiniz. Bu sayede örneğin ayrıntılı gözükmesi için ayrıntılı bir meshte tuttuğunuz objeyi düşük poligonlu bir meshte tutup, daha sonra piksel shader'ınız ile ayrıntılı hale getirebilirsiniz (ışıklandırma, bump mapping gibi tekniklerle).

Shader'ların 2001'de ortaya çıktığından bahsettik, fakat yukarıda bahsettiğim örnekleri yapabilmek için daha fazlasını beklemek gerekti. Artık ekran kartı programlama önümüzde yeni bir ufuk gibi duruyor. Daha önceleri "GLSL" ya da "C for Graphics" gibi dillerle yazılan shader'lara artık Assembly desteğinin de gelmesi ile grafik programlama, efektleri tamamen coder'ın yazdığı eski günlere geri dönüyor. Geometrik çevrimler, poligon basma gibi işler ekran kartına bırakılıp grafik programlamaya yeni başlayanlara kolaylık sağlanırken, daha fazla esneklik isteyenlere de kendi shader'larını yazma ve yeni rendering teknikleri keşfetme olanağı sağlanıyor.

Şimdiye dek shader'ların kullanıldığı birçok demodaki shader özellikleri, daha önceden elde bulunan gereçlerle de (poligon + doku) yapılabilir gibi duruyor. Fakat geçen sene çıkan Fair Play to the Queen/Candela demosundaki metaball'ları, shader'lar ile yazılmış bir raytracer kullanmadan yapmak mümkün değil gibi gözüküyor. Ayrıca aramızda hırslı PC demo coder'ları varsa Plastic'in motoruna yaklaşmanın da başka türlü mümkün olmadığını söylemek istiyorum. :)

Şimdiye kadar ekrana yapılan çizimler için temel yöntemlerden ve bu yöntemlerin hangi aşamalarının ne derece zor/kolay olduğundan bahsettik. Esasına bakılırsa PC'de hız optimizasyonu çok da üzerinde durulan bir konu değil. Çünkü bugün yazdığınızda 20fps çalışan bir efekti, 60 fps çalıştırabilecek konfigürasyonların 2-3 yıl içinde türeyeceğine garanti gözüyle bakabiliriz. Ekran kartı belleklerinin bile çok üzerine çıkacak sayıda poligon basmak istemediğimiz sürece, çizimde hız optimizasyonu çok fazla önemli değil. Asıl hız problemi bu çizim öncesinde gerçekleştirdiğiniz hesaplamalarda beliriyor. Örneğin bir demoda ekranda yüzlerce küp dönerken bir yavaşlama fark ediyorsanız bunun sebebi, küplerin çiziminin yavaş olmasından değil, küplerin hareketlerini belirleyen kodun yavaş olmasından kaynaklanmaktadır.

Başka bir örnek olarak, bir metaball efektinde hız faktörü çizilen poligon sayısıyla çok az ilişkilidir. Esasında metaball'ları poligonlarla oluşturuyorsak, en önemli yavaşlatıcı faktör yapılan matematiksel hesapların detayındadır. Çok detaylı bir hesap çok kaliteli bir görüntü sunacakken oldukça yavaş olabilir. Tersi şekilde hızlı bir metaball efekti de belki kaliteden ödün verdiği için bu özelliğe sahip olmuş olabilir (Nested'dakiler gibi). (Aslında blobların çözünürlüğünün kübüyle orantılı sayıda işlem gerekmektedir.) İyi bir kodu kötüsünden ayıran özelliği, hız-kalite çarpımının daha yüksek olmasıdır (tüm platformlarda olduğu gibi).

64kb Herkese Yeter

Bir demoda kodun kalitesini belirleyen tek şeyin hız olmadığını öğrendik. PC'de hız konusunda coder'lar bir nebze rahat olduğu için boyut optimizasyonuna yöneldiler. Normal bir demo için kodun boyutu bir şey ifade etmediğinden, tüm bir demoyu eskiden olduğu gibi belli boyut limitleri içerisine sıkıştırmaya çalıştılar.

PC coder'larının yukarıda bahsettiğim boşluğu yaşadığı 2000 yılında, PC'de iki adet klasik 64k yayınlandı. Bunlardan ilki daha çok DOS ürünlerinin takipçisi ve tamamen software rendered olan Heaven Seven/Exceed. Bu 64k, tamamen asm ile yazılmış gerçek zamanlı bir raytracer'ı, tasarımı, müziği ve anlatılması güç ruhu ile sadece PC değil tüm platformların en iyi ürünlerinden biri. Diğer 64k ise, Kasparov'da imzası bulunan scener'ların da içinde bulunduğu tecrübeli coder ve müzisyenlerin çalışması olan The Product/Farbrausch.

Demolarda Spot'un bir devrin sonu, Kasparov'un sonraki devrin başlangıcı olması gibi; 64k'larda da Heaven Seven DOS introlarının sonu, The Product (fr08) Windows introlarının başlangıcı oldu. (Burada ilk ve son derken, release edilmekten çok akımların yönlerinden bahsediyoruz tabi ki.)

Peki kodu bu kadar küçük yapmanın yolları nelerdir? Kayıpsız sıkıştırma (yani dataları ve exenizi zipleme), sizi bir yere kadar götürebilir. Oradan sonra önünüzde iki seçenek bulunmaktadır.

Bu seçeneklerden ilki kayıplı sıkıştırmadır. Kayıplı sıkıştırma, sıkıştırılacak bilginin %100 geri dönüşülebilir olmadığı durumlarda uygulanabilir. Örneğin bir resmi kayıplı sıkıştırıp tekrar açtığınız vakit, resme benzer bir görüntü elde edebilirsiniz. Fakat exe içindeki opcodelara böyle bir sıkıştırma uygulamak mümkün değildir. Çünkü opcodelarda geri dönülen bilginin öncekiyle tamamen aynı olması gerekir.

Örneğin fr08'de tüm dokular, obje bilgileri ve ses sample'ları kayıplı sıkıştırma ile saklanmıştır. Bu bilgilerin orijinallerini, duyularla çok kolay yakalayamayacağımız yüksek frekanslarını "kaybederek" daha düşük boyutlara indirebiliriz. Bu konunun temelinde mühendislikte çok önemli bir alan olan Fourier teorisi yatmaktadır. Coder'ın kayıplı sıkıştırma ve tekrar geri açma kodu yazabilmesi için teoriye hakim olması gerekmez. Ama "Kaybedilen şey ne olacak?", "Bu bilgi ne kadar küçülecek?" gibi sorulara cevap verebilmesi için, teori hakkında biraz bilgi, biraz da deneyim sahibi olması gerekir.

Fakat coder'ların çoğu, kartlarını buna değil de, sonraki seçeneğe oynamaktadırlar. Bu diğer seçenek, bilgileri demonun başlangıcında (ya da gerekiyorsa gerçek zamanlı olarak) işe uygun algoritmalar sayesinde oluşturmaktır. Doruk noktasına demoscene ile ulaşan ve "procedural generation" denilen bu yordamda kod içinde bilgi değil, bilgiyi oluşturacak yöntemler tutulur. Örneğin işinize uygun bir obje oluşturucu yazdıktan sonra bu kodun ufak parametrelerini oynayıp, farklı objeler elde etmeniz mümkündür. Yahut benzer şekilde bir texture generator'ın parametrelerinde değişiklikler yapıp sayısız doku elde etmek mümkün olabilir.

Kayıplı sıkıştırma bu yöntemin örneklerinden biri gibi duruyor. Ama hem endüstride çok önemli bir yere sahip olduğu, hem de yıllardır geliştirildikten sonra artık kıvama geldiği için bu sonrakinden ayrı tuttum. İki yöntemi karşılaştırırsak; ilkinde konuya hakim olmak biraz zordur, ikincisinde ise algoritmaları coder'ın duruma uygun olarak kendisinin çıkarması gerekmektedir. Fakat bir çok 64k'da doku oluşturmaya yarayan Perlin Noise algoritması kullanılmaktadır. Eğer coder bu algoritmaya bir şeyler katmamışsa, bunu demodaki dokuların ya çok "bulutsal" ya da çok "tahtasal" olmasından anlayabilirsiniz.

Ses sıkıştırmada ise sesin dalga yapısı yüzünden ilk tercih (Fourier) çoğu zaman daha mantıklı. Ama yöntemin doğası yüzünden çok fazla frekansa sahip sample'ları kodu kabartmadan üretmek pek kolay değil. Örneğin insan sesini 64k içine sığdırmak için, Candytron/ Farbrausch'taki gibi tek tek heceleri sıkıştırıp sonra bunları birleştirme gibi yöntemlere gerek duyulur.

Bu yöntemlerin ne denli gerekli olduğunu anlamak için ufak bir kaç hesap yapalım. Örneğin elimizde 3000 üçgenli ve 1500 köşeli bir objemiz olsun. Eğer standart dışı herhangi bir yola girmezsek, tüm köşeler için 1500*3=4500 tane koordinata ve bu koordinatları tutmak için 4500*4byte=18000byte, yani 18kb alana ihtiyacımız bulunmakta. Daha bu sayıya üçgenlerin hangi köşelere sahip olduğu bilgisini eklemedik bile.

Ya da 400*250 24bit bir logomuz olsun. Tüm logo için 400*250*24bit=2400000bit yani 300kb alana ihtiyacımız olacak. Bu büyüklükteki bir logoyu bmp olarak kaydetseydik diskte bu kadar yer kaplayacaktı. Kendiniz bu büyüklükte çeşitli resimler bulup önce png (kayıpsız) sonra da jpg (kayıplı) sıkıştırarak deneyler yapabilir, sonuçların dosya boyları ve görüntü kalitelerini karşılaştırarak sıkıştırma yöntemleri hakkında fikir edinebilirsiniz.

Yukarıdaki iki örnekten anladığımız gibi :) ayrıntılı ve de girintisi çıkıntısı çok olan (yüksek frekanslara sahip) bir meshi 64k içine yerleştirmek çok kolay değil. Aynı şekilde, çok da büyük olmayan ve algoritmik olarak oluşturması imkansız olan resimleri (örneğin logoları) kayıptan ödün vermeden küçük boyutlara düşürmek marifet isteyen bir iş. Bir 64k'da bir logo gördüğümüzde, yahut bir 4k'da hareket eden bir robot gördüğümüzde, alanın çoğunun bu elemanlara gittiğini anlayabiliriz. Bu durumda intronun geri kalanına aslında çok daha az yer kaldığını kolayca çıkarabiliriz.

Tabi ki statik bilgileri sıkıştırarak-kendiniz oluşturarak da sadece bir yere kadar gidebilirsiniz. Çünkü geriye demonun motorunu, partların kodları vs. için de yer kalmalı. Ama bu kısımları da daha küçük tutmanın bir yolu var. Bu yolu iki analoji ile anlayalım.

Örneğin bir coder, demodaki her obje için farklı bir çizim rutini, her resim için ayrı ayrı alanlar belirtiyor, her dokunun oluşturulma kodu birbirinden farklı tutuyor ise o coder'ın başı çok ağrıyacaktır. Çünkü ufak bir intro oluşturması gerçekten zor gözükmektedir.

İkinci bir coder ise bunun tam tersini yapıyor, yani tüm objeleri hatta resimleri aynı rutin üzerinden basıyorsa, hatta abartıp dokuları da bu rutinle oluşturuyorsa (dokuya çizim yaparak) bu coder çok küçük introlar hazırlayabilir. Fakat introsu sürekli tekrarlardan ibaret olmakla suçlanacaktır. Intronun tamamındaki elementler birbirine benzediği için (tasarım amacıyla kasıtlı olarak yapılmamışsa) izleyicide olumlu etki bırakmayacaktır.

İ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.

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ış.

Bu yazı, PC demolarının kodlarını değerlendirmede kullanılacak anahtar noktaları sunmanın yanı sıra, PC coding için ciddi planları olanlara da dönmeleri gereken yönleri gösteren bir tavsiye kimliğine de sahip oldu. Takdir kısmı umarım yardımcı olmuştur. Tavsiye kısmını ise kendim bizzat uyarak sınayacağım :)