UPS ve FPS - Neyi sınırlamalıyım ve neden?

Şu anda C ++ ve SDL2 kullanarak bir oyun yazıyorum ve merak ettiğim bir şey var - saniyedeki karelerimi (FPS) ve / veya saniyedeki güncellemelerimi (UPS) sınırlamak anlamlı mı?

UPS'i sınırlarsanız, oyunun hızını kontrol edersiniz - oyuncu güncelleme başına 1 piksel hareket ederse ve her zaman saniyede 30 kez güncellerseniz, 30 piksel / sn hızla hareket edersiniz ve siz Saniyede hesaplama miktarı azaldığından CPU'yu da rahatlatacaktır. FPS'yi sınırlarsanız, saniye başına çizim sayısı azalır, bu nedenle GPU'nuzu rahatlatırsınız. Umarım hepsini doğru anladım, eğer değilse, beni düzeltmekten çekinmeyin.

Sorum şu: Oyunumda neyi sınırlamam gerekiyor? FPS? GÜÇ KAYNAĞI? Her ikisi de? Ne? Buna başka, daha iyi bir yaklaşım var mı? Çoğu oyunda bu nasıl yapılır ve neden?

Cevaplar büyük beğeni topluyor!

Evet, mantıklı.

Söylediğiniz gibi, sistem üzerinde daha az yük oluşturacak, bu da termaller ve diğer uygulamalar için iyidir.

Ancak ... Oyun mantığınız saniyedeki güncellemelere bağlı OLMAMALIDIR. Bu nedenle, oyununuzu saniyedeki güncellemelerden bağımsız hale getirecek deltatime bir göz atmanızı öneririm.

Bu soruya göz atmanızı tavsiye ederim. Nasıl hesaplanacağını ve kullanılacağını oldukça iyi açıklar. Delta zamanı nasıl alınır ve kullanılır?

Umarım yardımcı olmuştur!

En iyi cevap: Duruma göre değişir .

Hiçbirini sınırlamak zorunda değilsiniz

Güncellemeler : Güncellemeleriniz bir üst sınıra bağlı değilse , oyunun çalıştığı makineye bağlı olarak oyunu daha hızlı veya daha yavaş çalıştırmaktan kaçınmak için oyun mantığı bir delta zaman miktarına bağlı olmalıdır . Bu, birçok oyun tarafından kullanılan çok yaygın bir yaklaşımdır, ancak sadece bu değildir.

Oluşturma : Oluşturma bir üst sınıra bağlı değilse, çerçeve arabelleği eksik veya hatalı bir durumda sunularak yırtılmaya neden olabilir . Bu nedenle birçok oyun Dikey Senkronizasyon (v-sync) kullanır

Her ikisini de sınırlayabilirsiniz

Güncellemeler : Bazı oyunlar , oyun sistemlerinin bazıları veya tümü için sabit zaman aralıklarından yararlanır . Bu yaklaşım aynen sizin tanımladığınız gibi çalışır. Saniyede Güncelleme sayısı, üst düzey bir makinede işlerin çok hızlı hareket etmediğinden emin olmak için bir üst sınırla sınırlıdır. Bu delta zamanlaması ihtiyacını ortadan kaldırır. Bazı uygulamalar sabit zaman aralıklarında, bazıları delta zamanlamalı olarak daha iyidir. Hangi yaklaşımı seçmek tamamen tam olarak neyi başarmaya çalıştığınıza bağlıdır. Çevrimiçi kitap GameProgrammingPatterns , her iki mimariye de dokunan oyun döngülerine adanmış bir bölüme sahiptir .

Rendering : Saniyedeki Kare yukarıda belirtilen yırtılma sorunu önlemek için bir üst limit olarak ayarlanması gerekir, ancak, uygulama olmamalıdır bazı CPU kilidi ile el bunu çalışırlar. Bunun yerine, v-sync özelliğini etkinleştirin ve alt donanımın monitörün yenileme hızıyla senkronize olmasına izin verin. Bunu yaparak, oyununuz şu anda yaygın olan 60Hz'den çok daha yüksek bir frekansta çalışabilecek gelecekteki monitörlerle uyumlu olacak. Ayrıca, özellikle kıyaslamaya dahil olan birçok oyuncunun hala mümkün olan en yüksek kare hızına izin vermek için v-sync olmadan çalışmayı tercih ettiğini belirtmek gerekir. Bu nedenle, çalışma zamanı sırasında özelliğin etkinleştirilmesine veya devre dışı bırakılmasına izin vermek mantıklıdır.

Neyi sınırlamamalısın

Oyununuz kullanıcı girişi için yoklama tabanlı bir yaklaşım kullanıyorsa, örneğin: getInput()güncelleme adımı sırasında denetleyici durumlarını güncellemek için bir tür çağrı çağırırsa , bu sınırlandırılmamışsa daha iyidir. Veya sınırlıysa, çok yüksek bir üst sınıra ayarlayın. Kullanıcı girişini ne kadar sık ​​sorgular ve ona göre hareket ederseniz, oyun o kadar duyarlı ve pürüzsüz olur. Bugünlerde duyduğumuz 60Hz oyunlar, AI'yi ve tüm dünya durumlarını bu oranda güncellemiyor, bazıları bu kadar hızlı hale gelmiyor, ancak denetleyici girdisini saniyede en az 60 kez sorgulıyor ve oyuncu avatarını buna göre güncelliyor. Bunun sadece hızlı tempolu aksiyon oyunlarıyla gerçekten alakalı olduğu kabul edildi.

Bir göz atmak isteyebileceğiniz iki gönderi var:

Timestep'inizi düzeltin

Enterpolasyonlu fizik oluşturma

Görevler hakkındaki tartışmaları gerçekten paha biçilmez buluyorum, ama bence oyunda önemli miktarda fizik simülasyonu olduğunda en mantıklı. Özet olarak, simülasyonun sabit bir zaman adımı olması gerekir (aksi takdirde fizik, deltanın çok büyük olduğu bir noktada patlayabilir), oysa renderleme işlemine mümkün olan en yüksek hızda çalışma özgürlüğü verilmelidir. Her ikisini de senkronize etmek için (simülasyon ve oluşturma), oluşturma durumu, simülasyonun aşağıdaki güncellemeden ne kadar uzak olduğuna bağlı bir faktör tarafından enterpolasyonlanır (simülasyonun sabit olduğunu unutmayın).

Umarım yardımcı olur.