OOP

'da "kuplaj" dan nasıl kaçınırım Tamam, birleştirme sorununun gerçekten açıklandığını bilmiyorum. Sorun şu ki, ogre'ye dayanarak kendi 3d oyun motorumunu oluşturuyorum. Ben de bir fizik kütüphanesi olan PhysX'i kullanıyorum, fakat ana motor kodumla PhysX arasında bir soyutlama katmanı oluşturmam gerektiğinden, başka bir fizik motoru kullanabilmem için - bir sarıcı, Quantum yaratmaya karar verdim. OOP

Yani dev de PhysX aktör konumunda çalıştığı hakkında bilgi içeren bir PxActor sınıf var ekranın
PhysX varlık kontrol edecek bir Varlık sınıf var.
kuantum sargı, son olarak motor, en az iki üye sahip olacak şekilde, varlık sınıf olacak motor ve PhysX
arasında bir tabaka olarak hareket edecek bir QEntity sınıf olacak ogre varlık nesnesi ve kuantum varlığı. Her bir update()'da QEntity'den neyin istendiğini ve ogre varlık pozisyonunu güncelleyeceğini sorar.

Sorununu çözme? Bir varlık için 4 sınıf? Ve dört varlığa en az 60 kez/s erişmemiz gerektiğini unutmayın! Peki veri bölümleme hakkında ne? Gerçekten optimize edilmemiş. Bunun yanı sıra, AI için bir sınıf, bir komut dosyası motoru için daha fazla sınıf olabilir ...

kaynak

2014-12-17 Vinz243

Acılarınızı hissediyorum. Her ne zaman bir oyun kurmaya çalıştığımı ve kuplajı en aza indirdiğim zaman, sadece büyük miktarda argümanla başka işlevleri çağrıştıran büyük işlev zincirleriyle sonuçlanırım. – SlySherZ

Birden fazla bağlamdaki nesneleri birden çok bağlamda göstermek, kendi başına kötü bir şey değildir. Aslında, tüm bu bağlamlarda aynı nesneyi kullanmış olsaydınız, örneğin, birden fazla kalıtımın yaratıcı kullanımı yoluyla daha da kötü olurdu.

Sizin QEntity sınıf zaten sizi ayırımı yok - sürece onun arayüzüne programlamak ve PhysX özgü sınıfları izin vermez olarak ^*QEntity arayüzünden "ortaya koyma", sen iyi.

Projenizin, tam olarak bulunduğu yere ait "köprü" sınıflarında birleştirme oluşturduğu anlaşılıyor. Orada tuttuğun sürece, tasarımın bir bağlantı sorunu olmazdı.

60 FPS'ye gittiği sürece, tasarım aşamasında çok fazla endişelenmeyin. Sanal işlevlere dayanan uzun bir sorumluluk zinciri olmadığı sürece, derleyiciniz sizin için iyi bir iş yapabilmelidir.

^* örneğin QEntity parametrelerini kabul ya da bir "kapsayıcı" yaratan bir yapıcı haricinde PhysX özgü nesneleri döndüren olmamalıdır.

kaynak

2014-12-17 19:17:32 dasblinkenlight

Teşekkürler, bu yüzden sonunda kötü değil. Sadece bir soru: veri bölümleme böyle bir kalıp ile çalışacak mı? Yani, Ogre varlığı ve PxActor bellekte birbirinden uzak olabilir, bu yüzden L3 önbelleği işe yaramıyordu. – Vinz243

@ Vinz243 Bu, uygulamaya bağlı olarak değişir. İki API, Ogre öğesine ve PxActor'a işaretçiler aracılığıyla erişmenizi gerektiriyorsa (bunları değer olarak kullanmanıza izin vermektense), veriler farklı bellek bölgelerinde sonlanabilir.Nesnelerinizi kendi içlerine gömmenize izin veriyorlarsa, ilgili iki nesne, bellekte birbirinin yanına gelecektir. L3 önbellek etkileriyle ilgili mantığınız genellikle çok erken, en azından bir prototip üzerinde, gerçek sistem değilse bile, kodlamanın tamamlanmasına kadar ve kesinlikle profilden önce çok erken ve kodunuzdaki "düşük asılı meyve" yi ortadan kaldırır. – dasblinkenlight

Eğer bir sakıncası yoksa son bir soru: Birden fazla varlık bulunduğundan, ad alanlarını kullanmalı veya Quantum Entity QEntity adını mı kullanmalıyım? – Vinz243

cevap

İlgili konular