Sayfa 24

Gibi bir görüntü çıkacak. Yani belki bazı frame'lerde tam istediğimiz gibi gözükmeyecek yani hem task a'nin o saniyede ki hali ve hem de task b'nin o saniyede ki hali... ama.. bir nevi process'lere bölüm scheduling sistemi bunu yükten kurtaracak. Öbür türlü yaptığımızda belki de 40fps'lik olayımız aslında 20fps olacaktı.. Yani olayı bir nevi workcompression gibi düşünün. (bilenler için.. Pal görüntü gibi.. Odd fields - even fields... Her frame'de sadece ya odd field'lar gönderilir.. Ya da even... Ancak ve ancak ikisi bir olunca bir frame olur.. Ama birinci frame'in odd'u geldiğinde.. Aslında ikinci frame'in even'i olabilir elimizde. Ek bir bilgi olarak yuv encoding de benzeri bir prensiple çalışır.)

Bu sistemin getirdiği başka bir avantaj ise, birden çok cpu'muzun olduğu durumlar için geçerli. Yani elimizde her zaman execute edilmesi beklenen bir group task var. Ve bunların execution'ını biz aslında birbirinden bağımsız olarak değişik processorlere yaptırabiliriz. Hali ile

2. Frame total usage Time 25------------30------------35--------------40------------45-----------50

___________ Cpu1 | |___________________________________________________________ ___________ Cpu2 | |___________________________________________________________

__________________________________________________ Gpu ___| |__________________

Haline dönüştürebiliriz. Bu da aslında bizim için işlemciye çok daha fazla yüklenebileceğimiz manasına geliyor. Neticede her task bir iş yapıyor. Ve tasklar birbirinden tamamen bağımsız. Ve eğer hangi sıra ile yapıldıkları da önem taşımıyorsa o zaman bir task/thread manager gibi bir birim vasıtası ile eşit miktarda CPU'lara bölüştürülebilir. (Tam eşit olmaz tabii ki ama.. Olduğu kadar)... Bunun nasıl olacağına o birimi incelerken değineceğim. Ama çok basit mantığını anlatmam gerekirse iki thread olduğunu düşünün ve bunların wait state'de olduğunu düşünün. Ve ortada bir queue var. Eğer queue'ya yeni bir task/mesaj bir şey gelirse bunlardan biri uyanıyor ve queue'dan onu alıp execute'a başlıyor.. Sonra bir adet daha gelirse ikincisi de uyanıyor. V.s. Eğer birisi işini bitirirse tekrar wait state'e gelmeden queue'ya tekrar bakıyor ve eğer queue'da daha birkaç adet task daha varsa gene onlardan birini alıp execute mode'una giriyor. Neyse fazla kafa karıştırmadan bunu daha sonra anlatayım.

Neyse umarım bu timer konusu ve sync olayları hakkında bir bilgi verip temel bir design'ın nasıl olması gerektiği konusunda aydınlatabilmişimdir. Bu yazıya devam edeceğim kaldığım yerden şimdi diğer konulara dallanırsam çok uzayabileceği inancındayım. Bir sonraki yazımda task/thread manager kısmına değinmeyi düşünüyorum. Daha ileriki bölümlerde ise memory manager / resource manager ve temel şeyleri yapan bir gfx lib'i nasıl yapmalıyız şeklinde devam edeceğim ilk design'ımıza. 'Lord of the demos' adlı yazı dizisi devam edecektir.

ciao!

~sensei/rt - csermen@gmail.com

******************************************************************************** ÖĞRETİCİ DÖKÜMAN : SDL_MIXER İLE SES VE MÜZİK

SDL_Mixer SDL kütüphanesinde ses ve müzik kullanımını kolaylaştırmak için geliştirilmiş bir kütüphanedir. Ses ve müzik dosyalarını yüklemek ve çalmak üzere işinizi kolaylaştıracak birçok fonksiyona sahiptir. Öncelikle SDL_Mixer kütüphanesi ile kullanabileceğiniz dosya formatları; - WAVE/RIFF (.wav)