1992 की तरह compile करें (2014)

 (fabiensanglard.net)
3 पॉइंट द्वारा GN⁺ 2024-02-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1992 के Wolfenstein 3D के मूल source आधुनिक systems के साथ सीधे compatible नहीं हैं, लेकिन DosBox और Borland C++ 3.1 का environment दोबारा बनाकर इन्हें फिर से compile किया जा सकता है
  • जरूरी setup में Wolfenstein 3D source code, DosBox, Borland C++ 3.1, और चलाने के लिए shareware assets शामिल हैं
  • build process में Borland C++ project settings के अलावा PATH, SIGNON.OBJ, GAMEPAL.OBJ paths को manually ठीक करना पड़ता है
  • पहली बार चलाने पर graphics टूटे हुए दिखने की वजह यह है कि engine में compiled graphics index और asset files के अंदर की locations आपस में mismatch हो जाती हैं
  • regenerated VGA assets को copy करके और DosBox का aspect correction चालू करने पर इसे 1992 के CRT aspect ratio के करीब चलाया जा सकता है

1992 का build environment दोबारा बनाना

  • Wolfenstein 3D का 1992 का मूल source code, 20 साल से ज्यादा समय बीत चुके आधुनिक systems पर वैसे ही इस्तेमाल करना मुश्किल है, लेकिन उस समय के tools और runtime environment को match करें तो इसे compile किया जा सकता है
  • जरूरी setup ये चार चीजें हैं
    • Wolfenstein 3D source code
    • DosBox
    • Borland C++ 3.1
    • Wolfenstein 3D shareware assets

DOS drive की तरह इस्तेमाल करने के लिए directory तैयार करना

  • local में DOS drive की तरह इस्तेमाल करने के लिए 2 directories बनाएं
    • system/c
    • system/a
  • system/a में Borland C++ 3.1 compressed file डाउनलोड करें
  • system/c में Wolfenstein 3D source code और VGA files डाउनलोड करें
  • unzip करने के बाद file layout इस तरह व्यवस्थित होता है
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

DosBox में compiler और source install करना

  • DosBox चलाने के बाद local folders को DOS drives के रूप में mount करें
    • ~/system/c को C: के रूप में mount करें
    • ~/system/a को A: के रूप में mount करें
  • A:\BCPP31 में install चलाकर Borland C++ 3.1 install करें
    • default settings बनाए रखें और installation शुरू करें
    • Microsoft Windows folder नहीं मिल पाने की warning जरूरी नहीं है, इसलिए Enter दबाकर आगे बढ़ें
  • C:\ में Wolfenstein 3D source installer चलाएं और default path \WOLFSRC इस्तेमाल करें

Borland C++ project build करना

  • C:\BORLANDC\BIN\BC.EXE से Borland C++ 3.1 चलाएं
  • ..\..\WOLFSRC\WOLF3D.PRJ project खोलें और directories को इस तरह set करें
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • पहले build में Cannot find executable TASM error आता है
    • Borland C++ बंद करें, PATH=C:\BORLANDC\BIN set करें, फिर दोबारा चलाएं
  • अगले build में link stage पर Unable to find OBJ file error आता है
    • project में SIGNON.OBJ और GAMEPAL.OBJ गलत तरीके से C:\SOURCE\WOLF\ path पर specified हैं
    • दोनों entries को project से delete करें और WOLFSRC\OBJ\SIGNON.OBJ, WOLFSRC\OBJ\GAMEPAL.OBJ के रूप में फिर से add करें
  • इसके बाद Compile -> Build All चलाने पर build सफल हो जाता है

Runtime assets और graphics टूटने की वजह

  • compiled executable चलाने के लिए Wolfenstein 3D shareware या full version assets चाहिए
  • shareware install करने के बाद compiled .EXE को game folder में copy करके चलाएं तो screen अजीब तरह से दिखती है
  • वजह graphics files बनाने वाली production pipeline और engine के asset access तरीके में है
    • Adrian Carmack और Kevin Cloud ने graphics files बनाने के बाद उन्हें IGRABed tool से bundle किया
    • output में VGAHEAD.WL1, VGAGRAPH.WL1, VGADICT.WL1 ये 3 files और GRE.H, GRE.EQU ये 2 files शामिल होती हैं
  • VGAHEAD.WL1, VGAGRAPH.WL1 के अंदर data locations की ओर इशारा करने वाला index है
    • VGAGRAPH.WL1 में Huffman-compressed data stored होता है
    • VGADICT.WL1 में decompression के लिए Huffman dictionary होती है
  • GRE.H और GRE.EQU वे files हैं जिनसे engine assets को नाम से access कर पाता है
    • उदाहरण के लिए L_GUYPIC जैसा logical name असली index value से जुड़ता है
    • engine image index को hardcode किए हुए state में build होता है
  • Wolfenstein 3D shareware release के बाद assets और codebase Spears of Destiny के साथ बदलते गए, जिससे नए compiled game के indexes मौजूदा asset files की locations से match नहीं रहे

VGA assets बदलना और aspect ratio correction

  • समाधान है source code में शामिल .H, .EQU indexes से match करने के लिए regenerated VGA assets को game folder में copy करना
  • shareware assets इस्तेमाल करते समय file extension को .WL6 से .WL1 में बदलकर copy करना होगा
    • VGADICT.WL6 → VGADICT.WL1
    • VGAGRAPH.WL6 → VGAGRAPH.WL1
    • VGAHEAD.WL6 → VGAHEAD.WL1
  • replacement के बाद WOLF3D.EXE दोबारा चलाएं तो game सही तरह काम करता है
  • DosBox की default screen 1992 में लोगों ने जो मूल screen देखी थी, उससे अलग है
    • VGA framebuffer 320x200 है
    • CRT monitor का aspect ratio 4:3 था, इसलिए output vertical direction में stretched दिखता था
  • DosBox settings में [render] के aspect=false को aspect=true में बदलने पर aspect ratio correction लागू होता है
  • aspect ratio correction लागू करने तक, Wolfenstein 3D उस समय के CRT display तरीके के करीब रूप में चलता है

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

1 टिप्पणियां

 
GN⁺ 2024-02-27
Hacker News की रायें

  • लेख के अंत में उल्लेख की गई Wolfenstein 3D किताब की ज़ोरदार सिफारिश करता हूँ। तकनीकी सामग्री होने के बावजूद यह रूखी या उबाऊ नहीं है, और इसमें पुराने दौर की बहुत-सी optimizations हैं—जैसे wall texture scaling के लिए फैलाकर रखे गए 64 functions, sprites को “साइडवेज़” स्टोर करने का तरीका, अजीब graphics cards से निपटना, और शुरुआत में ही game जैसा दिखाने के लिए graphics mode को hack करना

    • सिफारिश के लिए धन्यवाद। मैंने अभी game engine पर 431-पेज की PDF डाउनलोड की है, जिसमें John Carmack की प्रस्तावना भी शामिल है
    • क्या तुम इसी किताब की बात कर रहे हो? https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      यह अभी रिलीज़ हुई लगती नहीं, सही है?
    • पूरी तरह सहमत। मुझे पता भी नहीं था कि ऐसी किताब है, लेकिन Wolfenstein 3D और Doom—दोनों किताबें वाकई मज़े से पढ़ीं। अफ़सोस है कि वह Quake/i586 किताब नहीं लिखेंगे
    • इसकी sequel Doom किताब भी शानदार पढ़ने लायक है

  • retro systems की अच्छी बात यह है कि tools इकट्ठा कर लें तो उन्हें फिर से build किया जा सकता है। हाल ही में मज़े के लिए पुराने Uplink game को फिर से compile किया; बस Visual Studio 6.0 चाहिए था, और development archive में build के लिए ज़रूरी सारी dependencies मौजूद थीं
    dependencies ठीक करने में करीब एक घंटा लगा, लेकिन आखिरकार सफल रहा और game भी ठीक चला। कुछ छोटी खामियाँ भी ठीक कीं और इधर-उधर छोटे improvements भी जोड़े। आज के software के साथ ऐसा करने की सोचें तो यह वाकई पागलपन लगेगा

    • यह बात ज़्यादा तब लागू लगती है जब Linux package management खराब हो। मैंने commercial embedded/Windows side में आम तौर पर dependencies को thirdparty/ folder में vendor करते देखा है, और इस्तेमाल होने वाला toolchain भी pin किया होता है, इसलिए setup हमेशा reproducible रहता था
    • आजकल ज़रूरी चीज़ों का बड़ा हिस्सा बस सही version का Unity या Unreal install करना है। Unity से पहले के दौर के लिए यह बात निश्चित रूप से सही है
    • मुझे पता नहीं था कि Uplink source code public है। शानदार game

  • मैंने programming Borland Turbo C++ से सीखी। उस समय की याद आने की एक वजह यह है कि जटिल दिखने वाले काम बहुत आसानी से हो जाते थे। geometry functions को call करते ही screen पर drawing बन जाती थी, और shape draw करने के बाद थोड़े अलग shape पर xor function call कर दें तो animation भी बना सकते थे
    दोस्तों के साथ इन techniques से Final Fantasy जैसा game बनाया था—हाथ से बनाए sprites, screen-based maps, edge पर जाने से adjacent map में जाने वाली world, और हर step पर natural number 1 आने पर battle में जाने वाला structure तक बनाया। झंझट तो था, लेकिन high school student के लिए बेहद मज़ेदार था, और आज की तरह शुरुआत से ही SFML, ActiveX, OpenGL सीखने के बजाय बस circle call कर देना बहुत बड़ी बात थी

    • बच्चों के लिए simple shapes programming करने वाला environment ढूँढना हो तो आज भी शायद ऐसी चीज़ें मिल जाएँगी। फर्क यह है कि “professional tools” और “kids/beginner tools” के बीच दूरी अब ज़्यादा बढ़ गई है, जबकि Turbo C++ या मेरे समय का Turbo Pascal दोनों के करीब था
    • बचपन में Borland Turbo C++ और learning material मिल पाना थोड़ा ईर्ष्या करने जैसा लगता है। मेरे पास तो local computer magazine की reviews पढ़ने तक ही बात थी, और अगर copy मिल भी जाती तो पढ़ने की सामग्री के बिना समझ नहीं आता कि करना क्या है। उस समय मेरी English के हिसाब से, material होने पर भी कितना समझ पाता, पता नहीं
    • modern 2D graphics framebuffer में pixels डालने के तरीके पर नहीं चलती; textures या surfaces system की basic units हैं और composition अलग step के रूप में handle होता है। इसलिए “simple sprite” बनाना उल्टा आसान हो गया है, और composed surface को hardware sprite का ज़्यादा general form माना जा सकता है
    • अच्छे पुराने conio.h और Borland के BGI graphics.h की याद आती है। आजकल SDL कुछ हद तक वही भूमिका निभाता है, लेकिन उतना simple नहीं है
    • Borland Turbo C++ आज भी मेरी सबसे पसंदीदा IDE है, और बहुत बड़े अंतर से नंबर 1

  • यहाँ कई सालों से इसका बार-बार ज़िक्र देखकर कुछ महीने पहले आखिरकार मैंने Masters of Doom पढ़ी, और यह शानदार किताब थी। उस समय वे जो games बना रहे थे, वे खेलने में भी बेहद रोमांचक थे, लेकिन पीछे मुड़कर देखें तो कम संसाधनों वाले कुछ युवा developers क्या बना सकते थे—यह और भी ज़्यादा प्रेरणादायक है

    • Romero ने हाल ही में memoir Doom Guy निकाली है; जानना चाहूँगा कि किसी ने पढ़ी है या नहीं। क्या यह अच्छी किताब है?

  • DOS की text-based UI की बहुत याद आती है। 1997 के आसपास तक इस्तेमाल किए गए भरोसेमंद PS/2 की याद आ गई

    • terminal में Midnight Commander तो इस्तेमाल कर ही सकते हैं

  • C drive पर install करना—क्या luxury थी! Hard disk नहीं थी, इसलिए A और B drives के बीच floppy बार-बार बदलनी पड़ती थी, और compiler बार-बार बदले हुए हिस्से माँगता था। फिर भी हम मज़े लेते थे। आजकल के बच्चे ऐसी बातें सुनाएँ तो यकीन नहीं करेंगे

    • 1992 में मेरे पास 8.9MB की 5.25-inch double-height hard disk थी, और दो 5.25-inch 360KB floppy drives भी थीं। दोस्त के 720KB disk drive और 30MB hard disk वाले Mac से जलन होती थी, लेकिन वह system शायद मेरे PC से करीब 6 गुना महँगा था
    • बात 1992 की है, 1982 की नहीं

  • Borland C++ वाकई कमाल था। C++ compiler, standard library और debugger वाली IDE करीब 5MB में आ जाती थी, और पीले अक्षरों व नीले background वाला आरामदेह Borland color palette भी था

    • C++ tutorial वाला printed manual भी साथ आता था। मैंने उसी से पहले C++ सीखी थी
    • OWL भी काफी अच्छा था
    • Zortech कहीं बेहतर था

  • Borland के MS-DOS IDEs मीठी यादें हैं

    • अगर ऐसी nostalgia है तो Free Pascal देखना बनता है। यह open-source Pascal/Delphi clone है, और इसमें blue DOS Turbo Pascal editor का clone भी शामिल है, जिससे मनचाहा माहौल मिल जाता है
      इस साल Advent of Code के कुछ दिनों के लिए इस्तेमाल किया, लेकिन nostalgia जल्दी ही उतर गई। Modern environment की आदत पड़ जाने के बाद IDE की सीमाएँ और Pascal की verbosity रोज़ इस्तेमाल के लिए “fun” नहीं थीं। फिर भी यादें निश्चित रूप से मीठी हैं
    • RHIDE का आखिरी update 23 साल पहले हुआ था, फिर भी शायद source code अब भी मौजूद होगा। ऐसे terminal-mode GUI implement करते समय असली समस्या यह है कि Unix/Linux terminals ऐसे terminal standards में फँसे थे जो MS-DOS text-mode programs की सभी capabilities नहीं देते थे
      खासकर standalone Alt key input, Alt+letter combinations, और Ctrl+Shift+left/right arrow keys को recognize नहीं कर पाते
    • पुराने bookshelf space में Turbo C manuals वाला box अब भी रखा है

  • संबंधित लेख: Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - फरवरी 2017, 80 comments

  • archive खोलने में समस्या हुई। wolfsrc.zip पर End-of-central-directory signature not found error आया, और बताया गया कि यह zip file नहीं है या कई disks में बँटे archive का हिस्सा हो सकता है