2 पॉइंट द्वारा GN⁺ 2025-10-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • rlsw एक OpenGL 1.1 शैली का सॉफ़्टवेयर रेंडरर है, जो GPU के बिना वातावरण में भी raylib चलाने के लिए एक वैकल्पिक बैकएंड प्रदान करता है।
  • बिंदु, लाइन, त्रिभुज, क्वाड जैसे विभिन्न रेंडरिंग मोड के साथ क्लिपिंग, टेक्सचर, मल्टीकलर/डेप्थ बफर जैसी व्यापक फीचर सपोर्ट प्रदान करता है।
  • टेक्सचर में raylib द्वारा समर्थित सभी non-compressed फॉर्मेट इस्तेमाल किए जा सकते हैं, और फिल्टरिंग व रैपिंग सेटिंग को भी बारीकी से नियंत्रित किया जा सकता है।
  • मैट्रिक्स स्टैक, डेप्थ टेस्ट, ब्लेंड, क्यूल फेस जैसे मुख्य 3D ग्राफ़िक्स फीचर इन-बिल्ट हैं, और OpenGL फंक्शन बाइंडिंग का उपयोग करके कम्पैटिबिलिटी को अधिकतम किया गया है।
  • आकार 5 हजार लाइन से कम है, इसलिए परफॉर्मेंस और lightweight के मामले में अन्य सॉफ़्टवेयर रेंडरर की तुलना में सादगी और इंटीग्रेशन में यह मजबूत है।

rlsw: Raylib सॉफ़्टवेयर OpenGL रेंडरर का ओवरव्यू

परिचय

  • rlsw एक OpenGL 1.1 शैली का सॉफ़्टवेयर रेंडरर है, जो raylib के rlgl.h में उपलब्ध सभी फंक्शंस को सॉफ़्टवेयर में इम्प्लीमेंट करने वाली लाइब्रेरी है।
  • यह डायरेक्ट अल्टरनेट बैकएंड के रूप में डिज़ाइन किया गया है, ताकि GPU ही न होने पर भी raylib को चलाया जा सके।

प्रमुख फीचर

  • कस्टम इंटर्नल फ्रेमबफ़र पर रेंडरिंग की जाती है और विविध कलर/डेप्थ मोड (RGB 8, 16, 24bit, Depth 8/16/24bit) का समर्थन करती है।
  • सपोर्टेड रेंडरिंग मोड: पॉइंट, लाइन, त्रिभुज, क्वाड
    • पॉइंट की मोटाई, लाइन की चौड़ाई, पॉलिगन मोड जैसी अतिरिक्त रेंडरिंग डिटेल सेटिंग्स संभव हैं।
    • सभी रेंडरिंग मोड में क्लिपिंग सपोर्ट होता है।
  • टेक्सचर फीचर: raylib में समर्थित सभी non-compressed फॉर्मेट सपोर्ट किए गए हैं।
    • मिनिफिकेशन/मैग्नीफिकेशन चेक
    • पॉइंट/बाइलीनियर फिल्टरिंग
    • S/T कोऑर्डिनेट-आधारित Wrap मोड का सूक्ष्म अनुप्रयोग
  • वर्टेक्स एरे को सीधे सपोर्ट करता है, इसलिए प्रिमिटिव ड्रॉइंग तुरंत संभव है।
  • मैट्रिक्स स्टैक (Push/Pop) सपोर्ट करता है।
  • अन्य फीचर्स: OpenGL शैली getter, फ्रेमबफ़र resize, परस्पेक्टिव कोरेक्शन, सिज़र क्लिपिंग, डेप्थ टेस्ट, ब्लेंड, क्यूल फेस

उपयोग और कस्टमाइज़ेशन

  • single header & source स्ट्रक्चर में उपलब्ध है, और #define RLSW_IMPLEMENTATION से implementation बनाया जा सकता है।
  • बिल्ड से पहले कई micro सेटिंग constants के जरिए यूज़र-कस्टमाइज़ेशन संभव है।
    • उदाहरण: फ्रेमबफ़र या टेक्सचर की अधिकतम संख्या/साइज़ समायोजित करना

संरचना और प्रकार

  • कई OpenGL-compatible enum और प्रकार, तथा internal स्ट्रक्चर्स (sw_vertex_t, sw_texture_t आदि) परिभाषित हैं।
  • OpenGL कॉल का अधिकांश भाग rlsw फंक्शंस में remap करके विकल्प के रूप में उपयोग किया जा सकता है।
  • कई प्रकार के मैट्रिक्स और स्टेट, टेक्सचर मैनेजमेंट आदि के लिए मजबूत internal state management स्ट्रक्चर मौजूद है।

लाइसेंस और उपयोग

  • MIT लाइसेंस के कारण व्यावसायिक/गैर-व्यावसायिक और अन्य derivative उपयोगों के लिए स्वतंत्रता से इस्तेमाल किया जा सकता है।
  • परफॉर्मेंस से ज़्यादा lightweight और पूर्ण सॉफ़्टवेयर-रेप्लेसमेंट प्रकृति पर फोकस होने के कारण आसान इंटीग्रेशन और deployment में मजबूत पक्ष है।

विस्तृत सारांश

हेडर स्ट्रक्चर और व्याख्या

  • rlsw लगभग पूरी OpenGL 1.1 फ़ंक्शनलिटी को फंक्शन-स्तर पर सॉफ़्टवेयर से रिप्लेस करता है।
  • rlsw.h हेडर में निम्नलिखित परिभाषाएँ मौजूद हैं:
    • वैल्यू टाइप, कस्टम enum और struct
    • मैक्रो द्वारा OpenGL commands को rlsw internal फंक्शंस से बदलना
    • API डिक्लेरेशन सेक्शन (इनिशियलाइजेशन, फ्रेमबफ़र कॉपी/अधिग्रहण, draw, clear, vertex/texture इनपुट आदि)

प्रतिनिधि फीचर

  • अंदरूनी तौर पर multi-stack मैट्रिक्स सपोर्ट (Projection/ModelView/Texture के लिए अलग-अलग) दिया गया है।
  • रेंडर स्टेट मैनेजमेंट: Scissor, टेक्सचर एनैबल या Depth Test जैसी स्टेट बिट मैनिपुलेशन।
  • OpenGL के साथ कम्पैटिबिलिटी फीचर: विभिन्न getter, स्टेट कॉपी, error handling
  • टेक्सचर हैंडलिंग: non-compressed फॉर्मेट, filter/wrap मोड, मेमोरी कॉपी आदि
  • डिफ़ॉल्ट रूप से अधिकांश 2D/3D प्रकार के shape (डॉट, लाइन, त्रिभुज, क्वाड) के साथ कलर और डेप्थ प्रोसेसिंग संभव है।

कस्टमाइज़ करने योग्य सेटिंग्स

  • फ्रेमबफ़र/टेक्सचर resolution और काउंट, कलर/डेप्थ बफर bit-width, मैट्रिक्स स्टैक depth, max टेक्सचर count आदि।
  • SW_MAX_CLIPPED_POLYGON_VERTICES जैसी advanced यूज़र-level ट्यूनिंग संभव है।

अंदरूनी स्ट्रक्चर के प्रमुख तत्व

  • sw_context_t: पूरा कंटेक्स्ट स्टेट, सभी बफ़र्स को कवर करता है।
  • आंतरिक रूप से vertex buffer, texture array, framebuffer, state flags आदि का एकीकृत management।

फायदे और उपयोग केस

  • GPU-less devices, embedded environments, OS-wise पोर्टिंग/टेस्टिंग/डेवलपमेंट automation के लिए optimize किया गया।
  • OpenGL के बिना भी raylib आधारित ऐप्स को पूरी तरह सॉफ़्टवेयर से चलाया जा सकता है।
  • lightweight स्ट्रक्चर के कारण नए experiments/डेवलपमेंट और non-standard environments में सपोर्ट के लिए बहुत उपयुक्त।

लाइसेंस और योगदानकर्ता

  • MIT के कारण flexible redistribution संभव।
  • 2025–2026 में Le Juez Victor, Ramon Santamaria द्वारा review।

निष्कर्ष

  • rlsw एक OpenGL के साथ लगभग पूर्णतः संगत raylib-compatible Pure Software Renderer है।
  • सिंगल फ़ाइल, lightweight, extensibility, और raylib के सभी टेक्सचर फॉर्मेट सपोर्ट के कारण अन्य सॉफ्टवेयर ग्राफ़िक्स सोल्यूशंस की तुलना में entry barrier और integration दोनों बेहतर हैं।
  • लो-लेवल ग्राफ़िक्स और portability-केंद्रित प्रोजेक्ट्स में इसका खास उपयोगी मूल्य है

1 टिप्पणियां

 
GN⁺ 2025-10-23
Hacker News राय
  • Raylib के लेखक ने बहुत खुशी के साथ घोषणा की कि बिना किसी external dependency के, केवल win32 app के जरिए पूरा raylib प्रोग्राम compile किया जा सकता है लिंक
    • यह सच में दिलचस्प है, मैं embedded processor पर मज़े के लिए इस्तेमाल करने हेतु LED स्क्रीन पर कुछ render कर सकने वाली चीज़ ढूंढ रहा था, लेकिन अब तक जो मिला वह संतोषजनक नहीं था। अगर मैंने सही समझा है, तो इसे compile करके software rendering की जा सकती है। मेरे लगभग 192x128 pixel के size पर यह किसी भी system में काफ़ी तेज़ होना चाहिए, तो अब मज़ेदार animation बनाने का समय है
    • Win32 में पहले से ही काफ़ी अच्छा opengl 1.2 software renderer है
    • समझ नहीं आता कि यह करने की ज़रूरत क्यों है
  • ऐसी खबर पर Tsoding की राय जानने की उत्सुकता है
    • शायद अब यह mainstream बनकर HN तक पहुंच गया है, तो Tsoding की इसमें रुचि खत्म हो जाएगी
  • यह बात शानदार है कि कंप्यूटर अब इतने तेज़ हैं कि सिर्फ ऐसी software rendering OpenGL 1.1 library से भी काफ़ी अच्छा 2D game बनाया जा सकता है
    • अगर resolution कम रखा जाए, scene complexity को ध्यान से manage किया जाए, और art style पर ठोस निर्णय लिया जाए, तो 20 साल पुराने hardware पर चलने वाला एक ठीक-ठाक 3D game बनाना संभव था। मैंने सच में प्रयोग के तौर पर खुद एक game बनाया था1 2, और अब जब पता चला कि यह संभव है, तो मैं दूसरा, ज़्यादा "serious" और polished game बनाने की योजना कर रहा हूँ। कंप्यूटर performance सच में बहुत बढ़ गई है। Raylib की यह खबर भी बहुत शानदार है और मैं इसे वास्तव में अपनाने पर विचार कर रहा हूँ
    • संपादन: मुझे पता नहीं था कि यह software rendering है। फिर भी, केवल CPU पर optimal sprite depth sorting algorithm इस्तेमाल करके शायद मेरा game भी render किया जा सकता है (यह RollerCoaster Tycoon जैसी isometric pixel art शैली है)। 90s के Metropolis 1998 project में ancient OpenGL fixed function pipeline का इस्तेमाल करना पड़ता था (खुशकिस्मती से मैंने पाया कि gl.h file में extension function के ज़रिए अतिरिक्त fields GPU तक भेजे जा सकते थे)। मैं graphics framework के रूप में SFML इस्तेमाल कर रहा हूँ, जो शायद OpenGL 1.x आधारित है। एक आधुनिक उदाहरण के रूप में Metropolis 1998 game दिखाता है कि यह approach क्या कर सकती है
    • मुझे लगता है कि software rendering ही आखिरकार भविष्य है, बस शर्त यह है कि GPGPU की तरह hardware acceleration का आक्रामक उपयोग किया जा सके
    • दशकों पहले भी पूरा 3D Unreal Tournament software में render होता था, और 2023 में भी अच्छी तरह चलता है लिंक
  • Fabrice Bellard ने OpenGL से जुड़ा TinyGL भी लिखा था लिंक
    • हैरानी की बात यह है कि (5 मार्च 2022) TinyGL 0.4.1 आया, और (17 मार्च 2002) TinyGL 0.4 पहली बार रिलीज़ हुआ था। "हमारी development plan सदियों में आगे बढ़ती है"
    • वह लगभग हर चीज़ कर लेने वाले सचमुच अद्भुत role model हैं
    • 90s में मैंने इस तरह के बहुत से software renderer देखे थे, लेकिन ईमानदारी से कहूँ तो तब वे धीमे, भारी, या artifacts से भरे होते थे, इसलिए खास अच्छे नहीं लगते थे। performance के लिए game और renderer के बीच काफ़ी tight integration चाहिए होता था। इतिहास की विडंबना महसूस होती है
    • संदर्भ के लिए, C-Chads द्वारा fork किया गया tinygl भी है। इसे original की तुलना में काफ़ी हाल तक maintain किया गया, और multithreading जैसी कई सुविधाएँ जोड़ी गईं, हालांकि 2023 के अंत में इसे archive कर दिया गया
  • pikuma.com की बदौलत मुझे software renderer की खूबसूरती समझ में आई, और इस बात पर बहुत गर्व है कि मैं ज़्यादातर code को समझ सका
  • "OpenGL 1.1-style implementation on software" वाला वर्णन देखकर यह जिज्ञासा हुई कि OpenGL 2.0 (Non ES version) तक implement करने के लिए कितनी lines चाहिए होंगी
    • कम से कम कई गुना ज़्यादा। user-programmable shader (ARB assembly/GLSL) implement करना सबसे कठिन होगा, साथ ही GLSL parser और shader interpreter भी बनाना पड़ेगा। multitexturing और तरह-तरह के texture combiner भी जोड़ने होंगे। कुल मिलाकर बहुत ही कम अनुमान लगाएँ तब भी मुझे लगता है कम से कम 40,000 lines चाहिए होंगी। हाँ, अगर पूरी spec लागू न करके सिर्फ minimum हिस्सा किया जाए, तो इससे कम भी हो सकता है
    • मैंने पहले वास्तव में fixed function hardware के लिए OpenGL API implement किया था, 1.5 version तक और framebuffer object जैसी कुछ extension भी लागू की थीं। 1.x पीढ़ी में काफ़ी अनावश्यक चीज़ें हैं, लेकिन implement करना आसान है। 2.x पीढ़ी (shader की शुरुआत) को software में implement करना बहुत कठिन है
    • सही line count तो नहीं पता, लेकिन PortableGL नाम का एक 3.x software renderer भी है। यह बहुत शानदार और छेड़छाड़ करके देखने में मज़ेदार project है
  • OpenGL-style शब्द के बारे में
    • अगर सिर्फ header देखकर कह रहे हैं, तो बधाई हो, यह काफ़ी अच्छी OpenGL 1.1 software implementation है। बेशक यह पूरी spec का पालन नहीं करती, लेकिन पुराने MiniGL driver की तरह इतना हिस्सा implement करती है कि game चल सके। यह project भी कुछ वैसा ही करता है, यानी सिर्फ उतना implement करता है कि Raylib का OpenGL backend चल सके। मकसद यह है कि बिना external graphics dependency के इस्तेमाल किया जा सके
  • क्या इसमें CUDA support है, यह जानने की जिज्ञासा है
    • नहीं, यह पूरी तरह CPU rendering है। इसमें SIMD तक इस्तेमाल नहीं होता, सिर्फ सीधे integer/float आधारित code का उपयोग होता है
  • यह Nintendo 3DS के लिए एकदम उपयुक्त लगता है
    • तो क्या इसे NES, SNES, Genesis जैसे console games बनाने में भी इस्तेमाल किया जा सकता है, यह जानने की उत्सुकता है