Bu sayfadaki yazılar
Sayfanın metni
Sayfa 106
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?
Klavyeyle gezinmek için ← ve → tuşları.
Sayfa 107
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.