Yine bir gp2x sorusuyla karsinizdayim 😛 Gnostic umarim bana uyuz olmamissindir bu kadar cok soru soruyorum diye. Aslinda arastirma yapmadan sormuyorum ama gp2x development hakkinda cok fazla bilgi yok nette. Noiz2sa sourcelari baslica referansim oldu artik 🙂
Bu seferki sorunum da soyle ki gp2xmenu arkaplanda calisirken minimal library ile direk framebuffera erisip piksel yazan kodum gozle gorulur (ve fps counterla olculur) sekilde daha hizli calisiyor. Aklima bir tek mmuhack olabilir mi acaba geldi baska da bir sey bulamadim. Ne dersin bu konuda?
Bir de Vertical blanking problemini hala cozemedim.
edit: Simdi mmuhack'le de denedim. Birsey degismedi.

haftasonu boyunca mqb/analog ve Lryiu/bronx god of war 2 gelmeden tekrar bir god of war'u bitirelim diye oyun oynadiklarindan ve bende dayanamayip izledigimden dolayi, vbl'ye bakma firsatim olmadi. bugun/yarin bakarim.
gp2xmenu acikken daha hizli olmasi konusunda hicbir fikrim yok acikcasi.. o mmuhack vs kullanmiyor ve SDL ile yazilmis.. (eger sistemin kendi menusunden bahsediyorsan)
gp2xmenu calisirken daha hizli ise gpe yerine gpu yapabilirsin 😃
aklima tek gelen, yanlis hatirlamiyorsam, gp2xmenu calisirken init level boot'da duruyor linux.. gp2xmenu kapatildiginda init 3'e geciyor.. ama bu bahsettigin hiz farkini olusturur mu bilmiyorum.. ya da gp2xmenu birseyleri set ediyor ve kapanirkende bunlari eski haline aliyor. set ettigi seyler neyse, bu daha hizli olmasina neden oluyor.. ilginc..

update update!
Simdi anladim ki problem framebuffer'a erisim hiziyla alakali degil. Problemi asagidaki fps kitleme koduma kadar trace ettim:

while (frametime>gp2x_timer_read()) {
            asm volatile ("nop");
            asm volatile ("nop");
            asm volatile ("nop");
            asm volatile ("nop");
        }

Bu loop bir sonraki frame'i cizmesi gereken zaman gelene kadar bekliyor. gp2x tickleri her milisaniyede bir atiyor. menu yuklu degilken ne hikmetse bu looptan her iki cikista bir frame zamanini bayagi iskalamis oluyor (40-50 ms kadar gec cikiyor looptan). Menu yuklu iken boyle bir problem yok.
bu loop'u suna degistirip denedim:

while (frametime>gp2x_timer_read()) {}

sonuc ilginc bir sekilde yine ayni. Bir sonraki frame'in basilmasi gereken zamani timer'i tekrar okuyup bir degerle toplayarak elde ediyordum. Simdi direk eski frametime'in uzerine bir deger ekleyerek yapiyorum boylece en azindan bir sonraki frame'de toparliyor. Ama tabi boyle olunca da menu acikken cillop gibi hep ayni framerate'i veren kod menu kapaliyken her saniye bir artiyor bi azaliyor, ancak ortalama olarak verdigim degeri tutturabiliyor.
Su anda gorunen o ki:
ya isletim sistemi menu calismiyorken menuden daha inatci bir taska veriyor cpu'yu, boylece cpu benim process'e daha gec donuyor
ya da gp2x_timer_read fonksiyonunun calisma suresi menu kapaliyken anlasilmaz bir sekilde uzuyor.

GnoStiC wrote:haftasonu boyunca mqb/analog ve Lryiu/bronx god of war 2 gelmeden tekrar bir god of war'u bitirelim diye oyun oynadiklarindan ve bende dayanamayip izledigimden dolayi..

Geldi abi ben oyniom 🙂

@jimqode: emin olmak icin;
0.c kullaniyorsan gp2x_timer_init ve gp2x_timer_start 'i kullaniyorsun di mi?
ya da
0.c'den kucuk birsey kullaniyorsan gp2x_ticks_per_second (init'te tanimlaniyor) degerinden olabilir mi?
@bakkada: mqb 256k'lik hatti ile duallayer versiyonu torrent ile cekiyor, seed azmis galiba.. hemen gelmesin zaten, sonra oturup izliyom vakit kaybi oluyo.. 🙂

@gnostic: 0.c'yi henuz elime geciremedim. 0.b preview kullaniyorum. ticks per second 1000 olarak ayarli her iki durumda da. ama menu onu gidip tekrar set ediyor mudur acaba? galiba hardware bi sayac o cunku.

code'unun tamamini gormedigim icin, arada overflowluk bir durum mu oluyor acaba diye dusundum kendimce.. 🙂
ben minilib ile ilk timing konusunu mame source'undan gorup uygulamistim;

unsigned long onceki;

unsigned long suanki = gp2x_timer_read();
unsigned long interval = 1000/50; // ticks/fps

if ((suanki - onceki) < interval) {
while ((suanki - onceki) < interval) {suanki = gp2x_timer_read();}
}
onceki = suanki;

gibi birseydi..