- Half-Life 2 के शुरुआती दृश्य में एक अजीब bug मिला, जिसमें दरवाज़ा नहीं खुलता और प्रगति रुक जाती है
- वजह यह थी कि दरवाज़ा खुलते समय अंदर खड़े guard के पैर की उंगलियाँ दरवाज़े के रास्ते से टकरा जाती थीं, जिससे दरवाज़ा फिर बंद होकर लॉक हो जाता था
- मूल कोड में भी यही टक्कर मौजूद थी, लेकिन 2004 के x87 floating-point operations और 2013 के SSE operations की precision के अंतर से नतीजा बदल गया
- x87 environment में हल्के rotation से पैर थोड़ा खिसक जाता है और टक्कर हट जाती है, लेकिन SSE में rotation कम होने से दरवाज़ा बंद हो जाता है
- यह मामला दिखाता है कि floating-point precision और compiler differences असली game behavior पर कितना असर डाल सकते हैं
Half-Life 2 VR porting के दौरान मिला bug
- 2013 में Valve ने Team Fortress 2 को VR में port करने का प्रयोग किया, और उसी engine का इस्तेमाल करने वाले Half-Life 2 और Portal 1 भी VR में चलने लगे
- Portal 1 में viewpoint distortion की वजह से VR में खेलना लगभग असंभव था और बहुत चक्कर आते थे
- Half-Life 2 अपेक्षाकृत अच्छी तरह चला, और boat scenes, box stacking, तथा manhack combat जैसे हिस्सों में VR immersion बेहतर लगा
- testing के दौरान एक developer ने गेम को शुरू से अंत तक VR में खेलते हुए शुरुआती train station scene में progression block खोजा
दरवाज़ा न खुलने के कारण का विश्लेषण
- मूल scenario में guard (असल में Barney) दरवाज़ा खटखटाता है, “अंदर जाओ” कहता है, और खिलाड़ी के कमरे में जाने पर अगला script शुरू होता है
- लेकिन bug की स्थिति में दरवाज़ा खड़खड़ाकर लॉक हो जाता है और पूरी तरह बंद हो जाता है, guard बार-बार दरवाज़े की ओर इशारा करता रहता है और खिलाड़ी फँस जाता है
- मूल Half-Life 2 source code को दोबारा build करने पर भी वही समस्या आई, जिससे यह जैसे समय में पीछे जाकर पैदा हुआ bug लगा
मूल कारण: floating-point calculation method में बदलाव
- 2004 में रिलीज़ के समय Half-Life 2 ने x87 math instruction set का इस्तेमाल किया था, जिसमें 32, 64 और 80-bit precision का मिश्रण था
- 2013 के बाद के builds में SSE instruction set default हो गया, जिसमें calculation precision साफ़ तौर पर 32-bit या 64-bit तक सीमित रही
- दोनों environments में दरवाज़ा और guard के पैर की उंगलियाँ टकराती हैं, लेकिन physics engine की बहुत सूक्ष्म calculation differences से नतीजा बदल जाता है
- x87 में टक्कर के समय guard बहुत थोड़ा rotate होता है, पैर दरवाज़े से हट जाता है और दरवाज़ा खुल जाता है
- SSE में rotation थोड़ा कम होता है, पैर संपर्क में बना रहता है और दरवाज़ा फिर बंद होकर लॉक हो जाता है
सुधार और समाधान
- समस्या समझ में आने के बाद, guard की position को लगभग 1mm पीछे खिसकाने जैसी सरल fixing से इसे हल किया गया
- debugging के दौरान पुराने tools को फिर से इस्तेमाल करना सीखना पड़ा, और इसमें काफ़ी समय लगा
- यह मामला दिखाता है कि precision differences और compiler settings changes पुराने code के behavior को बदल सकते हैं
community की प्रतिक्रिया
- developers ने सहमति जताई कि “समस्या हमेशा floating-point precision की ही होती है”
- कुछ लोगों ने Sonic 1, 2, 3 remakes में collision calculation changes के उदाहरण देकर समानता बताई
- “code वही है, लेकिन compiler अलग है” जैसे सबक के साथ इसे legacy code maintenance की कठिनाई याद दिलाने वाला मामला माना गया
- दूसरे developers ने Fallout 4 जैसे games में NPCs को दरवाज़ों से न गुज़रने देने की design choice को भी इसी तरह की समस्याओं से जोड़ा
- कुल मिलाकर, इसे “सबसे दिलचस्प bug stories में से एक” जैसी प्रतिक्रिया मिली
1 टिप्पणियां
Hacker News की राय
पहले जब मैं game development करता था, तब FPU calculation error की वजह से सिर्फ कुछ खास PC पर assertion fail होने की घटना याद है
कारण यह था कि handwriting input software सभी process में DLL inject करते हुए FPU mode को default पर reset कर देता था
आखिरकार FPU setting code को initialization चरण से event loop में ले जाया गया, ताकि third-party DLL के असर से बचा जा सके
मेरे लक्ष्यों में से एक है Valve को Nix इस्तेमाल करने के लिए तैयार करना
Windows support पर काम चल रहा है, इसलिए मुझे लगता है यह और आकर्षक लगेगा
ऐसा होने पर न सिर्फ मूल source बल्कि उस समय का toolchain और dependency भी पूरी तरह reproduce किया जा सकेगा, और ऐसे bug की जड़ वजह ढूंढ़ना भी कहीं आसान हो जाएगा
इससे “DOOR STUCK” meme याद आ गया
संबंधित वीडियो
सोच रहा हूँ कि “Half-Life 2 VR beta” क्या वास्तव में playable है
अगर है, तो मुझे इसके बारे में पता क्यों नहीं था, और अगर नहीं है, तो अभी तक क्यों नहीं है
मैं Portal VR भी ज़रूर आज़माना चाहता हूँ। लोग कहते हैं कि उसमें motion sickness बहुत होता है, लेकिन मुझे VR motion sickness नहीं होती, इसलिए कोशिश करने लायक है
उसकी quality इतनी अच्छी है कि उसने मुझे लंबे समय बाद फिर से HL2 खेलने पर मजबूर कर दिया
x87 से SSE पर switch करने पर कुछ calculations का टूट जाना आम बात है
TF2 में भी यही हुआ था, जहाँ Linux build में SSE इस्तेमाल होने की वजह से ammo calculation थोड़ी अलग थी
छोटे box से +40 या +41 मिलता था, और यह server OS के अनुसार बदलता था
हर नए server पर जुड़ते समय यह देखना मज़ेदार होता था कि वह कौन-सा OS है
अगर सिर्फ x87 से SSE पर बदलने भर से game टूट सकता है, तो x86→ARM conversion इतना अच्छा कैसे काम कर लेता है, यह सच में दिलचस्प है
यह 80-bit register इस्तेमाल करता है, इसलिए precision ज़्यादा होती है, लेकिन memory में spill होने पर precision खो देता है और इस तरह का अजीब behavior दिखाता है
पहले software synthesizer debug करते समय मैंने भी ऐसा ही precision bug देखा था
RC circuit simulation में state बदलने के लिए मान का 0 के क़रीब पहुँचना ज़रूरी था, लेकिन कुछ CPU पर denormal values flush नहीं हो रही थीं, इसलिए शर्त पूरी नहीं हो पाती थी
आखिर में 0.7 और 0.01 जैसे लगभग अनुमानित threshold सेट कर दिए, तो वह सभी platform पर ठीक से काम करने लगा
meta बात के तौर पर, मैं एक Twitter clone बनाऊँगा और उसमें कई paragraph में blogging करने पर तुरंत ban करने वाला feature डालूँगा