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