intro zamanlamasinda belirli bir FPS degerinde calismak

[chenmy1]

Selam,
 Bu en buyuk sorunlarimdan birisi neden oldugunu anlamiyorum fakat ekranin FPS degeri 20 i gosterdiginde introda belli bir atlama oluyor. FPS 150+ oldugunda ise intro daha seri bir harekete geciyor.Buda gozle gorulur bir hiz bozukluguna neden oluyor yani kamera hareketleri olsun v.s. olsun bir atlama v.s. yuzunden introdaki o anlik hissi kaybetmeye neden oluyor.
 
Benim istedigim FPS ister 150+ olsun ister 30 ben ekran tazeleme suremi direkt belirli bir FPS ye gore nasil ayarliyabilirim?
 
Mesala benim icin en dusuk sevye araligi 1-30 arasiolmasini istiyorum ne bundan yuksek nede bundan dusuk?Yani kisitlamak istiyorum bunu nasil yapabilirim?

[skate]

efektlerin çalışma zamanlamaları FPS'ye değil, zaman delta değerine bağlı olmalı. yani her zaman bir "oncekiZamanDegeri" ve "suAnkiZamanDegeri" değerlerin olmalı ve aradaki fark sana bir "gecenZaman" değeri vermeli. senin efektlerin de bu değere göre çalışmalı. en basit örnek olarak ekranda hareket eden bir objeyi "gecenZaman * hiz" şeklinde bir formülle hareket ettirirsen 20 FPS de olsa 150 FPS de olsa aynı sürede aynı mesafe kat edecektir.

[nightlord]

chenmy1: fps'yi sabitlemeye calismamalisin. zamani sabitlemeye calismalisin. ideal yaklasim budur. boylece daha iyi donanimi olanlar daha akici seyredebilir. sen istersen bir minimum sistem requirement koyarsin. bunun altindaki sistemlerde fps o kadar dusuyor ki demonun izlenmesi anlamsizlasiyor ve ben insanlarin demomu boyle gormesini istemiyorum diyebilirsin. Bunun icinhatta demonun basinda kucuk birkac test yapip minimumun altindaki sistemde hata mesaji verip cikabilirsin bile. ama genelde ust sinir koymamakta fayda vardir.
 
degisken fps ile zamanlamayi sabit tutmak icin de skate'in postunda belirttigi gibi her frame'de gecen zamani kullanarak herseyi update etmelisin

[chenmy1]

Sorunsuki FPS de bir dalgalanma oldugu an mesala cok polygonlu bir yerde 150 fpsden bir anda 20 FPS ye dusuyor buda gozle gorulur bir bozukluga neden oluyor ordan cikinca birden 100 fps v.s.
 
benim kullandigim sistem soyle:
 

Kod: [Seç]

float zaman,basla;
 
bool init()
{
 
MuzikBasla();
basla=timeGetTime();
return true;
}
 
void Sahne()
{
zaman = timeGetTime()-basla; //genel zamanim 0 ms den basliyip demo bitenede kadar
 
 DEMO();
}

fakat penceremi REALTIME pro. etmeme ragmen bu FPS dalgalanmasi yuzunden feci goruntu bozukluklari olusuyor..Gerci Opengl framebufferimdada sorun olabilir bilemiycem.
 
Burda acaba pencerem mi performansis calisiyor?
 
Conspricy demolarinda dusuk fps lerde bile smooth goruntu var mesala bunu nasi basariyorlar bu FPS dalgalanmasi diger yabanci demolari neden etkilemiyor?

[nightlord]

acaba vblank senkronizasyonu kullanmiyor olabilir misin?

[chenmy1]

o nedir?:S

[anesthetic]

@chenmy1: fps'nin aniden düştüğü partlarda giriş çıkış geçişleri ile fps'yi daha yavaş değiştirmeye çalış. birden 100'den 20'ye düşmek yerine ekranda gösterdiğin şeylerin sayısını yavaş yavaş artırarak gözü düşük fps'ye alıştırmaya çalışabilirsin.

@skate, nightlord: demolarda oyunlardan farklı olarak olacak şeyleri önceden bilme avantajımız var. o yüzden
"konum += gecenZaman * hiz"
yerine
"konum = ilkKonum + (simdikiZaman - ilkZaman) * hiz"
daha makul.

Sebebi ise üzerinde birikimsel olarak işlem yapılan floating bir değerin hata oranının giderek büyümesi. 5 dakikalık bir demoda 60fps'den 18000 adet floating işlem inanılmaz hata farkı yaratmayacaktır ama farklı fps dağılımlarına sahip iki runda ince konum ayarları fark yaratabilir ve poligon intersection sınırlarında bu fark gözle görülebilir hale gelebilir.

Bunun dışında, demo çok düşük fpslerde çalışıyorsa (örneğin 1 fps), iki frame arası süre farkı çok keskin olmayacak ve hata payı çok büyüyecektir. Örneğin Che Guevara/Fairlight'taki eleman yürürken, şapka ve gözleri kafadan faha yükseğe çıkıp ebleh bir görüntü oluşturuyordu bende. Videosunu izleyene kadar bunun isteyerek böyle yapılmış olduğunu sanıyordum.

Hepsi bir kenara, zaman farkından ilerlemek olacak şeyleri önceden bilmediğimiz uygulamalarda (örn. oyun, bilimsel simülasyonlar) kullanmak zorunda kalınan bir yöntem. Animasyonlar için tüm fonksiyonları t cinsinden vermek yapılan işin doğasına daha yakın.

[skate]

@anes: atladığın bir nokta var. her zaman olay * hiz kadar basit ifade edilemiyor sen de biliyorsun. ben dummy bir örnek verdim. komplike örneklerde "ilk pozisyon +" şeklinde sonuca gitmek imkansıza yakın. ancak "ilk pozisyon" dediğin değeri ivme her değiştiğinde güncellersen bu mümkün olabilir ki timeDelta'dan gitmek her zaman daha pratiktir.

[anesthetic]

ivme değeri ile gidiyorsan da
hiz = ilkHiz + ivme * (simdikiZaman - ilkZaman)
konum = ilkKonum + hiz * (simdikiZaman - ilkZaman)
ya da daha basitçe
zaman = (simdikiZaman - ilkZaman)
konum = ilkKonum + hiz * zaman * zaman + ilkHiz * zaman
formülleriyle deltasız çıkarılabilir. Eğer kareler arasındaki süre farkı ile bir fonksiyonu analitik olarak ifade edebiliyorsan, ilk kare ile farkı kullanarak da ifade edebilirsin. Ne olacağı önceden kesin olarak belliyse çoğu durumda daha karışık olmayacaktır, çünkü deltada fonksiyonun kendisi yerine türevini bilmen gerekiyor.

En genel kullanımda splineları ya da daha yaygın olarak sinüs hareketleri t cinsinden ifade etmek dt cinsinden ifade etmekten daha basittir. dt cinsinden de:
t += (simdikiZaman - oncekiKareninZamani)
şeklinde şu anki zamanı tutarak basitçe ilerleyebiliriz ki tek float işlemle
t = simdikiZaman - ilkZaman
demek hem daha basittir hem de daha hatasız sonuçlar verecektir.

[skate]

anes, demo partında çarpışan irili ufaklı partiküller düşün, kütlelerine göre birbirlerine enerji veriyorlar, ivme değiştiriyorlar. bir partikül 45 saniye birçok diğer partikülle çarpıştıktan sonra yukardaki formüle göre nasıl hesaplanacak? benim demek istediğim bu. aşırı statik düşünürsen ok ama dinamik efektler için "ilk değer" işlemez.

[nightlord]

aslinda ikisinin de isleyecegi durumlar vardir. Ben yapilan efekte gore farkli teknikler kullaniyorum. ornegin temel objelerin ekrana ilk girisini genelde mutlak zaman ile (yani baslangictan) yonetiyorum. Efekt ici olaylari da (mesela objenin kimi atributelerindeki degisiklikleri) efekte lokal yapiyorum. Boylece efekti bir butun olarak zamanda istedigim yere koyabilirim.
 
Frameler arasi fark kullandigim en temel yer de particle system'ler. onlarda her particle'i her frame update ederken bir onceki frame'den farki kullaniyorum. Boylece daha fazla karmasik ve degisken kuvvetin etki ettigi particlelar yapmak mumkun oluyor.
 
Zaten particle systemler (ve baska olasi pekcok demo efekti) anes'in "simulasyon" olarak isimlendirdigi olguya "animasyon"dan daha yakin. Yani demolar bana gore yalnizca animasyon degiller cogu zaman.

[chenmy1]

Cogu yabanci introda cok smooth hareketler goruyorum mesala asm. 2004 de birinci olan 64kb intro sanirim fps olarak bende 3-6 fps arasi calisiyodu ama benim 30 fps gosteren intromdan daha smooth hareketler vardi .Anlamadigim nokta bu.

[anesthetic]

demoda particleları gerçek fiziksel modellerle belirtmek yerine "fake" particle yollları kullanmak daha makul geliyor bana. bunun dışında önceden sabit zaman aralıkları ile yolu hesaplayıp yaklaşığını verecek anahtar noktaları küçük arraylerde tutmak demonun her çalıştığında aynı şeyi göstermesini sağlayacaktır. fake efektler yerine illa gerçek hesaplamalar gerekecekse nightlord'un önerdiği yol da makul (ki daha önce tüm timelining bahsettiğim sistemde iken yerel bi kaç yerde iki kare arası süre farkı kullandım). demonun çalıştığı (çalışabildiği) her makinada aynı şeyi göstermesi, yapılan hesapların fiziksel gerçekçiliğinden (ki o da en iyi ihtimalle tam değerlerle olmayacak) daha önemli ise fps ile alakalı değişkenlerden uzak durmak gerekir. tabi bu kadarı da tat meselesi :)

[anesthetic]

@chenmy: görüntüdeki objeleri daha yavaş ilerletmeye çalış. renk değişimleri ne kadar fazlaysa düşük fps'nin etkisi o kadar yüksek olur.

[poison]

zaman hesapları yaparken müziği neden kullanmıyorsunuz?

void CALLBACK OnTimer( UINT wTimerID, UINT msg, DWORD dwUser, DWORD dw1, DWORD dw2)
{
    QWORD position = BASS_ChannelGetPosition(hMusic);

    float time = BASS_ChannelBytes2Seconds(hMusic,position);

    if ( senario != NULL )
#ifdef _DEBUG
        if ( paused == FALSE )
#endif
        senario->FrameMove( time );
}

şeklinde frameMove'u sisteme ait timer'da call ediyorum ama asıl zamanı müzikden alıyorum. böylece bahsettiğiniz iki işi birden (delta yada t) şeklinde iki hesabıda yürütebiliyorum, hatta demoyu runtime'da ileri geri alma imkanı bile oluyor.