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.