SDL अब DOS को सपोर्ट करता है

 (github.com/libsdl-org)
1 पॉइंट द्वारा GN⁺ 4 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DJGPP-आधारित DOS port अब SDL में जोड़ दिया गया है, और video, audio, input, threading, timer, filesystem और build chain तक का काफ़ी व्यापक सपोर्ट main में merge हो चुका है
  • VGA और VESA 1.2+ video, Sound Blaster परिवार का audio playback, PS/2 keyboard और mouse, BIOS-आधारित joystick, cooperative threading और PIT timer तक DOS environment के मुताबिक implementation जोड़ी गई है
  • DJGPP के seek/read issue को seek के समय buffer dump और restore करने के workaround से संभाला गया, जिससे SDL_LoadWAV की गलत reading और कई सेकंड की delay खत्म हो गई; audio path को भी IRQ reentry और stutter कम करने के लिए सुधारा गया
  • fullscreen black screen issue का संबंध INDEX8 mode selection से था; DOS-only hint जोड़ने के बजाय mode order को logical तरीके से arrange किया गया, और cursor transparency issue भी एक अतिरिक्त commit से ठीक किया गया
  • real hardware testing सीमित रही; audio recording, SDL_LoadObject, और SDL_TIME की DOS-specific implementation जैसी कुछ features अभी नहीं हैं, लेकिन 46 checks पास करके इसे merge किया गया और 3.6.0 feature के रूप में तय किया गया

DOS platform support का दायरा

  • SDL में DOS porting जोड़ी गई है, और DJGPP के आधार पर यह अपेक्षाकृत परिपक्व स्थिति तक पहुंच गई है
    • काम कई लोगों ने बांटकर किया, और अंतिम चरण में stability fixes और missing features की पूर्ति जोड़ी गई
    • DevilutionX को DOSBox में व्यापक रूप से test किया गया, लेकिन real hardware testing नहीं हुई
    • जिन features को ठीक से test करना संभव नहीं था, उन्हें जानबूझकर कुछ जगह शामिल नहीं किया गया
  • supported features को विस्तार से व्यवस्थित किया गया है
    • video में VGA और VESA 1.2+ framebuffer, RGB और 8-bit indexed color, VGA DAC palette programming, vsync और hardware page flipping, और exit के समय VBE state save/restore शामिल हैं
    • audio में Sound Blaster 16, Sound Blaster Pro, Sound Blaster 2.0/1.x सपोर्ट हैं, और IRQ-based DMA तथा double-buffer auto-init path का उपयोग होता है
    • input में extended scancode सहित PS/2 keyboard, INT 33h mouse, और BIOS INT 15h-आधारित gameport joystick शामिल हैं
    • threading में setjmp/longjmp और stack patching पर आधारित cooperative scheduler उपयोग होता है, साथ ही mutex, semaphore, TLS और condition variable के सामान्य fallback भी हैं
    • event pump और delay function में yield points डाले गए हैं ताकि audio और दूसरे threads की responsiveness बनी रहे
    • timer में DJGPP के uclock() का उपयोग करने वाली PIT-based implementation है, जिसकी resolution लगभग 1.19 MHz है
    • filesystem में GetBasePath और GetPrefPath को DJGPP के searchpath() से संभाला जाता है, और POSIX filesystem operations के fallback भी शामिल हैं
    • build में CMake cross-compilation toolchain file, DJGPP CI job, और तेज configure के लिए preseed cache शामिल हैं
  • जो features शामिल नहीं हैं, उन्हें भी साफ़ तौर पर लिखा गया है
    • audio recording नहीं है; केवल playback supported है
    • SDL_TIME की native implementation अलग से नहीं है; DJGPP की POSIX layer के जरिए Unix gettimeofday को reuse किया गया है
    • shared library loading supported नहीं है, इसलिए SDL_LoadObject उपलब्ध नहीं है

implementation प्रक्रिया और मुख्य बदलाव

  • DOS port में कई commits के दौरान video, audio, input, timer, threading और build chain चरणबद्ध तरीके से जोड़े गए
    • शुरुआती काम के बाद stdio buffering, audio implementation, video subsystem, filesystem, mouse, keyboard, CI और platform detection को क्रमशः पूरा किया गया
  • stdio और file access में DJGPP के खास seek/read issue का workaround किया गया
    • stdio SDL_IOStreams का buffering बंद करने की कोशिश भी हुई, लेकिन बाद में seek के समय buffer dump और restore करने वाले तरीके पर बदला गया
    • यह बदलाव buffer को पूरी तरह बंद करने से कहीं तेज़ था, और fseek के बाद गलत reads आने की समस्या से भी बचाता है
    • SDL_LoadWAV जब test/sample.wav पढ़ता था तब कई सेकंड लगने की समस्या खत्म हो गई, और सही data मिलने लगा
  • audio processing का तरीका भी stability पर फोकस रखते हुए लगातार सुधारा गया
    • शुरुआत Sound Blaster 16 implementation से हुई, फिर pre-SB16 8-bit mono और SB Pro stereo support जोड़ा गया
    • audio mixing पहले IRQ handler में सीधे चलती थी, फिर main loop से होकर, और बाद में SDL audio thread की ओर वापस ले जाई गई
    • दिशा इसलिए बदली गई ताकि IRQ के अंदर reentry problem न हो, और load के दौरान पुराने DMA buffer के आधे हिस्से को silence करके stutter कम किया गया
    • sample rate adjustment, DSP state polling, DMA memory allocation का आधार, और interrupt vector restore के बाद IRET wrapper हटाने तक चीज़ें व्यवस्थित की गईं
  • video को भी DOS environment की सीमाओं के अनुसार विस्तार दिया गया
    • VESA interface के साथ software renderer चलाने वाली शुरुआती implementation जोड़ी गई
    • इसके बाद 8-bit palette support, VBE page flipping, state restore, single-buffer mode vsync, और VESA banked framebuffer mode जोड़े गए
    • VBE 1.2+ में अगर LFB नहीं हो तो bank switching से framebuffer copy की जाती है, और इस mode में page flipping बंद कर दिया जाता है
    • video initialization और shutdown के समय पूरा VBE state save/restore करके mode switching को साफ़ रखा गया
  • input और interrupt handling को भी practical उपयोग के स्तर तक सुधारा गया
    • keyboard में extended scancode और Pause key तक संभाली गई, और event storage के लिए simple ring buffer इस्तेमाल हुआ
    • mouse में INT 33h function 0x1B से sensitivity query करके उपयोग किया गया
    • joystick में BIOS timing loop की लागत कम करने के लिए axis polling को लगभग 60 Hz तक सीमित किया गया, जबकि responsiveness के लिए buttons को हमेशा सीधे poll किया गया
    • ISR code और data को lock किया गया ताकि interrupt के दौरान page fault न हो
  • build और platform detection की समस्याएं भी ठीक की गईं
    • DJGPP के लिए CI job जोड़ी गई और DOS के लिए CMake platform detection जोड़ा गया
    • SDL_PLATFORM_DOS को SDL_RunApp() exclude list में रखा गया ताकि DOS-specific launcher से conflict न हो
    • DJGPP भले __unix__ define करे, DOS में GTK या display server नहीं होते, इसलिए SDL_Gtk_Quit() को DOS पर exclude किया गया ताकि link error न आए
    • कुछ DJGPP toolchains i386-pc-msdosdjgpp-gcc prefix इस्तेमाल करते हैं, इसे भी ध्यान में रखा गया

testing की स्थिति और बची हुई सीमाएं

  • automated tests पूरी तरह smooth नहीं थीं, लेकिन patch लगाकर अंत तक चलाई जा सकने वाली स्थिति तक पहुंच गईं
    • कुछ standard formatting functions की वजह से automated tests अंत तक नहीं जा रही थीं; workaround patch के साथ tests पूरी की गईं
    • कुछ failing cases अब भी बचे थे, लेकिन उन formatting functions को सही तरीके से कैसे ठीक किया जाए, इस पर पर्याप्त भरोसा न होने से उन्हें शामिल नहीं किया गया
    • निष्कर्ष यह रहा कि ज़्यादातर demos कुल मिलाकर अपेक्षित स्तर पर काम करते हैं
  • actual usage results भी जोड़े गए
    • DOSBox और DOS 6.22 on a Vortex86 board पर non-fullscreen window test program और user code दोनों में ठीक काम करती है
    • लेकिन fullscreen में उस समय draw.exe --fullscreen जैसे उदाहरणों पर काली खाली स्क्रीन दिखाई देती थी
    • speed धीमी है, लेकिन usable स्तर की बताई गई है
  • कुछ test programs की समस्याएं भी सामने आईं
    • sprite.exe DOSBox में तुरंत बंद हो जाता है
    • wm.exe और draw.exe render नहीं करते, लेकिन ESC दबाने पर बंद हो जाते हैं
    • testpalette में segfault होता है

fullscreen color depth selection issue और उसके बदलाव

  • fullscreen black screen का सीधा कारण SDL_GetClosestFullscreenDisplayMode() का INDEX8 mode चुन लेना था
    • अगर application INDEX8 rendering संभाल नहीं पाती, तो स्क्रीन काली दिखती है
    • internal implementation में INDEX8 को केवल तब consider किया गया जब user पहले से INDEX8 fullscreen mode सेट करे
  • शुरू में DOS पर ही SDL_HINT_DOS_ALLOW_INDEX8_MODES के पीछे INDEX8 modes छिपाने वाला उपाय जोड़ा गया
    • उद्देश्य था कि application तभी explicit opt-in करे जब वह इसे सही तरह संभाल सके
  • लेकिन main branch में lowest bit depth के बजाय highest bit depth चुनने वाला बदलाव पहले से आ चुका था, इसलिए यह देखने की प्रक्रिया चली कि क्या वही पर्याप्त है
    • इस बदलाव ने bpp issue तो हल किया, लेकिन 640x480 best fit request पर 1024x768 चुन लेने जैसी नई समस्या पैदा की
    • आखिरकार वह बदलाव revert कर दिया गया, और बेहतर fix को अलग PR में संभालने का निर्णय हुआ
  • अंत में DOS-only hint हटा दिया गया और modes को logical order में arrange किया गया
    • Remove SDL_HINT_DOS_ALLOW_INDEX8_MODES and order modes logically commit जोड़ा गया
    • #15442 merge होने पर, palette set न करने वाली या fullscreen mode सीधे न चुनने वाली apps में भी automatic mode selection सही काम कर सकता है, ऐसा निष्कर्ष निकला
    • साथ ही यह सीमा भी तय की गई कि इस PR में SDL की दूसरी पुरानी समस्याओं तक अंतहीन गहराई में नहीं जाया जाएगा

demo rendering और cursor fixes

  • demos के काला दिखने की समस्या केवल इस PR से नहीं, बल्कि #15442 के merge status पर भी निर्भर थी
    • जब तक SDL_GetClosestFullscreenDisplayMode() सबसे कम color depth को प्राथमिकता देता रहा, इस port में INDEX8 चुना जाता रहा, और अगर app palette सेट न करे तो black screen मिलती रही
    • उस PR को local तौर पर merge करने पर पुष्टि हुई कि test targets सभी काम कर रहे थे
  • बची हुई visual problem cursor transparency थी
    • local verification के बाद पता चला कि सिर्फ cursor transparent नहीं था
    • इसे ठीक करने के लिए Don't convert cursor if dest is not INDEX8 commit जोड़ी गई
    • fix के बाद RGB mode में unoptimized version उपयोग होती है, लेकिन RGB और INDEX8 दोनों में सही behavior सुनिश्चित किया गया
    • XRGB1555 और RGB565 में थोड़ी बेहतर performance की संभावना बची है, लेकिन उसे low priority माना गया

review और merge का निर्णय

  • PR के लिए squash merge उपयुक्त माना गया
    • GitHub final commit में PR reference बनाए रखता है, इसलिए work history trace की जा सकती है
    • final commit में अतिरिक्त credit lines जोड़ने का सुझाव भी शामिल था
    • Co-authored-by दो लोगों और Tested-by एक व्यक्ति को जोड़ने के लिए ठोस wording भी शामिल थी
  • reviewer ने कहा कि merge के बाद कुछ build script expressions को और साफ़ तरीके से फिर लिखा जाएगा
  • final merge से ठीक पहले दूसरे related PRs को भी साथ merge करके DOS PR आगे बढ़ाने की दिशा तय हुई
    • “Last call on DOS pull request!” के बाद related PRs के merge status की पुष्टि हुई
    • उसके बाद 46 checks passed के साथ यह main में merge हो गया
  • merge के बाद release scope भी स्पष्ट कर दी गई
    • यह बदलाव 3.6.0 feature माना गया

    • 3.4.x में cherry-pick नहीं किया जाएगा

      • merge के अगले दिन DOS work branch हटा दी गई

आगे के काम और बाकी hardware issues

  • कुछ Nvidia GPUs पर 4f07(SetDisplayStart) implementation सही तरह काम नहीं करने की समस्या भी उठाई गई
    • VOGONS thread के साथ यह लिखा गया कि रिपोर्ट में support दिखने पर भी कुछ GPUs पर यह वास्तव में काम नहीं करता
    • test range GeForce 9300 से 3060 तक और व्यापक हो सकती है, लेकिन उपलब्ध hardware के आधार पर यह पूरी coverage नहीं है
    • project-side testing में भी वही display issue देखा गया
  • GPU vendor के आधार पर SDL द्वारा feature disable करना उचित नहीं माना गया, और user-control hint की संभावना भी उठी
    • page_flip_available को user द्वारा सीधे नियंत्रित करने वाला नया hint बेहतर हो सकता है, ऐसा सुझाव आया
    • इसे तुरंत नहीं किया गया, लेकिन बाद में जोड़े जाने की संभावना के साथ बात समाप्त हुई
  • merge के बाद direct framebuffer usage hint का भी उल्लेख किया गया
    • SDL_HINT_DOS_ALLOW_DIRECT_FRAMEBUFFER चालू करने पर ऊपर वाला SetDisplayStart issue शायद उतना महत्वपूर्ण न रहे

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

1 टिप्पणियां

 
GN⁺ 4 일 전
Hacker News की टिप्पणियाँ

  • अब अगर UEFI के लिए SDL मिल जाए, तो गेम्स को OS boot होने से पहले वाले environment में भी चलाया जा सकेगा

    • सोच रहा हूँ कि क्या Intel Management Engine / Minix, जो सभी Intel chipset पर चलता है, आज भी वैसा ही है
      क्या security अब ज़्यादा मजबूत हो गई है, या अब भी पहुँचा जा सकता है, यह भी जानना चाहता हूँ https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/
    • असल में यह इतना मुश्किल शायद नहीं होगा
      बस, मेरी जानकारी में UEFI में sound driver नहीं होता, और आजकल audio codec chips के लिए भी सिर्फ NDA-only datasheet मिलती हैं, इसलिए खुद लिखना भी मुश्किल है
      उससे भी अजीब बात यह है कि graphics output protocol में vsync information नहीं है, इसलिए tearing-free blitting नहीं हो सकती, और यह तो सचमुच VGA से भी खराब है
    • UEFI थोड़ा modern DOS जैसा लगता है
    • सच कहूँ तो यह काफ़ी शानदार तस्वीर है
      सोचो grub जैसे menu से boot किया और सामने classic games की list आ गई, काफ़ी रोमांचक लगता है
    • एक तरह से यह bare metal के लिए SDL है

  • यह screenshot खास तौर पर इसलिए मज़ेदार है क्योंकि DosBOX खुद SDL के ऊपर बना है

    • तो अब हमें DOS के अंदर चलने वाला dosbox चाहिए
    • यह तो बिल्कुल SDLception है

  • यह DJGPP का उपयोग करता है, इसलिए DPMI के ज़रिए CPU को 32-bit mode में switch करता है
    इसलिए segmented memory, near pointer, और हर तरह की 64KB limitations वाला असली old-school एहसास नहीं मिलता

  • बढ़िया
    सोच रहा हूँ कि SDL bindings सपोर्ट करने वाले FreeBASIC के 386+ target MS-DOS executable के साथ यह कैसा चलेगा
    [1] - https://github.com/freebasic/fbc

    • मैं खुद इसे जाँचने वाला हूँ
      मैं कई सालों से सोच रहा था कि मूल रूप से DOS से आए OHRRPGCE को फिर से DOS पर port करूँ
      और SDL 1.2 के दिनों में SDL ने लगभग सारे ports और OS support को काफ़ी आक्रामक तरीके से हटा दिया था, यह याद करें तो SDL3 का DOS support वापस लाना काफ़ी चौंकाने वाला है

  • परफेक्ट
    आज सुबह मैं macOS के अंदर VMware Fusion के अंदर Debian GNU/Linux के अंदर DOSBox-X के अंदर Turbo C में development कर रहा था, तो यह खबर बिल्कुल फिट बैठती है

    • यह मज़ाक था या सच, यह मैं ज़रूर जानना चाहूँगा
    • सोच रहा हूँ क्या Linux के लिए turboc variant भी था
      कई दशक पहले turboc पर काम करने की धुंधली-सी याद है
    • अगर ऐसा है, तो आपको फ़िल्म Inception भी मज़ेदार लगेगी :)

  • तकनीकी रूप से देखें तो यह पहले से HXDOS के साथ संभव था
    क्योंकि वह DirectDraw को इतना अच्छी तरह emulate करता था कि SDL उसे इस्तेमाल कर सके

    • एक मिनट, क्या?
      तो फिर सवाल है कि इसे किस SDL target के लिए compile किया जाता है
      क्या यह Win32-exclusive fullscreen है, या 640x480 जैसी VESA resolution?

  • SDL जैसे open source project में ऐसा support आना आमतौर पर इस पर निर्भर करता है कि बदलाव कितने intrusive हैं, और क्या contributor आगे चलकर इसकी maintenance भी करता रहेगा
    हर project की policy अलग होती है, और SDL की policy मुझे नहीं पता, लेकिन ports पहले से इतने हैं कि शायद वे जानते हैं कि वे क्या उठा रहे हैं

    • ऐसे rare architecture support लगभग हमेशा किसी एक सपने देखने वाले इंसान, और उसे सच में बनाकर बनाए रखने वाले एक hero पर टिके रहते हैं
      मेरा पसंदीदा उदाहरण openbsd luna88k है https://www.openbsd.org/luna88k.html
      मुझे बिल्कुल नहीं पता कि इसके असली users कितने हैं। शायद यह जापान में ही आया कोई बहुत दुर्लभ machine था, और अगर users हैं भी तो ज़्यादातर जापान में होंगे, जो मेरी नज़र से बाहर हैं, इसलिए महसूस तो यही होता है कि इसका user बस वही porter एक ही व्यक्ति है
      फिर भी हर release में, आधिकारिक release date के कुछ हफ्तों बाद, जैसे जंगल से अचानक निकलकर, वह luna88k files और packages अपलोड कर देता है
      शायद असली luna88k पर compile करने में समय लगता होगा, और जो भी हो, इतना काफ़ी है कि यह OpenBSD का official hardware platform बना रहे
      मेरे पास खुद luna88k रखने की कोई इच्छा नहीं है, लेकिन उसे लगातार चलाते रहने वाला वह व्यक्ति सच में सम्मान के लायक है

  • लगता है SDL फिर से Loki era की जड़ों की ओर लौट रहा है

  • बढ़िया
    क्यों? पता नहीं, लेकिन cool है तो काफ़ी है

    • अब हम DOS में Dota 2 चला सकते हैं
    • Browser-based DOSBox इतना आसान और तेज़ है कि DOS, छोटे games ही नहीं बल्कि काफ़ी serious games के लिए भी, एक highly portable target बन जाता है
      Internet Archive में जैसा दिखता है, keyboard और mouse हों तो mid-90s की AAA-level complexity तक की चीज़ें लगभग कहीं भी चलाई जा सकती हैं
      Tomb Raider, Command & Conquer, Quake जैसे games इसका उदाहरण हैं, और अगर आपको ऐसा platform चाहिए जो बस ठीक से काम करे, तो यह काफ़ी आकर्षक है
      ऊपर से SDL मिल जाए तो यह और आसान हो जाता है
    • तकनीकी नज़रिए से FreeDOS आज भी सक्रिय रूप से supported, modern DOS है
    • SDL एक cross-platform multimedia library है, और DOS भी एक platform है

  • सच में बहुत खुशी हुई
    यह मुझे बेहद खुश करता है