Game Boy Color पर रियल-टाइम 3D shader लागू किया गया

 (blog.otterstack.com)
1 पॉइंट द्वारा GN⁺ 2026-02-09 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • यह एक ऐसा प्रोजेक्ट है जिसमें Game Boy Color पर रियल-टाइम 3D shading लागू की गई है, और खिलाड़ी प्रकाश की कक्षा को नियंत्रित करते हुए वस्तु को घुमा सकता है
  • normalized vectors और Lambert shading (dot product) की गणना के आधार पर, spherical coordinates का उपयोग करके ऑपरेशन को सरल बनाया गया है
  • multiplication instruction के बिना SM83 CPU की सीमाओं को पार करने के लिए log transform और lookup tables का उपयोग किया गया, और 8-bit precision पर गणना की गई
  • self-modifying code का उपयोग करके लगभग 10% performance improvement हासिल किया गया, और प्रति frame 15 tiles render किए गए
  • AI की मदद से code generation के अधिकांश प्रयास विफल रहे, और मुख्य algorithm व shader को सीधे हाथ से लिखे गए code से पूरा किया गया

प्रोजेक्ट का अवलोकन

  • Game Boy Color पर रियल-टाइम में image render करने वाला game बनाया गया
    • खिलाड़ी कक्षा-आकार की रोशनी को नियंत्रित करते हुए वस्तु को घुमाता है
  • पूरा code GitHub repository(nukep/gbshader) में सार्वजनिक है

3D बनाने की प्रक्रिया

  • शुरुआती lookdev के लिए Blender का उपयोग किया गया, और दृश्य परिणाम संतोषजनक होने पर प्रोजेक्ट आगे बढ़ाया गया
  • Cryptomatte और custom shader का उपयोग करके normal map बनाया गया
    • teapot model में camera को घुमाकर PNG sequence के रूप में normal map output किया गया
    • Game Boy Color model के screen हिस्से को अलग scene में render करके बाद में composite किया गया

गणितीय आधार

  • normal map को हर pixel के normal vector को encode करने वाले vector field के रूप में उपयोग किया गया
  • Lambert shading को v = N·L रूप के dot product से गणना किया गया
  • spherical coordinates में बदलकर इसे v = sinNθ sinLθ cos(Nφ−Lφ) + cosNθ cosLθ रूप में सरल बनाया गया
    • सभी vectors के लिए radius r=1 मानकर गणना की मात्रा घटाई गई

Game Boy पर implementation

  • Lθ (प्रकाश का vertical angle) को स्थिर constant रखा गया, और Lφ (प्रकाश का rotation angle) को ही खिलाड़ी नियंत्रित करता है
  • ROM में हर pixel को (Nφ, log(m), b) रूप में store किया गया
  • multiplication instruction की अनुपस्थिति को हल करने के लिए log transform और lookup tables (log, pow) का उपयोग किया गया
    • negative operations को support करने के लिए sign bit को upper bit में store किया गया
  • सभी scalar values को -1.0~+1.0 range के 8-bit fraction के रूप में व्यक्त किया गया
    • addition linear space में, जबकि multiplication log space में किया गया
    • denominator के रूप में 127 का उपयोग किया गया ताकि ±1 दोनों को व्यक्त किया जा सके

cos_log और मुख्य गणना

  • cos_log एक combined lookup है जो log(cos x) रूप में काम करता है, और multiplication को log addition से बदल देता है
  • प्रति pixel गणना मात्रा
    • 1 subtraction, 1 cos_log lookup, 1 addition, 1 pow lookup, 1 addition
    • कुल 3 additions/subtractions और 2 lookups

प्रदर्शन

  • प्रति frame 15 tiles प्रोसेस किए जाते हैं, और कुछ खाली rows को इससे भी तेज़ी से गणना किया जा सकता है
  • प्रति pixel लगभग 130 cycles लगते हैं, जबकि खाली row में 3 cycles लगते हैं
  • CPU का लगभग 89% shader calculations में उपयोग होता है, और बाकी input व I/O processing में

Self-Modifying Code

  • प्रति frame लगभग 960 pixels को प्रोसेस करने वाले मुख्य loop को optimize करने के लिए instructions को ही modify किया गया
    • constants को सीधे code में डालकर variable load की तुलना में तेज़ operation किया गया
    • उदाहरण: sub a, 8, sub a, variable की तुलना में 12 cycles तेज़ है
    • कुल मिलाकर लगभग 11,520 cycles (10%) की बचत हुई

AI उपयोग के प्रयास

  • पूरे प्रोजेक्ट का 95% हिस्सा हाथ से लिखा गया
  • AI को Game Boy assembly (SM83) लिखने में कठिनाई हुई
  • AI का उपयोग
    • Python: OpenEXR layers पढ़ना
    • Blender: scene automation scripts
    • SM83: कुछ function snippets (जैसे VRAM DMA)
  • विफल प्रयास
    • AI से shader assembly code generate कराने की कोशिश → अक्षम और कई त्रुटियों वाला परिणाम
  • Claude Sonnet 4 model की मदद से pseudocode से assembly generate करने की कोशिश की गई
    • कुछ हिस्सा काम किया, लेकिन धीमा था और Z80 व SM83 को गड़बड़ करने जैसी त्रुटियाँ हुईं
    • अंतिम code को हाथ से पूरी तरह फिर से लिखा गया

निष्कर्ष और सीख

  • AI साधारण scripts के लिए उपयोगी हो सकती है, लेकिन सटीकता और verification अनिवार्य हैं
  • OpenEXR processing code में AI ने channel order error (BGR vs RGB) पैदा किया, जिससे कई हफ्तों तक bug बना रहा
  • अनुभव से यह सीख सामने आई कि “AI का उपयोग करते समय verification सबसे महत्वपूर्ण है”
  • इस प्रोजेक्ट को legacy hardware की सीमाओं को पार करने वाले एक प्रयोगात्मक shader implementation के उदाहरण के रूप में देखा जा सकता है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.