Bash में Raycaster का इम्प्लीमेंटेशन

• यह Bash में इम्प्लीमेंट किया गया raycaster है, जो arrow keys से rotate/move होता है और q दबाकर बंद किया जा सकता है। यह एक terminal-based pseudo-3D डेमो है
• इम्प्लीमेंटेशन मुख्यतः Lode Vandevenne के raycasting tutorial का port है, और सारा math floating point के बिना 64K scale वाले integer operations से किया गया है
• सबसे बड़ी सीमा Bash की performance है; हर pixel पर command चलाना, या screen state को array/string में रखना, frame time के भीतर output देना मुश्किल बनाता है
• terminal display के लिए Unicode half block और foreground/background 24-bit colors का उपयोग किया गया है, जिससे vertical resolution प्रभावी रूप से दोगुनी हो जाती है, लेकिन इसके लिए पास-पास के pixels के रंग साथ में जानने पड़ते हैं
• मौजूदा roadmap में fluid movement, decent framerate, parallel rendering, kitty keyboard protocol, और sound का शुरुआती prototype जैसे काम पूरे हो चुके हैं, जबकि textures, sprites, enemies, particles, multiplayer आदि अभी अधूरे हैं

---

Bash से बना terminal raycaster

• यह प्रोजेक्ट Bash में चलने वाला raycaster है, जो terminal के अंदर pseudo-3D स्क्रीन render करता है
• कंट्रोल के लिए arrow keys से rotation और movement किया जाता है, और q से बाहर निकला जाता है
• और ज़्यादा screenshots और वीडियो Imgur album में हैं
• इम्प्लीमेंटेशन मुख्यतः Lode Vandevenne के raycasting tutorial का port है

इम्प्लीमेंटेशन को कठिन बनाने वाली सीमाएँ

• सबसे बड़ी समस्या यह है कि Bash धीमा है
  • लेखक के अनुसार, अगर हर pixel पर सिर्फ एक command भी चलानी पड़े, तब भी acceptable frame rate पाना मुश्किल है
  • अगर screen state को color array में रखा जाए, तो arbitrary array element access linear time होने के कारण समस्या बनता है
  • अगर screen state को एक लंबी string में रखा जाए, तो LANG=C में भी nवें character तक पहुँचना linear time है, इसलिए सिर्फ उसे पढ़कर screen पर dump करना ही एक frame से ज़्यादा समय ले सकता है
• Bash में floating point support और math function library का access नहीं है
  • सारा math integer में किया गया है
  • integer values को 64K scale तक बढ़ाकर calculate किया जाता है
• terminal में एक character को एक pixel की तरह इस्तेमाल करने पर दृश्य अच्छा नहीं लगता, इसलिए Unicode half block का उपयोग किया गया है
  • foreground और background colors अलग-अलग देकर vertical resolution को प्रभावी रूप से दोगुना किया जाता है
  • एक cell में दो colors में से सिर्फ एक को update करने का कोई तरीका नहीं है
  • मौजूदा cell का color query करने का भी कोई तरीका नहीं है, और Bash में ऐसी query अपने आप में बहुत धीमी है
  • इसलिए हर बार pixel लिखते समय पास वाले pixel का color भी पता होना चाहिए

terminal और input/output की समस्याएँ

• Bash जैसी धीमी भाषा में पूरे terminal को एक बार में refresh करना आसान नहीं है
• ज़्यादातर terminal video games के लिए design नहीं किए गए हैं, इसलिए इस समय कौन-सी key दबाई हुई है, यह test नहीं किया जा सकता
  • आम तौर पर केवल वही single key input मिलता है जिसे दबाकर रखा गया हो
  • input repeat धीमे debounce के साथ होता है, और continuous input limit भी कम होती है, जिससे कभी-कभी प्रति सेकंड सिर्फ 5~6 characters मिलते हैं
  • modifier keys के अलावा कई keys को एक साथ पाना भी कठिन है
  • kitty keyboard protocol इस समस्या को हल करता है
• terminal को रंगों से भरने पर बहुत ज़्यादा data चाहिए होता है
  • लेखक के सामान्य font size पर लगभग 10MB I/O प्रति सेकंड होता है
• Bash कई newline वाले string को print करते समय single syscall का उपयोग नहीं करता
  • यह प्रोजेक्ट \n print नहीं करता, बल्कि cursor को दूसरे तरीके से move करता है

FAQ और चलाने की शर्तें

• अगर window size बदलने पर display टूट जाए, flickering बहुत हो, या किसी खास terminal में अच्छा न दिखे, तो issue खोलने के लिए कहा गया है
• अगर CPU बहुत गरम हो जाए या पुराना computer धीमा पड़ जाए, तो resolution कम करने या FPS environment variable को 30 से नीचे सेट करने की सलाह दी गई है
  • यह भी बताया गया है कि Microsoft Defender performance को काफ़ी घटा देता है, इसलिए उसे disable करने का सुझाव दिया गया है
• Bash 5.2 से कम पर यह काम नहीं करता
• यह पूरी तरह pure Bash code नहीं है
  • शुरुआत में stty को एक बार कॉल करके echo बंद किया जाता है
  • बंद करते समय stty को एक बार कॉल करके echo फिर चालू किया जाता है
  • बंद होने के बाद कुछ statistics दूसरे tools से collect किए जाते हैं

roadmap की स्थिति

• पूरे किए गए आइटम

  • semi-accurate pseudo 3d

    • fluid movement
    • decent framerate
    • parallel rendering
    • 24 bit colours
    • kitty keyboard protocol
    • framerate-independent speed
    • sound, लेकिन यह अभी बहुत शुरुआती prototype है
    • dynamic wall colours
    • dynamic map, अभी events इसे बदलते नहीं हैं, लेकिन तकनीकी रूप से इसे dynamic बताया गया है
    • basic animations effects for walls
    • basic on-screen minimap
    • अधूरे आइटम

  • mouse support

    • textures
    • sprites
    • objects/enemies
    • particles
    • better perf
    • multiplayer

[GN⁺]

Hacker News की राय

• यह वाकई बहुत बढ़िया है। मैं सोच रहा था कि हर पिक्सेल पर एक बार echo किए बिना यह चित्र कैसे बनाता है, और इसका तरीका काफ़ी चतुर है
  चूँकि गेम “असल” 3D नहीं है, इसलिए हर कॉलम के लिए सिर्फ़ एक बार raycasting चलानी पड़ती है, और सिर्फ़ आसमान, घास और असली ऑब्जेक्ट्स से जुड़ी कुछ लाइनों को ही ड्रॉ करना होता है
  यह टर्मिनल में string repetition के ज़रिए उतनी बार “इस पिक्सेल को बनाओ और एक पंक्ति नीचे जाओ” स्ट्रिंग आउटपुट करता है, जितनी बार ज़रूरत हो
  यह Bash के लिए नहीं है, लेकिन मैं सीमित compute resources वाले दूसरे environment में voxel rendering engine बनाने के बारे में सोच रहा था, और लगता है यहाँ से कुछ उपयोगी ज़रूर मिल सकता है
  • VoxelCanvas.js फ़ाइल भी दिलचस्प हो सकती है। यह एक JavaScript फ़ाइल है, और वही raycasting वाला विचार इस्तेमाल करती है: https://github.com/EngineersNeedArt/Mooncraft2000
• अगर आप सोच रहे थे कि MS Batch में लिखा हुआ कोई raycaster भी है या नहीं, तो यह भी है: https://github.com/nTh0rn/batch-raycaster
• अफ़सोस है कि stty को fork की ज़रूरत पड़ती है। शायद अगला प्रोजेक्ट Bash और rowhammer के साथ ज़रूरी ioctl कॉल करके इसे बिना fork के चलाने का हो
• मुझे नहीं पता था कि Bash में यह भी संभव है। मैंने कभी सोचा था कि मैं Bash को काफ़ी उन्नत स्तर पर जानता हूँ, लेकिन यह सच में हैरान कर देने वाला है
  इसे समझने लायक मेरी गणित नहीं है, लेकिन सिर्फ़ देखना भी मज़ेदार है
• मेरी Bash scripts तो तरह-तरह के command-line option parsing में ही 300 लाइनें खर्च कर देती हैं, जबकि असल में उसकी जगह ऐसा कोई गेम दिखाया जा सकता था :-P
• अब भी समझ नहीं आता कि हम अभी तक इतने बेहिसाब धीमे shell से बँधे क्यों हुए हैं। यह शुद्ध पागलपन जैसा लगता है
  मैं समझ सकता हूँ कि कुछ apps को vt100 के तरह-तरह के अजीब व्यवहारों की ज़रूरत होती है, लेकिन शायद 90% apps तो बस standard output और standard error में लिखती ही हैं
  क्या ऐसा नहीं होना चाहिए कि टेक्स्ट को स्क्रीन पर थोड़ा तेज़ी से भेजा जा सके, और बाकी 10% को compatibility mode में रखा जाए
  • shell धीमे होते हैं, और Bash ख़ास तौर पर, लेकिन उसके बाद की बात कहाँ जाती है यह मुझे साफ़ नहीं है। shell का terminal escape sequences की interpretation से कोई लेना-देना नहीं होता, और modern terminals काफ़ी तेज़ हैं
    350-कॉलम वाले terminal पर भी animation render की जा सकती है, और सीमाओं को देखते हुए वह काफ़ी smooth दिखती है
    ऊपर से, इस लेख का मूल आधार ही यह है कि Bash raycasting के लिए उपयुक्त भाषा नहीं है। यह कुछ वैसा है जैसे CSS में bubble sort लिखना
    “बाकी 10% को compatibility mode में डाल दें” — इसे रोकने वाली कोई बात नहीं है। बस यह जाँच लें कि string में सिर्फ़ सामान्य characters हैं और फिर fast path इस्तेमाल करें
    समस्या यह है कि software text rendering में वास्तव में कोई fast path होता ही नहीं। आपको अब भी ligatures जैसी चीज़ें संभालनी पड़ती हैं
• “bash धीमा है।”
  यही उन वजहों में से एक है जिनकी वजह से मैं scripting के लिए Bash का इस्तेमाल नहीं करता। interactive तौर पर भी नहीं
  कुछ लोकप्रिय Linux distributions भी Bash को scripting shell के रूप में इस्तेमाल करने से बचती हैं
• अच्छा होगा अगर इसे लेखक के बिना-fork वाले ps implementation के साथ जोड़कर लगभग forkless psDoom बनाया जाए
  मज़ाक अपनी जगह, यह सच में शानदार है
• और हाँ, 9 साल पुराने awk raycaster का सम्मानजनक ज़िक्र भी होना चाहिए: https://github.com/TheMozg/awk-raycaster/tree/master
  • बढ़िया easter egg: https://github.com/TheMozg/awk-raycaster/blob/master/awkaste...