Oyunlar için STL, evet mi, hayır mı? [kapalı]

Her programlama dilinin standart kapsayıcıları, algoritmaları ve diğer yardımcı öğeleri vardır. C #, Java ve Python gibi dillerle, dili standart lib olmadan kullanması neredeyse imkansızdır .

Yine de üzerinde çalıştığım birçok C ++ oyununda ya STL'yi hiç kullanmadık, ya da çok küçük bir kısmını kullandık ya da kendi uygulamalarımızı kullandık. Bunun oyunlarımız için sağlam bir karar olup olmadığını veya STL’nin cehaletinden birisini söylemek zor.

Öyleyse ... STL uygun mu, değil mi?

Profesyonel oyun geliştirme alanında çalıştığımda, STL çok olgunlaşmamış ve şişmişti. Fakat bu> 10 yıl önceydi.

Şimdi daha zorlu performans gereksinimlerine sahip askeri simülasyonda çalışıyorum (kare hızı hiçbir zaman FPS'nin altına düşmeyecek gibi). Askeri simülasyonda her yerde STL kullanılıyor.

Size STL kullanmamanızı söyleyenlerden bazıları, sorunun her zaman mükemmel veya hatta en iyi çözüm olmadığı iddiasını kullanır. Ancak bu sorunun cevabı değil. Soru şu olmalı: STL'yi oyunlarda kullanmakta doğal olarak yanlış bir şeyler var mı? Hayır derim, STL çoğu zaman bir kullanıcının kendi başına bulabileceğinden daha iyi bir uygulamadur.

STL'yi nasıl kullanacağınızı bildiğinizden emin olun ve oyununuzda kullanın. Bazı kitapları okuyun ve kullandığınız STL'deki uygulama koduna bakın.

Tam olarak bilmediğiniz sürece, kafamın üstünden STL kullanmak daha iyi bir fikirdir. neden kullanmak istemediğinizi .

İşte STL ile ilgili bir şey: sizden daha zeki insanlar tarafından geliştirilmiştir. Bu, rahatsız edici veya herhangi bir şey için tasarlanmadı, sadece STL, çalışmaları gerçekten STL'yi oluşturan insanlar tarafından geliştirilir. Platform izin verebileceği kadar pratikte hızlı olacak ve genellikle evden alınacak bir çözümden çok daha sağlam olacak (ve eğer daha fazla olmasa bile bu kadar endişe verici olmalı) ham hız konusunda endişelenmekten fazlası çünkü oyununuz ihtiyaç duyuyor) sağlamlık sizin hızınızdan gerekenden biraz daha fazladır; ikincisi eskisi olmadan anlamsızdır).

STL’nin “dünyanın dar görüşünü” yürüttüğü şikayetleri beni biraz aptallaştırıyor. Onlar konteyner. Sınırlı işlem kümeleri vardır, çünkü konteynerlerin sınırlı işlem kümeleri vardır. Ne yapıyorsun bununla başa çıkmıyor?

STL'yi oyunlarda kullanmamak için çok az neden gördüm.

Bellek ayırma sorunları için, birçok kişi bunu bilmez, ancak STL konteyner sınıflarınız için özel ayırıcılar yazabilirsiniz. Tahsisatçılar, temel olarak tahsislerin nasıl yapıldığını belirlemek için şablonlarınıza aktardığınız politika sınıflarıdır. Bunları kullanarak, genellikle tercih ettiğiniz platformda hangi bellek sorunlarının sorunlu olduğunu çözebilirsiniz.

Tabi ki, STL'yi kullanıyorsanız ve büyük, imleçsiz tiplere dizge haritaları gibi aptalca şeyler yapıyorsanız, o zaman elinizde daha büyük problemler vardır.

Varsayılan STL, özellikle bellek hizalama söz konusu olduğunda, oyunlarla kullanımını zorlaştıran çok sayıda soruna sahiptir.

EA STL gibi özelleştirilmiş bir model , oyunlar için özel olarak tasarlanmıştır ve size çok daha iyi bellek performansı ve konsol kullanılabilirliği sağlayabilir. 2016 yılında, BSH-3 maddesi uyarınca GitHub'ta bir depo ile açık kaynak oldu .

İşte burada Mike Acton (Dragon Spyro'nun Insomniac Oyunları Motor Direktörü, Cırcır ve Clank ve Direniş şöhreti) burada sorulduğunda bunu söylemek zorunda kaldı . Not dev oyunda kullanım ile ilgili olarak genel olarak hem STL hem de Boost hakkında bir soru soruldu.

STL / Boost, gamedev'e mi ait? Sadece bir kısmı varsa hangileri?

Burada iki farklı şey hakkında soru soruyorsun, değil mi? STL ve Boost, ayrı ayrı. Ama gerçekten, cevabım aynı: Her ikisinde de yanlış olan bir şey yok , ama kullanımlarını önermiyorum. Ya kullanımı için insanları teşvik sığdırmak yerine bir soruna çözüm bulma bir soruna çözüm. Çözüm her zaman eldeki veriler ve donanımın kısıtlamaları vb. İçin uygun olmalıdır. Hem STL hem de Boost “dünya” hakkında son derece dar bir görüşe sahiptir ve uygun kullanımları sınırlıdır. Gerçekten, onları caydırıyorum, çünkü programcıları hemen yanlış yöne doğru yönlendiriyorlar, sık sık ikisinden birine ihtiyacın olduğunu hissedersen, muhtemelen problemini anlamıyorsundur derim.

Profesyonel oyun geliştiricilerin çoğunun C'ye karşı C ++ 'dan daha çok çaba gösterdiğini de farkettim.

Kendinizi STL'de zaten var olan bir şeyi yeniden yazarken bulursanız, herhangi bir nedenle durdurun . STL'yi kullanın.

STL yıllarca süren analiz ve zaman boyunca optimize edilmiştir ve muhtemelen daha verimli bir şey yazamayacağınız güvenli bir bahis. Bu, daha basit bir çözümün mümkün olabileceği STL'yi kullanmanız gerektiği anlamına gelmez (yani, bilinen bir şey sayısına sahipseniz, bir stl :: listesini değil), ancak bir harita uygulamanızı yazıyorsanız ( temel veri yapısı, bir oyun dünya haritası değil), yanlış yapıyorsunuz.

STL oyunlar için uygun mu? Kesinlikle. Oyunlar karmaşık yazılım parçalarıdır, STL karmaşıklığı yönetmeye yardımcı olan özellikler sunar, bu yüzden iyidir.

Platformunuz için uygun mu? Şart değil. Bir konsol için yazıyorsanız, bellek ve önbellek kullanımı konusunda çok dikkatli olmalısınız. STL bunu kolaylaştırmaz.

Çok sık sık "oyunları", "gömülü veya ısmarlama donanımda çalışan yüksek performanslı gerçek zamanlı oyunlar" için yanlış yaptığımızı düşünüyorum, ancak bir ayrım yapmak önemlidir. Sabit bir 60fps hızında tam ekranda çalışmaya çalışmayan bir Windows oyunu yazıyorsanız, standart kütüphanenin size sunduğu araçlardan kaçınmanız için hiçbir neden yoktur.

Bunun partiye çok geç kaldığını biliyorum, ama zaman değişiyor ve cevaplar burada kalıyor. C ++ 11, birçoğu C ++ ve standart kütüphanesinin performansını artıracak oldukça kapsamlı değişikliklere sahip. Görünüşe göre STL veya Boost kullanmayanlar, yeni standartlara uymamaya meyilli, evdeki çözümleri önemli gelişmelerden mahrum bırakma eğiliminde görünüyorlar, elbette bu her zaman böyle değil.

EA'da kısa bir süre dışında 90'lı yılların ortasından günümüze her projede STL kullandım. STL karşıtı tarafın kullanmamak için bazı marjinal sebepleri olduğunu düşünüyorum. Bunlar büyük ölçüde gitti. Özel tahsisatçılar bir çözümdür, rezerv kullanmak başka bir şeydir ve şeyleri değerine göre geçirmemek üçte birdir, ancak bunlar oldukça basittir ve herhangi bir programcı bunları bilmelidir. Daha önemlisi, algoritmaların kullanılması olsa da. Derleyici yazarlar bir for_each () 'nin ne yaptığını tam olarak bilir ve kodu optimize edebilir. Bu bir ev haddelenmiş döngü ile gerçekleşemez. Bir const nesnesinde for_each () daha iyidir. Microsoft for_each serileştirme dahil olmak üzere birçok şekilde optimize eder. Ayrıca parallel_for_each () olan AMP kütüphanesine sahiptir. Şansınız varsa, derleyici mühendisleriyle bunun hakkında konuşun. Konsol derleyicileri, kullanılanları optimize edeceklerdir. Bir parça tavuk ve yumurta problemi. Microsoft C ++ 11 ile çok ağır gidiyor ve bir sonraki XBox farklı olmayacak. PS4 hakkında hiçbir fikrim yok, henüz bir tanesini almadık.

Özel ayırıcılar, bellek sorununu ele almanın bir yoludur, ancak başka (genellikle göz ardı edilen) bir seçenek, yeni sınıf tabanlı ve sil komutunu kullanmaktır. Büyük performans artışları bu şekilde olabilir.

Boost ve STL'nin problem çözme konusunda dar bir görüşü olduğu fikri saf delilik. STL ve Boost'taki kaç şeyin özellik ve politikalarla özelleştirilebildiğine şaşırdım. Bir örnek olarak case bağımsız dize karşılaştırması arayın.

Uzun bağlantı süreleri ve kod ihlaline ilişkin olarak, yeni harici şablon bu konuda yardımcı olmalıdır. Genel olarak, uzun derleme sürelerinin aşırı bağlanma ve pch'in yanlış kullanılmasından kaynaklandığını görüyorum.

STL'yi evde kullanmanın en zorlayıcı nedeni, STL'de size yardımcı olabilecek milyonlarca insanın bulunmasıdır. Her zaman olduğu gibi, erken optimize etmeyin ve test edin, test edin, test edin.

Bu oyun geliştirmede sıcak bir konudur. Şahsen ben tavsiye etmem, belki yukarıda belirtilen EASTL hariç. Oyunlarda STL ile ilgili iki temel sorunum var (teknik olarak "C ++ Standart Kütüphanesi", çünkü STL artık isim değil). 1) Dinamik bellek ayırma, STL kullanıldığında oyunlarda çoğu zaman boşa harcar. 2) STL kullanımı oyun mimarisine bir dizi yapı yaklaşımı teşvik ederken, bir dizi yapı yaklaşımı çok daha fazla önbellek dostudur.

Değişir. Proje ne kadar büyük, hangi platform (lar) ve zaman çizelgesi nedir?

Büyük bir projede, sınırlı kaynaklara sahip platformlarda, önemli bir zaman çizelgesi ve bütçeye sahipseniz, yarım milyon satırlık bir kod tabanına bakacak kaçınılmaz cehennemden kaçınarak kendinizi çok fazla beladan kurtarabilirsiniz. STL ile dolu, 30'un üzerinde bir kare hızını koruyamıyor, birkaç varlığa daha fazla sığacak kadar RAM yiyor ve yapımı 2 saat sürüyor.

Bununla birlikte, diğer durumlarda, uygun şekilde uygulandığında STL ve hatta Boost çok faydalı olabilir. Bir STL / Boost seçkisi kullanan başlıklar üzerinde çalıştım ve kod için mutlak bir hayaldi: daha az hata / sızıntı ve bakımı kolay kod daha fazla zaman kodlaması daha eğlenceli yeni özellikler demektir! Özellikle hobi projeleri için motivasyon departmanında büyük bir kazanç.

Performans için ne zaman işlem yapabileceğinizi öğrenin!

IMHO, STL'nin zaten iyi çalıştığı ve yapılan işler için optimize edildiği için uygun olduğunu söyleyebilirim. Ayrıca, bir oyun üzerinde çalışıyorsunuz, bu yüzden elinizde bulunan araçları kullanarak hayatınızı kolaylaştıracak ve kodunuzu hatalara daha az açık hale getireceksiniz.

Oyunun AI, kullanıcı deneyimi veya daha iyisi gibi başka bir şey üzerinde çalışırken, neden tekerleği yeniden icat etmeye zahmet ettin; test etme ve hata ayıklama?

STL iyi anladığınız sürece oyunlarda kullanım için kesinlikle iyidir. Motorumuz onu oldukça kapsamlı kullanıyor ve bu hiç sorun olmamıştı. Tamamen farklı bir hikaye olabilecek konsol geliştirme konusunda hiçbir deneyimim yok, ancak tüm PC platformlarında (Windows / Mac / Linux) iyi destekleniyor.

En önemli şey, her bir konteyner türünün güçlü ve zayıf yönlerinin ne olduğunu anlamak ve yaptığınız iş için doğru konteynerin seçilmesidir.

Eski işverenim, sağlam bir özel konteyner sınıfları setini kullanmaktan STL'ye geçti. Derleme zamanları arttı ve hata ayıklama kolaylığı düştü. Sıfırdan başlamış olsaydık, STL (belki de daha iyi kullanıldı) muhtemelen mantıklı olurdu, ancak STL'ye geçerken çalışma, hızlı, hata ayıklama kodunu atmayı haklı çıkaracak hiçbir şey kazanmadığı açık değildi.

Kişisel projelerim için STL'nin uygun olup olmadığı projeye bağlı. Bazı Mike Acton tarzı veri odaklı, bellek ve önbellek erişimi için optimize edilmiş işler yapmaya çalışıyorsam, en azından kendi özel veri yapılarını yuvarlamayı düşüneceğim. Bazı algoritmaları veya oynanışı prototipliyorsam ve performans, ölçeklenebilirlik, hedef platform vb. İle ilgilenmiyorsam, otomatik olarak STL'yi yakalayacağım.

Bu konuda 2 sentim, STL'nin gayet iyi çalıştığı yönünde. PC için bir 3D oyun motoru geliştiriyorum (AAA kalitesi değil, ancak yeterince gelişmiş - kodlu varlık türleri, ertelenmiş oluşturucu, tümleşik Bullet fiziği) ve henüz kapların ana tıkanıklığı olduğunu görmedim. Yanlış 3D API kullanımı ve zayıf algoritmalar, her girdiğimde ve biraz daha fazla performans göstermeye çalıştığımda (profil oluşturma!) En iyi hedeflerdi.

STL kullanarak oyunlar yaptım ve hoşuma gitti ve iyi performans gösteriyor.

İyi soru! Daha belirgin bir soru, bir oyunun STL ve Boost ile karşılanamayacağı bazı genel gereklilikler nelerdir.

Tecrübelerime göre, konsol donanımının sınırlı bellek sınırlamaları, özel ayırıcınız ne kadar zekice olursa olsun, her tür dinamik boyutlu kabı kötü bir fikir haline getirir. Kasıtlı sınırları olmayan kaplar, programcıları, veri kümelerinin sınırlarını zorlamayan kodlar yazmaya teşvik eder. İzlemesi zor olan sayısız değişkene bağlı olarak, hafıza sınırlamalarınızı aşabilirsiniz. Modern oyunlarda bunun dengesizliğin temel nedenlerinden biri olduğuna dair bir fikrim var.

Ek olarak, şablonların aşırı kullanımı, büyük bir kod tabanında çok uzun derleme sürelerine yol açabilir ve artık bir ps3'teki yardımcı çekirdeğin önbelleğine sığmayacak şekilde çalıştırılabilir boyutunuzu şişirir.

Ancak, sadece PC geliştirme için STL ve Boost'un çok iyi olduğunu düşünüyorum. Genel durum çözümleri her zaman ideal olmamakla birlikte, genellikle yeterince iyidirler. Bir probleme ilk çözümünüz neredeyse hiç ideal değildir ve yeteri kadar iyi olana kadar yetersizlikleri iyileştirir veya değiştirirsiniz.

STL oyununuz için uygunsa, STL oyununuz için iyi bir seçimdir.

Geliştirme sırasında yapılan tüm teknoloji seçeneklerinde olduğu gibi, artıları ve eksileri tartmanız gerekir - kendi kütüphanemi yayınlamak bana STL'yi kullanmaktan daha faydalı bellek kullanımı, performansı ve üretkenlik sağlayacak mı? Muhtemelen; vectordaha fazla bellek kullanan, daha yavaş olan ve zaten var olana kıyasla işlevini sürdürmek için büyük miktarda bakım gerektiren bir uygulama oluşturmak çok kolaydır .

İnsanlar oyunlarında STL'yi kullanmaktan kaçınmamalıdır, çünkü diğer kişiler oyunlarda STL'yi kullanmaktan kaçınır; Tüm seçeneklerini tartıyorlarsa kullanmaktan kaçınmaları gerekirdi ve başka bir uygulamanın ürünlerinin kalitesini artıracağına gerçekten inanıyorlardı .

Çoğu soruda olduğu gibi cevap hiçbir zaman "evet veya hayır", siyah veya beyaz değildir. STL bazı problemler için iyi bir seçimdir, bu problemlerde kullanmak iyi olmalı. İşe yaramaz olduğunu varsaymak bir hatadır, ancak her durumda kullanmanın uygun olduğunu varsaymak da bir hatadır.

Oyun geliştirmede STL kullanırken dikkat edilmesi gereken en önemli husus hafıza tahsisidir. STL'nin varsayılan tahsisçileri, oyun geliştirme için tercih edilen tahsis stratejilerine uygun görünmüyor. Elbette özel tahsis ediciler kullanılabilir, ancak STL'yi STL olmayan bir kod tabanına eklemek isteyip istemediğinizi düşünüyorsanız, bu bütün fikri daha az çekici hale getirir.

Buna ek olarak, kod tabanınız STL değilse, özel ayırıcıları doğru şekilde uygulamak için STL veya şablon kavramlarını bilen hiç kimseye sahip olamayabilirsiniz.

Bence bu tartışma şu şekilde özetlenebilir:

vasat yazılmış uygulamaya özgü kod <iyi yazılmış genel amaçlı kod <iyi yazılmış uygulamaya özel kod

Evde yetiştirilen çözümü kategori 3'e girecek olan herkes, kesinlikle kendi sorunlarına yönelik orijinal sorunun cevabını bilir. STL kategori 2'ye giriyor. Bu nedenle, " STL kullanmalı mıyım " sorusunu sorması gereken biri için cevap muhtemelen evet.

STL, bir bilgisayarda kullanım için uygundur, çünkü gelişmiş sanal bellek sistemi, dikkatli bellek tahsisine olan ihtiyacı biraz daha az önemli kılar (yine de çok dikkatli olmasına rağmen). Sınırlı veya hiç bellek belleği bulunmayan veya aşırı derecede önbellek maliyetlerinin düşük olduğu bir konsolda, muhtemelen tahmin edilebilir ve / veya sınırlı bellek ayırma kodları olan özel veri yapıları yazarken daha başarılı olursunuz. (Ve aynı zamanda bir PC oyun projesinde de aynı şeyi yapmakta kesinlikle yanlış gitmeyeceksiniz.)

Bu soru gerçekten büyük bir sorulmamış bir soru olduğunu düşünüyorum - kullanmalıyım X benim de Y ? Ve bunu gerçekten yanıtlamanın tek yolu, bunu kendin denemek. X’in harika çalıştığını söyleyen her kişi için, bunun korkunç olduğunu söyleyen birini bulacaksınız. Ve her ikisi de haklıdır - projeleri için.

Yazılımla ilgili en güzel şey, çoğu diğer disiplinin aksine, istediğiniz şekilde çalışmadığını tespit ederseniz, daha sonra her zaman bir şeyleri değiştirebilmenizdir. Daha sonra STL'nin bu projede sizin için çalışmadığını öğrendiniz mi? Çıkartın, yerine başka bir şey yerleştirin. Görevleri nesneler arasında paylaştırmayı sevmiyor musun? Elden Geçirme. Nesne kullanman hoşuna gitmedi mi? Bunları düz C yöntemleriyle değiştirin. Her şeyi yapıları ve yöntemleriyle saklamaktan hoşlanmıyor musunuz? Bunları C ++ nesnelerle değiştirin.

Ben STL'ye hayır diyorum. Nedenim oldukça basit:

1. Oyun yazmak için STL'ye ihtiyacınız yok. Büyük olanları bile değil.
2. STL derleme sürenizi önemli ölçüde artırır.
3. Büyük derleme zamanı, gelişiminiz üzerinde daha az yinelenmeye neden olur.

Yineleme sayısını en büyük öneme sahip tutarım, bu yüzden sadece STL'den ve yinelemeleri yavaşlatan başka herhangi bir geliştirme tekniğinden (bunun için yapmak için mimarlık yapmak veya derlenmesi gereken komut dosyası dilleri gibi) uzak duruyorum.

Pahalı tekrarlamalar, aslında çok az bir şeyle işleri halletmeye çalışan büyük geliştirme ekiplerine yol açar. Onu gördüm ve duydum ve suçlulardan biri şablon kütüphaneleri için derleme zamanları gibi görünüyor.