सवाल
जब आपके पास एक 2D गेम होता है जो वास्तव में बड़ी छवियों (आपके हार्डवेयर से बड़ा समर्थन कर सकता है) का उपयोग करता है, तो आप क्या करते हैं? शायद इस समस्या का कुछ दिलचस्प समाधान है जो मुझे पहले कभी नहीं हुआ था।
मैं मूल रूप से ग्राफिक एडवेंचर गेम मेकर की तरह काम कर रहा हूं। मेरे लक्षित दर्शक ऐसे लोग हैं जिनके पास कोई गेम डेवलपमेंट (और प्रोग्रामिंग) अनुभव नहीं है। यदि आप इस तरह के एक अनुप्रयोग के साथ काम कर रहे थे, तो क्या आप "अपनी छवियों को विभाजित करने" के लिए कहने के बजाय आंतरिक रूप से समस्या को संभालना पसंद नहीं करेंगे?
प्रसंग
यह अच्छी तरह से ज्ञात है कि ग्राफिक कार्ड उन बनावटों के आकार पर प्रतिबंध का एक सेट लगाते हैं जो वे उपयोग कर सकते हैं। उदाहरण के लिए, जब आप XNA के साथ काम कर रहे हों, तो आप अधिकतम 2048 या 4096 पिक्सल के टेक्सचर साइज़ तक सीमित रह जाते हैं।
आमतौर पर यह 2 डी गेम में बहुत अधिक समस्या पैदा नहीं करता है क्योंकि उनमें से अधिकांश में छोटे व्यक्तिगत टुकड़ों (जैसे टाइल या परिवर्तित स्प्राइट) से निर्माण किए जा सकते हैं।
लेकिन कुछ क्लासिक point'n'click ग्राफिक एडवेंचर गेम्स (जैसे मंकी आइलैंड) के बारे में सोचें। ग्राफिक एडवेंचर गेम्स के कमरों को आमतौर पर एक पूरे के रूप में डिजाइन किया जाता है, जिसमें परिदृश्य पर काम करने वाले चित्रकार की तरह बहुत कम या कोई दोहराए जाने वाले खंड नहीं होते हैं। या शायद फाइनल फंतासी 7 जैसा गेम जो बड़े प्री-रेंडर बैकग्राउंड का उपयोग करता है।
इनमें से कुछ कमरे बहुत बड़े हो सकते हैं, जिनमें अक्सर तीन या अधिक स्क्रीन की चौड़ाई होती है। अब अगर हम आधुनिक उच्च परिभाषा खेल के संदर्भ में इन पृष्ठभूमि पर विचार करते हैं, तो वे आसानी से अधिकतम समर्थित बनावट आकार से अधिक हो जाएंगे।
अब, इसका स्पष्ट समाधान पृष्ठभूमि को छोटे वर्गों में विभाजित करना है जो आवश्यकताओं के भीतर फिट होते हैं और उन्हें कंधे से कंधा मिलाकर खींचते हैं। लेकिन क्या आपको (या आपके कलाकार) को आपके सभी बनावटों को विभाजित करना होगा?
यदि आप एक उच्च स्तर के एपीआई के साथ काम कर रहे हैं, तो क्या यह शायद इस स्थिति से निपटने के लिए तैयार नहीं होना चाहिए और आंतरिक रूप से बनावट के विभाजन और संयोजन करना चाहिए (या तो एक पूर्व-प्रक्रिया जैसे कि XNA की सामग्री पाइपलाइन या रनटाइम पर)?
संपादित करें
यहाँ मैं जो सोच रहा था, एक XNA कार्यान्वयन के दृष्टिकोण से।
मेरे 2D इंजन को केवल Texture2D की कार्यक्षमता का एक बहुत छोटा सा हिस्सा चाहिए। मैं वास्तव में इसे इस इंटरफ़ेस के लिए कम कर सकता हूं:
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 पर निर्भर करता है, SpriteBatch.Draw () है, इसलिए मैं एक एक्सटेंशन विधि जोड़कर उनके बीच एक पुल बना सकता हूं:
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);
}इससे पहले कि जब भी मैंने एक Texture2D का उपयोग किया था, यह मुझे एक विनिमेय रूप से उपयोग करने की अनुमति देगा।
तब मैं ITexture के दो अलग-अलग कार्यान्वयन बना सकता था जैसे RegularTexture और BigTexture, जहाँ RegularTexture बस एक नियमित Texture2D लपेटेगा।
दूसरी ओर, लार्जटेक्स्चर बनावट की सूची को पूरी छवि के विभाजित टुकड़ों में से प्रत्येक के अनुरूप रखेगा। सबसे महत्वपूर्ण हिस्सा यह है कि लार्जक्राफ्ट पर कॉलिंग ड्रा () सभी परिवर्तनों को लागू करने और सभी टुकड़ों को आकर्षित करने में सक्षम होना चाहिए जैसे कि वे सिर्फ एक सन्निहित छवि थे।
अंत में, पूरी प्रक्रिया को पारदर्शी बनाने के लिए, मैं एक एकीकृत बनावट लोडर वर्ग बनाऊंगा जो कि फैक्टरी विधि के रूप में कार्य करेगा। यह एक पैरामीटर के रूप में बनावट का रास्ता अपनाएगा और एक ITexture लौटाएगा जो या तो एक RegularTexture या एक BigTexture होगा जो कि सीमा से अधिक छवि आकार के आधार पर होगा या नहीं। लेकिन उपयोगकर्ता को यह जानने की जरूरत नहीं थी कि यह कौन सा है।
थोड़ा ओवरकिल या क्या यह ठीक लगता है?