Bir oyun döngüsünde güncellemeden bağımsız oluşturmanın amacı nedir?

Oyun döngülerinde onlarca makale, kitap ve tartışma var. Ancak, oldukça sık böyle bir şeyle karşılaşıyorum:

while(running)
{
    processInput();
    while(isTimeForUpdate)
    {
        update();
    }
    render();
}

Temel olarak beni bu yaklaşımdan rahatsız eden şey “güncellemeden bağımsız” oluşturmadır; örneğin, hiçbir değişiklik olmadığında bir çerçeve oluşturur. Öyleyse benim sorum bu yaklaşımın neden sık sık öğretildiği?

Bu ortak kongreye nasıl ulaştığımızın uzun bir geçmişi var, yol boyunca çok fazla zorlayıcı zorluklar oldu, bu yüzden onu aşamalar halinde motive etmeye çalışacağım:

1. Sorun: Aygıtlar farklı hızlarda çalışıyor

Hiç modern bir bilgisayarda eski bir DOS oyunu oynamayı denediniz ve oynanamaz bir şekilde hızlı çalışıyor - sadece bir bulanıklık?

Eski oyunların çoğunda çok naif bir güncelleme döngüsü vardı - ne kadar zaman geçtiğini hesaba katmadan girdi topladılar, oyun durumunu güncellediler ve donanımın izin verdiği kadar hızlı hale getirdiler. Donanım değiştiği anda oyun oynanır.

Genellikle oyuncularımızın, geçen yılın telefonunu veya en yeni modelini, en üst seviye oyun masaüstünü veya orta seviye dizüstü bilgisayar.

Özellikle, rekabetçi olan oyunlar için (çok oyunculu veya skor tabloları aracılığıyla), belirli bir cihazda çalışan oyuncuların diğerlerine göre avantaj sağlamasını istemeyiz, çünkü daha hızlı koşabilirler veya daha fazla tepki verebilecekler.

Buradaki kesin çözüm, oyun durumu güncellemelerini yapma oranını kilitlemektir. Bu şekilde sonuçların her zaman aynı olacağını garanti edebiliriz.

2. Öyleyse, neden sadece kare hızını kilitlemiyorsunuz (örn. VSync kullanarak) ve hala oyun durumu güncellemelerini ve gösterimini lockstep'te çalıştırmıyorsunuz?

Bu işe yarayabilir, ancak izleyiciler için her zaman zevkli değildir. Uzun süredir 30 fps hızında koşarken oyunlar için altın standart olarak kabul edildi. Artık oyuncular, özellikle çok oyunculu aksiyon oyunlarında rutin olarak 60 fps minimum bar bekliyorlar ve bazı eski oyunlar şimdi beklentilerimiz değiştikçe belirgin şekilde dalgalı görünüyor. Ayrıca özellikle de kilitleri çerçevelemeye itiraz eden sesli bir bilgisayar çalar grubu var. Son teknolojiye sahip donanımları için çok para ödediler ve bu hesaplama kasını kullanabileceği en yumuşak, en yüksek kalitede render için kullanabilmek istiyorlardı.

Özellikle VR'de, kare hızı kraldır ve standart sürünmeye devam eder. Son VR canlanmasının başlarında, oyunlar genellikle 60 fps civarındaydı. Şimdi 90 daha standart ve PSVR gibi bir donanım 120'yi desteklemeye başlıyor. Bu henüz artmaya devam edebilir. Bu nedenle, eğer bir VR oyunu bugün yapılabilecek ve kabul görmüş olanlarla sınırlandırırsa, donanım ve beklentiler daha da geliştikçe geride bırakılabilir.

(Kural olarak, genellikle "sırayla bir kareyi tanıma" gibi belirli bir "algı" türüne dayandığı için "oyuncular XXX'tan daha hızlı bir şey algılayamaz" derken dikkatli olun. Hareketin devamlılığı algısı genellikle çok daha fazladır hassas. )

Buradaki son sorun, kilitli bir kare hızını kullanan bir oyunun da muhafazakar olması gerektiğidir - oyunda bir anda çok fazla sayıda nesneyi güncellediğiniz ve görüntülediğiniz bir anı vurursanız, çerçevenizi kaçırmak istemezsiniz. son teslim tarihi ve belirgin bir kekemelik veya aksamaya neden olur. Dolayısıyla, içerik bütçelerinizi boşluk bırakacak kadar düşük tutmanız veya tüm oyun deneyimini en az özellikli donanımdaki en kötü durum performansına zorlamaktan kaçınmak için daha karmaşık dinamik kalite ayarlama özelliklerine yatırım yapmanız gerekir.

Bu, özellikle performans sorunları geç gelişme halinde ortaya çıkarsa, mevcut tüm sistemlerinizin şimdi her zaman vuramayacağınız bir adım adım görüntü oluşturma çerçevesini varsayarsak ve ayarlandığı zaman sorunlu olabilir. Dekuplaj güncelleme ve oluşturma oranları, performans değişkenliği ile başa çıkmak için daha fazla esneklik sağlar.

3. Sabit bir zaman diliminde güncelleme yapmak, (2) ile aynı sorunları yaşamıyor mu?

Bence asıl sorunun özü şu: güncellemelerimizi birleştirir ve bazen aralarında oyun durumu güncellemesi olmayan iki kareyi oluşturursak, o zaman daha belirgin bir değişiklik olmadığından, daha düşük bir kare hızında lockstep oluşturma ile aynı olmaz mı? ekran?

Oyunların, bu güncellemelerin ayrışmasını iyi bir sonuç elde etmek için kullanmasının birkaç farklı yolu var:

a) Güncelleme oranı , oluşturulan kare hızından daha hızlı olabilir

Tyjkenn başka bir cevabın da belirttiği gibi, özellikle fizik çoğu kez renderleme işleminden daha yüksek bir frekansta kademelendirilir, bu da entegrasyon hatalarını en aza indirmeye ve daha doğru çarpışmalar vermeye yardımcı olur. Dolayısıyla, oluşturulan kareler arasında 0 veya 1 güncelleme yapmak yerine, 5 veya 10 veya 50 olabilir.

Şimdi 120 fps'de oynatıcı, kare başına 2 güncelleme alabilirken, 30 fps'de daha düşük özellikli donanım sunumu yapan oyuncu, kare başına 8 güncelleme elde ediyor ve her iki oyunu da aynı anda saniyede aynı hızda oynuyor. Daha iyi donanım, daha yumuşak görünmesini sağlar, ancak oyunun nasıl çalıştığını kökten değiştirmez.

Burada , güncelleme hızı kare hızıyla eşleşmiyorsa, ikisi arasında bir "yendi sıklığı" alabilme riski vardır . Örneğin. Çoğu karede 4 oyun durumu güncellemesi ve biraz geriye kalanlar için yeterli zamanımız var, o zaman her seferinde bir karede 5 güncelleme yapmak için yeterli tasarruf sağladık, bu sayede harekette küçük bir sıçrama veya kekemelik yaptık. Bu ele alınabilir ...

b) Oyun durumunu güncellemeler arasında enterpolasyon yapmak (veya ekstrapolasyon yapmak)

Burada sıklıkla oyun durumunun gelecekte bir sabit zaman aşımına uğramasına izin vereceğiz ve aralarında keyfi bir nokta oluşturabileceğimiz en son 2 durumdan yeterince bilgi depolayacağız. Ardından ekranda yeni bir çerçeve göstermeye hazır olduğumuzda, sadece gösterim amacıyla uygun anı harmanlarız (yani, burada temel oyun durumunu değiştirmiyoruz)

Doğru yapıldığında bu, hareketin tereyağını pürüzsüz hissetmesini sağlar ve hatta çok düşük düşmediğimiz sürece kare hızındaki bazı dalgalanmaları maskelemeye yardımcı olur .

c) Oyun dışı durum değişikliklerine pürüzsüzlük ekleme

Enterpolasyon oyun durumu olmadan bile, yine de bazı pürüzsüzlük kazançlar elde edebilirsiniz.

Karakter animasyonu, parçacık sistemleri veya VFX ve HUD gibi kullanıcı arayüzü öğeleri gibi tamamen görsel değişiklikler, genellikle oyun durumunun sabit zaman çizelgesinden ayrı olarak güncellenir. Bu, oyun durumumuzu kare başına birden çok kez tıklattığımız takdirde, maliyetlerini her onay işaretiyle ödeyemeyiz - yalnızca son işlem geçişinde. Bunun yerine, bu efektlerin oynatma hızını karenin uzunluğuna uyacak şekilde ölçeklendiriyoruz, bu nedenle (1) de tartışıldığı gibi oyun hızını veya adaleti etkilemeden renderleme kare hızının izin verdiği kadar yumuşak oynarlar.

Kamera hareketi bunu da yapabilir - özellikle VR'de, bazen aynı kareyi bir kereden fazla göstereceğiz, ancak oyuncunun aradaki baş hareketini hesaba katması için reddettiğimizde , algılanan gecikme ve rahatlığı artırabiliriz. doğal olarak her şeyi bu kadar hızlı yapmayın. Bazı oyun akış sistemleri (oyunun bir sunucuda çalıştığı ve oyuncu yalnızca ince bir istemcinin çalıştığı) bunun bir sürümünü de kullanır.

4. Neden sadece (c) stilini her şey için kullanmıyorsun? Animasyon ve kullanıcı arayüzü için çalışıyorsa, oyun durumu güncellemelerini mevcut kare hızına uyacak şekilde basitçe ölçekleyemez miyiz?

Evet * bu mümkün, ama hayır basit değil.

Bu cevap zaten biraz uzun, bu yüzden tüm ayrıntılara girmeyeceğim, sadece kısa bir özet:

• Doğrusal değişim deltaTimeiçin değişken uzunluktaki güncellemeleri ayarlamak için çalışmalarla çarpma (örn. Sabit hızda hareket, bir zamanlayıcının geri sayımı veya bir animasyon zaman çizelgesi boyunca ilerleme)

• Ne yazık ki, oyunların birçok yönü doğrusal değildir . Yerçekimi kadar basit bir şey bile, değişen kare hızlarında farklı sonuçların ortaya çıkmasını önlemek için daha karmaşık entegrasyon teknikleri veya daha yüksek çözünürlüklü alt tabakalar gerektirir. Oyuncu girişi ve kontrolü kendisi büyük bir doğrusallık kaynağıdır.

• Özellikle, ayrık çarpışma algılama ve çözünürlüğünün sonuçları, güncelleme hızına bağlı olarak çerçeveler çok uzarsa tünel açmaya ve titremeye neden olur. Bu nedenle değişken bir kare oranı bizi içeriğimizin çoğunda daha karmaşık / pahalı sürekli çarpışma algılama yöntemleri kullanmaya ya da fizikteki değişkenliği tolere etmeye zorlar. Sürekli çarpışma algılaması bile nesneler yaylarda hareket ettiğinde, daha kısa zaman aşımına uğrayan zorluklarla karşılaşır ...

Bu nedenle, genel bir orta karmaşıklık oyununa ilişkin olarak, tutarlı bir davranış ve adaleti tamamen deltaTimeölçeklendirme yoluyla korumak , tamamen zorla mümkün olmayan, çok zor ve bakım arasında bir yerdedir.

Bir güncelleme oranını standartlaştırmak , genellikle daha basit kodlarla, bir dizi koşulda daha tutarlı davranışları garanti etmemizi sağlar .

Bu güncelleme oranı tutulması render itibarıyla ayrılır bize veren esneklik deneyimi düzgünlüğü ve performansını denetlemek için oyun mantığı değiştirmeden .

O zaman bile hiçbir zaman gerçek anlamda “mükemmel” bir çerçeve bağımsızlığı elde edemiyoruz, ancak oyunlardaki pek çok yaklaşım gibi bize verilen bir oyunun ihtiyaçları için “yeterince iyi” ye çevirmek için kontrol edilebilir bir yöntem veriyor. Bu nedenle yaygın olarak faydalı bir başlangıç ​​noktası olarak öğretilir.

Diğer cevaplar iyidir ve oyun döngüsünün neden var olduğu ve oluşturma döngüsünden ayrı olması gerektiği hakkında konuşun. Ancak, "Neden bir değişiklik olmadığında neden bir çerçeve oluştur" özel örneğine gelince. Gerçekten de sadece donanım ve karmaşıklığa bağlı.

Ekran kartları devlet makineleri ve aynı şeyi tekrar tekrar yapmakta gerçekten başarılılar. Yalnızca değişen şeyleri yaparsanız, aslında daha pahalı, daha az değil. Çoğu senaryoda, statik olan hiçbir şey yoktur, eğer bir FPS oyunda biraz sola hareket ederseniz, ekrandaki% 98’in piksel verisini değiştirirseniz, tüm kareyi de oluşturabilirsiniz.

Ama esas olarak, karmaşıklık. Bir güncelleme yaparken değişen her şeyi takip etmek çok daha pahalıdır, çünkü ya her şeyi yeniden yapmanız ya da bazı algoritmaların eski sonuçlarını takip etmeniz, yeni sonuçla karşılaştırmanız ve yalnızca değişiklik farklıysa bu pikseli oluşturmanız gerekir. Bu sisteme bağlıdır.

Donanım vb. Tasarımlar mevcut sözleşmeler için büyük ölçüde optimize edilmiştir ve bir durum makinesi başlangıç ​​için iyi bir model olmuştur.

Render genellikle oyun döngüsündeki en yavaş işlemdir. İnsanlar, kare hızındaki 60'tan daha hızlı bir farkı kolayca fark edemezler; bu nedenle oluşturma işleminden daha hızlı zaman harcamak çoğu zaman daha az önemlidir. Ancak, daha hızlı bir oranda daha fazla fayda sağlayacak başka süreçler var. Fizik birdir. Bir döngüdeki değişimin çok büyük olması, nesnelerin duvarları tam olarak aşındırmasına neden olabilir. Daha büyük artışlarla basit çarpışma hatalarını aşmanın yolları olabilir, ancak birçok karmaşık fizik etkileşimi için aynı doğruluğu elde edemezsiniz. Fiziksel döngü yine de daha sık çalıştırılırsa, nesneler her seferinde oluşturulmadan daha küçük artışlarla hareket ettirilebildiğinden, daha az aksaklık olasılığı vardır. Hassas fizik motoruna daha fazla kaynak gider ve kullanıcının göremediği daha fazla çerçeve çizmeye daha az harcanır.

Bu özellikle grafik yoğun oyunlar için önemlidir. Her oyun döngüsü için bir render olsaydı ve bir oyuncu en güçlü makineye sahip olmasaydı, oyunda fps'nin 30 ya da 40'a düştüğü noktalar olabilirdi. Oyun, her bir fizik değişikliğini, aksaklıktan kaçınmak için oldukça küçük tutmaya çalışırsak, oldukça yavaş olmaya başlar. Oyuncu, karakterinin normal hızın sadece yarısı kadar yürüdüğünden rahatsız olur. Eğer görüntü oluşturma hızı döngünün geri kalanından bağımsız olsaydı, oyuncu kare hızındaki düşüşe rağmen sabit bir yürüyüş hızında kalabilecekti.

Sorunuzdaki gibi bir yapı, oluşturma alt sisteminin "son oluşturma işleminden bu yana geçen zaman" kavramına sahip olup olmadığını anlayabilir .

Örneğin, oyun dünyasındaki bir nesnenin konumunun (x,y,z), mevcut hareket vektörünü ek olarak saklayan bir yaklaşımla sabit koordinatlarla temsil edildiği bir yaklaşımı düşünün (dx,dy,dz). Şimdi, oyun döngüsünü, pozisyondaki değişimin updateyöntemde gerçekleşmesi gerekecek şekilde yazabilir , ancak hareketin değişmesi sırasında gerçekleşmesi için de tasarlayabilirsiniz update. İkinci yaklaşımla, oyun durumunuz aslında updatebir sonrakine kadar değişmese de ,render- daha yüksek bir frekansta çağrılan fonksiyon, nesneyi biraz güncellenmiş bir pozisyona çekebilir. Bu teknik olarak, gördükleriniz ile dahili olarak temsil edilenler arasında bir tutarsızlığa yol açsa da, fark, pratik yönlerin çoğu için farketmeyecek kadar küçüktür, ancak animasyonların daha yumuşak görünmesine izin verir.

Oyun durumunuzun "geleceğini" tahmin etmek (yanlış olma riskine rağmen), örneğin ağ girişi gecikmelerini hesaba kattığınızda iyi bir fikir olabilir.

Diğer cevaplara ek olarak ...

Durum değişikliğini kontrol etmek önemli işlem gerektirir. Değişikliklerin kontrol edilmesi benzer (veya daha fazla!) İşlem süresi gerektiriyorsa, aslında işlemeyi gerçekleştirmeye kıyasla, durumu gerçekten daha iyi hale getirmediniz. Bir görüntü oluşturma durumunda, @ Waddles’in söylediği gibi, bir ekran kartı aynı aptal şeyi tekrar tekrar yapmakta gerçekten iyidir ve değişiklikler için her veri yığınını kontrol etmekten daha maliyetlidir. işleme için ekran kartına. Ayrıca görüntü oluşturma oynanışı ise, ekranın son onaylamada değiştirilmemesi olası değildir .

Ayrıca, renderlemenin önemli işlemci süresi aldığını varsayıyorsunuz. Bu, işlemcinize ve grafik kartınıza bağlıdır. Uzun yıllar boyunca, odak noktası giderek daha karmaşık işleme çalışmalarını grafik kartına boşaltma ve işlemciden ihtiyaç duyulan görüntü işleme girişini azaltma üzerine odaklandı. İdeal olarak, işlemcinin render()çağrısı basitçe bir DMA transferi kurmalı ve bu kadar. Grafik kartına veri alınması daha sonra bellek denetleyicisine verilir ve görüntünün üretilmesi grafik kartına verilir. İşlemci paralel olarak bunu kendi zamanlarında yapabilirlerfiziği, oyun motoru ve bir işlemcinin daha iyi yaptığı diğer şeyleri sürdürür. Açıkçası, gerçeklik bundan çok daha karmaşık, ancak çalışmayı sistemin diğer bölgelerine boşaltabilmek de önemli bir faktör.