Soru
Gerçekten büyük görüntüler (donanımınızın destekleyebileceğinden daha büyük) kullanan bir 2D oyununuz varsa, ne yaparsınız? Belki de bu sorunun bana daha önce hiç gelmemiş ilginç bir çözümü var.
Temelde bir tür grafik macera oyunu yapımcısı üzerinde çalışıyorum. Hedef kitlem, oyun geliştirme (ve programlama) deneyimi çok az olan veya hiç olmayan kişilerdir. Böyle bir uygulama ile çalışıyorsanız, "resimlerinizi bölmeye gitmenizi" söylemek yerine sorunu dahili olarak ele almayı tercih etmez misiniz?
bağlam
Grafik kartlarının, kullanabilecekleri dokuların boyutu üzerinde bir dizi kısıtlama getirdiği iyi bilinmektedir. Örneğin, XNA ile çalışırken, seçtiğiniz profile bağlı olarak maksimum 2048 veya 4096 piksel doku boyutuyla sınırlandırılırsınız.
Genellikle bu, 2D oyunlarda çok fazla sorun yaratmaz, çünkü çoğunun daha küçük münferit parçalardan (örneğin fayanslar veya dönüştürülmüş spritelar) inşa edilebilen seviyeleri vardır.
Ancak birkaç klasik point'n'click grafik macera oyununu düşünün (örneğin Monkey Island). Grafik macera oyunlarındaki odalar, tıpkı bir manzara üzerinde çalışan bir ressam gibi, genellikle tekrarlanabilir bölümleri olan veya hiç olmayan bölümlerle bir bütün olarak tasarlanmıştır. Ya da önceden oluşturulmuş büyük geçmişleri kullanan Final Fantasy 7 gibi bir oyun.
Bu odaların bazıları oldukça geniş olabilir, sıklıkla üç veya daha fazla genişliğe sahiptir. Şimdi bu arka planları modern bir yüksek tanımlı oyun bağlamında ele alırsak, desteklenen maksimum doku boyutunu kolayca aşacaklar.
Şimdi, bunun bariz çözümü, arka planı gereksinimlere uyan daha küçük bölümlere ayırmak ve yan yana çizmektir. Ama siz (ya da sanatçınız) tüm dokularınızı ayıran kişi olmalısınız?
Yüksek düzeyli bir API ile çalışıyorsanız, belki de bu durumla başa çıkmaya ve dokuların dahili olarak bölünmesine ve birleştirilmesine (XNA'nın İçerik Pipeline'ı gibi bir ön işlem olarak veya çalışma zamanında) hazır olmamalı mı?
Düzenle
İşte XNA uygulama açısından düşündüğüm şey.
2D motorum yalnızca çok küçük bir Texture2D işlevselliği alt kümesi gerektirir. Aslında bu arayüze indirgeyebilirim:
public interface ITexture
{
int Height { get; }
int Width { get; }
void Draw(SpriteBatch spriteBatch, Vector2 position, Rectangle? source, Color color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth);
}Texture2D dayanır kullandığım tek dış yöntem SpriteBatch.Draw () yani bir uzantı yöntemi ekleyerek aralarında bir köprü oluşturabilirsiniz:
public static void Draw(this SpriteBatch spriteBatch, ITexture texture, Vector2 position, Rectangle? sourceRectangle, Color color, float rotation, Vector2 origin, Vector2 scale, SpriteEffects effects, float layerDepth)
{
texture.Draw(spriteBatch, position, sourceRectangle, color, rotation, origin, scale, effects, layerDepth);
}Bu, daha önce bir Texture2D kullandığımda bir ITexture'ı birbirinin yerine kullanmamı sağlayacaktı.
Sonra RegularTexture'ın normal bir Texture2D'yi basitçe saracağı RegularTexture ve LargeTexture gibi iki farklı ITexture uygulaması oluşturabilirim.
Öte yandan, LargeTexture, her biri tam görüntünün bölünmüş parçalarından birine karşılık gelen bir Doku2D Listesi tutar. En önemli bölüm, LargeTexture üzerinde Draw () yönteminin çağrılması tüm dönüşümleri uygulayabilmeli ve tüm parçaları tek bir bitişik görüntüymiş gibi çizebilmelidir.
Son olarak, tüm süreci şeffaf hale getirmek için, bir Fabrika Yöntemi olarak hareket edecek birleşik bir doku yükleyici sınıfı yaratacağım. Dokunun yolunu bir parametre olarak alır ve sınırı aşan görüntü boyutuna bağlı olarak RegularTexture veya LargeTexture olan bir ITexture döndürür. Ancak kullanıcının hangisi olduğunu bilmesine gerek yoktu.
Biraz abartılı mı yoksa kulağa iyi geliyor mu?