प्रस्तावना

अच्छे दिन, हम एक्स-रे ऑक्सीजन इंजन के बारे में बात करेंगे, या इसके बजाय, एक्स-रे ऑक्सीजन के कांटे के बारे में दिसंबर 2016 में, एक्स-रे ऑक्सीजन परियोजना प्रकाशित हुई थी। फिर मैंने इसे अकेले विकसित किया और इस बारे में सपने में नहीं सोचा कि यह इस समय क्या हो गया है।

मार्च में, मेरे पास यह विचार आया: "सभी को x64 में स्थानांतरित क्यों नहीं किया?" जैसा कि आप समझते हैं, यह इस विचार के बारे में है, या इसके कार्यान्वयन के बारे में है, जिस पर चर्चा की जाएगी।

प्रोजेक्ट असेंबली

पहला कदम x64 प्लेटफ़ॉर्म के तहत पूरी चीज़ डालने के लिए कोड को पोर्ट कर रहा था। परियोजनाओं की स्थापना के बाद, मैं पहली समस्या में भाग गया ... नहीं, Ptr फ़ंक्शन नहीं, लेकिन कोडांतरक आवेषण ...

__forceinline void fsincos( const float angle , float &sine , float &cosine ) { __asm { fld DWORD PTR [angle] fsincos mov eax , DWORD PTR [cosine] fstp DWORD PTR [eax] mov eax , DWORD PTR [sine] fstp DWORD PTR [eax] } } 

इस कोड की सुंदरता अनुकूलन थी, लेकिन x64 में MSBuilder ने इसका समर्थन नहीं किया और अभी भी इसका समर्थन नहीं करता है। इस कोड को ज्यादातर std analogues से बदला जा सकता है, ऐसे स्थान थे जिन्हें आसानी से आंतरिक में बदला जा सकता था, उदाहरण के लिए, जैसे:

 __asm pause; 

इसे सुरक्षित रूप से प्रतिस्थापित किया जा सकता है:

 _mm_pause(); 

इंजन में भी, कभी-कभी मूल कोड पर कार्यों के एनालॉग होते थे (प्रशंसा सीपीयूआईडी प्रणाली के लिए हो)। लेकिन ऐसी जगहें थीं जिनसे आपको छुटकारा पाना था। उदाहरण के लिए, MMX निर्देश गुमनामी में डूब गए हैं। सौभाग्य से, उन्हें कहीं भी नहीं बुलाया गया था, लेकिन बस संकलित किया गया और बेकार हो गया।

संचालनीयता

विधानसभा पर सभी संपादन के बाद, अगला चरण शुरू हो गया है: यह सब कैसे शुरू करें?

पहला गद्दार LJJIT था। दुर्भाग्य से, LuaJIT ने x64 में केवल संस्करण 2.0.5 के साथ ठीक (अच्छा, लगभग ...) काम करना शुरू कर दिया। और वे छोटे अंकों से स्मृति आवंटन की छोटी समस्याएं थीं। लेकिन, तब मुझे इसके बारे में पता नहीं था और पहली चीज जो मैंने देखी थी वह थी LuaJIT और लुढ़की हुई वैनिला लुआ 5.1। हां, इससे समस्या ठीक हो गई, लेकिन गति ... याद रखें, हम शोक करते हैं। बाद में मंच पर मुझे बताया गया कि आप LuaJIT 2.0.4 का उपयोग करने का प्रयास कर सकते हैं। और हां, इससे मदद मिली, मैंने खेल शुरू किया और मुख्य मेनू में जाने में सक्षम था!

लेकिन ... खुशी अल्पकालिक थी ... ऑफसेट, डेटा प्रकार और xrCDB को नमस्कार। खेल ने स्तर को लोड नहीं किया, सामग्री वस्तुओं पर उड़ गई और इंजन को यह बहुत पसंद नहीं आया। कुछ दिनों के बाद, मैं पूरी तरह से निराश हो गया और उसने उपनाम गिपरियन के तहत एक अधिक अनुभवी प्रोग्रामर से मदद मांगने का फैसला किया। मैंने परियोजना में उनकी भागीदारी पर भरोसा नहीं किया, मेरा सपना सिर्फ सलाह था। लेकिन, इस तरह, मुझे परियोजना में एक अनुभवी डेवलपर मिला। उसी क्षण से, एक टीम का गठन हुआ।

अगली समस्या OPCODE और डेटा प्रकार थे। मुझे सभी udwords (अहस्ताक्षरित int) को uqwords (अहस्ताक्षरित लंबे समय) में अनुवाद करना था। केवल इसे समझने के लिए, मुझे डिबगर के तहत लगभग 4 घंटे बिताने पड़े।

लेकिन, यह समस्या का केवल एक हिस्सा था। यह सामग्रियों की बारी थी। हमारे पास क्या है:

 union { u32 dummy; // 4b struct { u32 material : 14; // u32 suppress_shadows : 1; // u32 suppress_wm : 1; // u32 sector : 16; // }; }; 

X32 में ऐसा कोड जादू #pragma pack(4) द्वारा सहेजा गया था, लेकिन x64 के लिए किसी कारण से यह नहीं बचा। संरेखण की बारी आई, एक डिबग के माध्यम से हमें पता चला कि कुछ मामलों के लिए संरचना में डेटा मान्य थे, लेकिन दूसरों के लिए नहीं। हमने संरचना को फिर से बनाया और कनवर्टर को वैध बनाया। संरचना का निम्न रूप है:

 union { size_t dummy; struct { size_t material:14; // size_t suppress_shadows:1; // size_t suppress_wm:1; // size_t sector:16; // size_t dumb : 32; // ,     x64. }; 

और सत्यापनकर्ता इस तरह था:

 ... if (rebuildTrisRequired) { TRI_DEPRECATED* realT = reinterpret_cast<TRI_DEPRECATED*> (T); for (int triIter = 0; triIter < tris_count; ++triIter) { TRI_DEPRECATED& oldTri = realT[triIter]; TRI& newTri = tris[triIter]; newTri = oldTri; } } else { std::memcpy(tris, T, tris_count * sizeof(TRI)); } ... 

इस प्रकार, कॉल के भाग को फिर से तैयार किए गए ध्वज के कारण बदलना पड़ा, लेकिन खेल शुरू करने में सक्षम था।

लेकिन, समय के साथ, कणों के साथ समस्या आई:

 real_ptr = malloc( sizeof( Particle ) * ( max_particles + 1 ) ); particles = (Particle*)((DWORD)real_ptr + (64 - ((DWORD)real_ptr & 63))); 

इस कोड से मूल कणों के साथ समस्या नहीं हुई। वे बहुत सरल थे और चुपचाप उनके लिए आवंटित स्मृति में फिट थे। लेकिन अधिक जटिल और रंगीन विवरणों के साथ, जो मॉडमेकर्स द्वारा किए गए थे, स्मृति से प्रस्थान आए थे। x64 और मेमोरी से क्रैश, ऐसा कैसे?! कोड फिर से तैयार किया गया है, प्रस्थान चले गए हैं:

 particles = alloc<Particle>(max_particles); 

खेल की समस्याएं

पहली समस्या, फिर से, LuaJIT थी

स्मार्ट कवर के लिए यूजरडेटा ने उड़ान भरी। इस समस्या को लगभग बहुत ही अंतिम रूप दिया गया है। बस जारी किए गए LuaJIT 2.0.5 से संपादन स्थानांतरित कर रहा है।

अगली समस्या: झांकियों की भौतिकी और गणना। control87 में infinity गणना के लिए control87 और control87 को अवरुद्ध कर दिया गया था ... आइटम के गिरने के साथ एक बड़ी समस्या थी, तीन से एक बार वे सही ढंग से गिर गए। कभी-कभी वे अंतरिक्ष में, कभी-कभी टेर्रान के नीचे उड़ गए। समस्या केवल एक चर में थी, जिसे मूल्य अनंत दिया गया था। स्थिति FLT_MAX द्वारा तय की गई थी, सभी प्लेटफार्मों के लिए समान।

 surface.mu = dInfinty // x32 surface.mu = FLT_MAX // x64 

अंतिम समस्या कणों की गति थी। निम्नलिखित कोड पर ध्यान दें:

 DWORD angle = 0xFFFFFFFF; ... if (angle != *((DWORD*)&m.rot.x)) { angle = *((DWORD*)&m.rot.x); fsincos(angle, sina, cosa); } 

सब कुछ क्रम में लगता है। लेकिन, x64 में 0xFFFFFFFF का एक अलग अर्थ है जब एक फ्लोटिंग पॉइंट प्रकार में कनवर्ट किया जाता है। तथ्य यह है कि fsincos में एक डबल समकक्ष है, और x64 दोहरा डेटा पसंद करता है। और दोहरे मूल्य में यह बहुत अधिक मायने रखता है। तैरने में परिवर्तित होने से स्थिति बच गई।

 DWORD angle = 0xFFFFFFFF; ... if (angle != *((DWORD*)&m.rot.x)) { angle = *((DWORD*)&m.rot.x); // fsincos(angle, sina, cosa); fsincos(*(float*)&angle, sina, cosa); } 

निष्कर्ष

अंत में, मैं केवल एक बात कहना चाहता हूं: x64 में बंदरगाह बहुत कुछ नया ज्ञान लाया जो भविष्य में उपयोगी होगा। मैंने आपको कई पोर्टिंग मुद्दों के बारे में बताया। और फिर सब कुछ आप पर निर्भर करेगा यदि आप किसी भी OpenSource प्रोजेक्ट में ऐसा करने का निर्णय लेते हैं।

पढ़ने के लिए धन्यवाद!