न्यूरोमांसर का उलटा। भाग 3: समाप्त प्रतिपादन, खेल बना

नमस्ते, यह मेरे प्रकाशनों की श्रृंखला का तीसरा भाग है, जो न्यूरोमांसर के रिवर्स विकास के लिए समर्पित है - विलियम गिब्सन द्वारा इसी नाम के उपन्यास का एक वीडियो गेम अवतार।

न्यूरोमांसर का उलटा। भाग 1: स्प्राइट्स
न्यूरोमांसर का उलटा। भाग 2: रेंडर फ़ॉन्ट

यह हिस्सा कुछ अव्यवस्थित लग सकता है। तथ्य यह है कि यहां जो कुछ भी वर्णित है, उनमें से अधिकांश पिछले एक लिखने के समय तैयार था। जब से दो महीने पहले ही समाप्त हो चुके हैं, और, दुर्भाग्य से, मुझे काम नोट रखने की आदत नहीं है, मैं बस कुछ विवरण भूल गया हूं। लेकिन जैसा है, चलिए।

[जब मैंने लाइनों को प्रिंट करना सीख लिया, तो संवाद बॉक्स के निर्माण को उलट देना जारी रखना तर्कसंगत होगा। लेकिन, किसी कारण से मुझे भागने के बजाय, मैं पूरी तरह से प्रतिपादन प्रणाली के विश्लेषण में चला गया।] एक बार फिर, main साथ चलते हुए, मैं उस कॉल को स्थानीयकृत करने में सक्षम था जो पहले स्क्रीन पर कुछ प्रदर्शित करता है: seg000:0159: call sub_1D0B2 । "कुछ भी", इस मामले में, मुख्य मेनू का कर्सर और पृष्ठभूमि छवि है:

यह उल्लेखनीय है कि sub_1D0B2 फ़ंक्शन [इसके बाद - render ] का कोई तर्क नहीं है, हालाँकि, इसकी पहली कॉल दो, कोड के लगभग समान वर्गों से पहले की है:

 loc_100E5: loc_10123: mov ax, 2 mov ax, 2 mov dx, seg seg009 mov dx, seg seg010 push dx push dx push ax push ax mov ax, 506Ah mov ax, 5076h ; "cursors.imh", "title.imh" push ax push ax call load_imh call load_imh ; load_imh(res, offt, seg) add sp, 6 add sp, 6 sub ax, ax sub ax, 0Ah push ax push ax call sub_123F8 call sub_123F8 ; sub_123F8(0), sub_123F8(10) add sp, 2 add sp, 2 cmp word_5AA92, 0 mov ax, 1 jz short loc_10123 push ax sub ax, ax mov ax, 2 push ax mov dx, seg seg010 mov ax, 2 push dx mov dx, seg seg009 push ax push dx sub ax, ax push ax push ax mov ax, 64h push ax push ax mov ax 0Ah mov ax, 0A0h push ax push ax call sub_1CF5B ; sub_1CF5B(10, 0, 0, 2, seg010, 1) sub ax, ax add sp, 0Ch push ax call render call sub_1CF5B ; sub_1CF5B(0, 160, 100, 2, seg009, 0) add sp, 0Ch 

render कॉल render से पहले, कर्सर (कर्सर) ( cursors.imh ) और बैकग्राउंड ( title.imh ) को मेमोरी में अनपैक किया जाता है ( load_imh को पहले भाग से बदला गया sub_126CB है), क्रमशः नौवें और दसवें खंडों में। फ़ंक्शन का एक सतही अध्ययन sub_123F8 ने मुझे कोई नई जानकारी नहीं दी, लेकिन, केवल sub_1CF5B के तर्कों को sub_1CF5B , मैंने निम्नलिखित निष्कर्ष दिए:

• तर्कों 4 और 5 को एक साथ लिया गया, विघटित स्प्राइट ( segment:offset ) के पते का प्रतिनिधित्व करते हैं;
• तर्क 2 और 3 संभवतः निर्देशांक हैं, क्योंकि ये नंबर कॉल render बाद प्रदर्शित छवि के साथ सहसंबंधित render ;
• अंतिम तर्क स्प्राइट की पृष्ठभूमि की अस्पष्टता का झंडा हो सकता है, क्योंकि अनपैक किए गए स्प्राइट में एक काली पृष्ठभूमि होती है, और हम इसके बिना स्क्रीन पर कर्सर देखते हैं।

पहले तर्क के साथ [और सामान्य रूप में प्रतिपादन के साथ एक ही समय में] सब कुछ सब sub_1CF5B को ट्रेस करने के बाद स्पष्ट हो गया। तथ्य यह है कि डेटा खंड में, पता 0x3BD4 शुरू होता है, निम्न प्रकार की 11 संरचनाओं की एक सरणी स्थित है:

 typedef struct sprite_layer_t { uint8_t flags; uint8_t update; uint16_t left; uint16_t top; uint16_t dleft; uint16_t dtop; imh_hdr_t sprite_hdr; uint16_t sprite_segment; uint16_t sprite_pixels; imh_hdr_t _sprite_hdr; uint16_t _sprite_segment; uint16_t _sprite_pixels; } sprite_layer_t; 

मैं इस अवधारणा को स्प्राइट चेन कहता हूं। वास्तव में, sub_1CF5B फ़ंक्शन (इसके बाद add_sprite_to_chain ) चयनित स्प्राइट को श्रृंखला में जोड़ता है। 16-बिट मशीन पर, इसमें लगभग निम्नलिखित हस्ताक्षर होंगे:

 sprite_layer_t g_sprite_chain[11]; void add_sprite_to_chain(int index, uint16_t left, uint16_t top, uint16_t offset, uint16_t segment, uint8_t opaque); 

यह इस तरह काम करता है:

• पहला तर्क g_sprite_chain सरणी में अनुक्रमणिका है;
• left और top तर्क g_sprite_chain[index].left और g_sprite_chain[index].top को लिखे जाते हैं;
• स्प्राइट हेडर ( segment:offset पर स्थित पहले 8 बाइट्स segment:offset ) को g_sprite_chain[index].sprite_hdr टाइप किया imh_hdr_t , imh_hdr_t (पहले भाग से बदला गया rle_hdr_t ):

 typedef struct imh_hdr_t { uint32_t unknown; uint16_t width; uint16_t height; } imh_hdr_t; 

• फ़ील्ड g_sprite_chain[index].sprite_segment segment का मान रिकॉर्ड करता है;
• g_sprite_chain[index].sprite_pixels , offset + 8 बराबर एक मान लिखा offset + 8 है, इसलिए sprite_segment:sprite_pixels बिटमैप का पता है;
• sprite_hdr , sprite_segment , और sprite_pixels क्रमशः _sprite_hdr , _sprite_segment , और _sprite_pixels गए हैं [क्यों? - मुझे पता नहीं है, और यह खेतों के ऐसे दोहराव का एकमात्र मामला नहीं है] ;
• फ़ील्ड में g_sprite_chain[index].flags 1 + (opaque << 4) बराबर मान लिखा 1 + (opaque << 4) है 1 + (opaque << 4) । इस प्रविष्टि का मतलब है कि flags मूल्य का पहला बिट "वर्तमान" परत की "गतिविधि" को इंगित करता है, और पांचवें बिट इसकी पृष्ठभूमि की अस्पष्टता को इंगित करता है। [पारदर्शी चित्र पर इसके प्रभाव का परीक्षण करने के बाद पारदर्शिता ध्वज के बारे में मेरा संदेह दूर हो गया। पांचवीं बिट के रनटाइम के मूल्य को बदलते हुए, हम इन कलाकृतियों का अवलोकन कर सकते हैं]:
  
  

जैसा कि मैंने पहले ही उल्लेख किया है, render फ़ंक्शन का कोई तर्क नहीं है, लेकिन इसकी आवश्यकता नहीं है - यह सीधे g_sprite_chain सरणी के साथ काम करता है, बारी-बारी से "लेयर्स" को VGA मेमोरी में ट्रांसफर करता है, आखिरी ( g_sprite_chain[10] - बैकग्राउंड) ( g_sprite_chain[0] - अग्रभूमि)। sprite_layer_t संरचना में इसके लिए आवश्यक सब कुछ है और इससे भी अधिक। मैं dleft फ़ील्ड update , dleft और dtop बारे में बात कर रहा हूँ।

वास्तव में, render फ़ंक्शन प्रत्येक फ्रेम में सभी स्प्राइट्स को फिर से नहीं बनाता है। g_sprite_chain.update फ़ील्ड का एक गैर-शून्य मान इंगित करता है कि वर्तमान स्प्राइट को फिर से g_sprite_chain.update करने की आवश्यकता है। मान लीजिए कि हम कर्सर को स्थानांतरित करते हैं ( g_sprite_chain[0] ), तो माउस हैंडलर में ऐसा कुछ होगा:

 void mouse_move_handler(...) { ... g_sprite_chain[0].update = 1; g_sprite_chain[0].dleft = mouse_x - g_sprite_chain[0].left; g_sprite_chain[0].dtop = mouse_y - g_sprite_chain[0].top; } 

जब नियंत्रण render फ़ंक्शन को पास करता है, तो बाद वाला, g_sprite_chain[0] लेयर पर पहुंच जाता है, देखता है कि इसे अपडेट करने की आवश्यकता है। तब:

• सभी पिछली परतों के साथ अद्यतन करने से पहले कर्सर स्प्राइट के कब्जे वाले क्षेत्र के चौराहे की गणना और खींचा जाएगा;
• स्प्राइट निर्देशांक अपडेट किए जाएंगे:

 g_sprite_chain[0].update = 0; g_sprite_chain[0].left += g_sprite_chain[0].dleft g_sprite_chain[0].dleft = 0; g_sprite_chain[0].top += g_sprite_chain[0].dtop g_sprite_chain[0].dtop = 0; 

• स्प्राइट अद्यतन निर्देशांक पर तैयार किया जाएगा।

यह render फ़ंक्शन द्वारा किए गए संचालन की संख्या को कम करता है।

इस तर्क को लागू करना मुश्किल नहीं था, हालांकि मैंने इसे काफी सरल बना दिया। आधुनिक कंप्यूटरों की कंप्यूटिंग शक्ति को ध्यान में रखते हुए, हम प्रत्येक फ्रेम में सभी 11 चेन स्प्राइट्स को फिर से शुरू करने का खर्च उठा सकते हैं, इस वजह से g_sprite_chain.update , .dleft , .dtop और उनसे जुड़े सभी प्रोसेसिंग .dtop । एक और सरलीकरण अपारदर्शिता ध्वज को संभालने की चिंता करता है। मूल कोड में, स्प्राइट में प्रत्येक पारदर्शी पिक्सेल के लिए, निचली परतों में पहले अपारदर्शी पिक्सेल वाले चौराहे की खोज की जाती है। लेकिन मैं 32-बिट वीडियो मोड का उपयोग करता हूं, और इसलिए मैं आरजीबीए योजना में पारदर्शिता बाइट के मूल्य को बदल सकता हूं। नतीजतन, मुझे एक श्रृंखला (एक) के लिए एक स्प्राइट जोड़ने (हटाने) के ऐसे कार्य मिले:

 typedef struct sprite_layer_t { uint8_t flags; uint16_t left; uint16_t top; imh_hdr_t sprite_hdr; uint8_t *sprite_pixels; imh_hdr_t _sprite_hdr; uint8_t *_sprite_pixels; } sprite_layer_t; sprite_layer_t g_sprite_chain[11]; void add_sprite_to_chain(int n, uint32_t left, uint32_t top, uint8_t *sprite, int opaque) { assert(n <= 10); sprite_layer_t *layer = &g_sprite_chain[n]; memset(layer, 0, sizeof(sprite_layer_t)); layer->left = left; layer->top = top; memmove(&layer->sprite_hdr, sprite, sizeof(imh_hdr_t)); layer->sprite_pixels = sprite + sizeof(imh_hdr_t); memmove(&layer->_sprite_hdr, &layer->sprite_hdr, sizeof(imh_hdr_t) + sizeof(uint8_t*)); layer->flags = ((opaque << 4) & 16) | 1; } void remove_sprite_from_chain(int n) { assert(n <= 10); sprite_layer_t *layer = &g_sprite_chain[n]; memset(layer, 0, sizeof(sprite_layer_t)); } 

एक परत को वीजीए बफर में स्थानांतरित करने का कार्य निम्नानुसार है:

 void draw_to_vga(int left, int top, uint32_t w, uint32_t h, uint8_t *pixels, int bg_transparency); void draw_sprite_to_vga(sprite_layer_t *sprite) { int32_t top = sprite->top; int32_t left = sprite->left; uint32_t w = sprite->sprite_hdr.width * 2; uint32_t h = sprite->sprite_hdr.height; uint32_t bg_transparency = ((sprite->flags >> 4) == 0); uint8_t *pixels = sprite->sprite_pixels; draw_to_vga(left, top, w, h, pixels, bg_transparency); } 

draw_to_vga फ़ंक्शन दूसरे भाग में वर्णित उसी नाम का कार्य है, लेकिन एक अतिरिक्त तर्क के साथ छवि पृष्ठभूमि की पारदर्शिता का संकेत है। render फंक्शन की शुरुआत में draw_sprite_to_vga कॉल जोड़ें (इसकी बाकी सामग्री दूसरे भाग से माइग्रेट की गई है):

 static void render() { for (int i = 10; i >= 0; i--) { if (!(g_sprite_chain[i].flags & 1)) { continue; } draw_sprite_to_vga(&g_sprite_chain[i]); } ... } 

मैंने एक फ़ंक्शन भी लिखा था जो माउस पॉइंटर ( update_cursor ), और एक साधारण संसाधन प्रबंधक की वर्तमान स्थिति के आधार पर कर्सर की स्थिति को अद्यतन करता है। हम यह सब काम एक साथ करते हैं:

 typedef enum spite_chain_index_t { SCI_CURSOR = 0, SCI_BACKGRND = 10, SCI_TOTAL = 11 } spite_chain_index_t; uint8_t g_cursors[399]; /* seg009 */ uint8_t g_background[32063]; /* seg010 */ int main(int argc, char *argv[]) { ... assert(resource_manager_load("CURSORS.IMH", g_cursors)); add_sprite_to_chain(SCI_CURSOR, 160, 100, g_cursors, 0); assert(resource_manager_load("TITLE.IMH", g_background)); add_sprite_to_chain(SCI_BACKGRND, 0, 0, g_background, 1); while (sfRenderWindow_isOpen(g_window)) { ... update_cursor(); render(); } ... } 

Kursor.GIF

ठीक है, एक पूर्ण-मुख्य मेनू के लिए, मेनू स्वयं वास्तव में पर्याप्त नहीं है। संवाद बॉक्सों के उलटने का समय है। [पिछली बार, मैंने draw_frame फ़ंक्शन को draw_frame , जो डायलॉग बॉक्स बनाता है, और, आंशिक रूप से, draw_string फ़ंक्शन, वहां से केवल टेक्स्ट रेंडरिंग लॉजिक ले रहा है।] draw_frame नए को देखते हुए, मैंने देखा कि add_sprite_to_chain फ़ंक्शन का उपयोग किया गया था - कुछ आश्चर्य की बात नहीं है, बस एक डायलॉग बॉक्स जोड़ रहा है। स्प्राइट श्रृंखला में। संवाद बॉक्स के अंदर पाठ की स्थिति से निपटने के लिए यह आवश्यक था। मुझे याद दिलाएं कि draw_string कॉल draw_string दिखता है:

  sub ax, ax push ax mov ax, 1 push ax mov ax, 5098h ; "New/Load" push ax call draw_string ; draw_string("New/Load", 1, 0) 

और draw_frame भरने का draw_frame [यहाँ थोड़ा आगे है, क्योंकि मैंने draw_string पूरी तरह से लगाने के बाद अधिकांश तत्वों का नाम बदल दिया है। वैसे, यहाँ, जैसा कि sprite_layer_t के मामले में, खेतों का दोहराव है] :

 typedef struct neuro_dialog_t { uint16_t left; // word[0x65FA]: 0x20 uint16_t top; // word[0x65FC]: 0x98 uint16_t right; // word[0x65FE]: 0x7F uint16_t bottom; // word[0x6600]: 0xAF uint16_t inner_left; // word[0x6602]: 0x28 uint16_t inner_top; // word[0x6604]: 0xA0 uint16_t inner_right; // word[0x6604]: 0xA0 uint16_t inner_bottom; // word[0x6608]: 0xA7 uint16_t _inner_left; // word[0x660A]: 0x28 uint16_t _inner_top; // word[0x660C]: 0xA0 uint16_t _inner_right; // word[0x660E]: 0x77 uint16_t _inner_bottom; // word[0x6610]: 0xA7 uint16_t flags; // word[0x6612]: 0x06 uint16_t unknown; // word[0x6614]: 0x00 uint8_t padding[192] // ... uint16_t width; // word[0x66D6]: 0x30 uint16_t pixels_offset; // word[0x66D8]: 0x02 uint16_t pixels_segment; // word[0x66DA]: 0x22FB } neuro_dialog_t; 

यहाँ क्या, कैसे और क्यों है, यह समझाने के बजाय, मैं सिर्फ इस छवि को छोड़ता हूँ:

चर x_offt और y_offt क्रमशः draw_string फ़ंक्शन के लिए दूसरा और तीसरा तर्क हैं। इस जानकारी के आधार पर, अपने स्वयं के संस्करणों का निर्माण करना आसान था draw_frame और draw_text , के बाद उनका नाम बदलकर build_dialog_frame और build_dialog_text :

 void build_dialog_frame(neuro_dialog_t *dialog, uint16_t left, uint16_t top, uint16_t w, uint16_t h, uint16_t flags, uint8_t *pixels); void build_dialog_text(neuro_dialog_t *dialog, char *text, uint16_t x_offt, uint16_t y_offt); ... typedef enum spite_chain_index_t { SCI_CURSOR = 0, SCI_DIALOG = 2, ... } spite_chain_index_t; ... uint8_t *g_dialog = NULL; neuro_dialog_t g_menu_dialog; int main(int argc, char *argv[]) { ... assert(g_dialog = calloc(8192, 1)); build_dialog_frame(&g_menu_dialog, 32, 152, 96, 24, 6, g_dialog); build_dialog_text(&g_menu_dialog, "New/Load", 8, 0); add_sprite_to_chain(SCI_DIALOG, 32, 152, g_dialog, 1); ... } 

मेरे संस्करणों और मूल लोगों के बीच मुख्य अंतर यह है कि मैं पिक्सेल आकार के पूर्ण मूल्यों का उपयोग करता हूं - यह आसान है।

फिर भी, मुझे यकीन था कि बटन बनाने के लिए कॉल करने के लिए तुरंत कॉल करने के लिए ज़िम्मेदार कोड अनुभाग build_dialog_text :

  ... mov ax, 5098h ; "New/Load" push ax call build_dialog_text ; build_dialog_text("New/Load", 1, 0) add sp, 6 mov ax, 6Eh ; 'n' -  push ax sub ax, ax push ax mov ax, 3 push ax sub ax, ax push ax mov ax, 1 push ax call sub_181A3 ; sub_181A3(1, 0, 3, 0, 'n') add sp, 0Ah mov ax, 6Ch ; 'l' -      push ax mov ax, 1 push ax mov ax, 4 push ax sub ax, ax push ax mov ax, 5 push ax call sub_181A3 ; sub_181A3(5, 0, 4, 1, 'l') 

यह सब इन उत्पन्न टिप्पणियों के बारे में है - 'n' और 'l' , जो स्पष्ट रूप से "New" और "load" शब्दों में पहले अक्षर हैं। इसके अलावा, अगर हम build_dialog_text साथ समानता से बहस करते हैं, तो sub_181A3 (इसके बाद - build_dialog_item ) के पहले चार तर्क निर्देशांक और आकारों के कारक हो सकते हैं [वास्तव में, पहले तीन तर्क, चौथे, जैसा कि यह निकला, चौथा, अन्य के बारे में] । यदि आप छवि पर इन मानों को ओवरले करते हैं तो सब कुछ परिवर्तित हो जाता है:

छवि में चर x_offt , y_offt और width , क्रमशः build_dialog_item फ़ंक्शन के पहले तीन तर्क हैं। इस आयत की ऊंचाई हमेशा प्रतीक की ऊंचाई के बराबर होती है - आठ। build_dialog_item पर बहुत ही नज़दीकी नज़र build_dialog_item , मुझे पता चला कि मैंने neuro_dialog_t संरचना में padding (अब items ) के रूप में जो निर्दिष्ट किया है, वह निम्न फ़ॉर्म की 16 संरचनाओं की एक सरणी है:

 typedef struct dialog_item_t { uint16_t left; uint16_t top; uint16_t right; uint16_t bottom; uint16_t unknown; /* index? */ char letter; } dialog_item_t; 

और फ़ील्ड neuro_dialog_t.unknown (अब - neuro_dialog_t.items_count ) मेनू में आइटमों की संख्या का काउंटर है:

 typedef struct neuro_dialog_t { ... uint16_t flags; uint16_t items_count; dialog_item_t items[16]; ... } neuro_dialog_t; 

dialog_item_t.unknown फ़ील्ड dialog_item_t.unknown चौथे तर्क के साथ build_dialog_item फ़ंक्शन के साथ प्रारंभ किया dialog_item_t.unknown है। शायद यह एरे में तत्व का सूचकांक है, लेकिन ऐसा लगता है कि यह हमेशा ऐसा नहीं होता है, और इसलिए unknown । dialog_item_t.letter फ़ील्ड dialog_item_t.letter build_dialog_item फ़ंक्शन के पांचवें तर्क के साथ आरंभीकृत किया गया है। फिर, यह संभव है कि बाएं क्लिक हैंडलर में गेम किसी एक आइटम के क्षेत्र में माउस पॉइंटर के निर्देशांक के लिए जाँच करता है (उदाहरण के लिए, क्रम में उन्हें छांट रहा है), और यदि कोई हिट है, तो एक विशिष्ट बटन पर क्लिक करने के लिए वांछित हैंडलर को इस क्षेत्र से चुना जाता है। [मुझे नहीं पता कि यह वास्तव में कैसे किया जाता है, लेकिन मैंने ठीक उसी तर्क को लागू किया है।]

यह एक पूर्ण-मुख्य मेनू बनाने के लिए पर्याप्त है, मूल कोड को वापस नहीं देख रहा है, लेकिन बस खेल में देखे गए अपने व्यवहार को दोहरा रहा है।

Glavnoe_Menyu.GIF

यदि आपने पिछले gif को अंत तक देखा है, तो संभवतः आपने अंतिम फ़्रेम पर स्टार्ट-अप गेम स्क्रीन देखी है। वास्तव में, मेरे पास इसे खींचने के लिए पहले से ही सब कुछ है। बस इसे लें और आवश्यक स्प्राइट्स डाउनलोड करें और उन्हें स्प्राइट चेन में जोड़ें। हालाँकि, मुख्य चरित्र के स्प्राइट को मंच पर रखकर, मैंने imh_hdr_t संरचना से संबंधित एक महत्वपूर्ण खोज की।

मूल कोड में, add_sprite_to_chain फ़ंक्शन, जो नायक की छवि को श्रृंखला में जोड़ता है, को निर्देशांक 156 और 110 के साथ कहा जाता है। यहां मैंने वही देखा, जो खुद को दोहरा रहा है:

यह पता लगाने के बाद कि क्या है, मुझे निम्न प्रकार की संरचना imh_hdr_t :

 typedef struct imh_hdr_t { uint16_t dx; uint16_t dy; uint16_t width; uint16_t height; } imh_hdr_t; 

एक unknown क्षेत्र के रूप में इस्तेमाल किया जाने वाला ऑफ़सेट मान जो स्प्रैड चेन में संग्रहीत संगत निर्देशांक (रेंडरिंग के दौरान) से घटाया जाता है।

इस प्रकार, खींचे गए स्प्राइट के ऊपरी बाएं कोने के वास्तविक समन्वय की गणना लगभग इस तरह की जाती है:

 left = sprite_layer_t.left - sprite_layer_t.sprite_hdr.dx top = sprite_layer_t.top - sprite_layer_t.sprite_hdr.dy 

अपने कोड में इसे लागू करते हुए, मुझे सही तस्वीर मिली, और उसके बाद मैंने मुख्य चरित्र को पुनर्जीवित करना शुरू कर दिया। वास्तव में, मैंने मूल पर वापस देखे बिना चरित्र के नियंत्रण (माउस और कीबोर्ड), अपने एनीमेशन और आंदोलन से संबंधित सभी कोड लिखे।

Moonwalk.GIF

पहले स्तर के लिए एक पाठ परिचय मिला। मुझे याद दिलाना है कि स्ट्रिंग संसाधन .BIH फ़ाइलों में संग्रहीत हैं। .BIH फाइलें वैरिएबल-साइज़ हैडर और नल-टर्मिनेटेड स्ट्रिंग्स के अनुक्रम से मिलकर बनती हैं। मूल कोड जो इंट्रो खेलता है, की जांच करने पर, मुझे पता चला कि .BIH फ़ाइल में पाठ भाग की शुरुआत की चौथी हेडर शब्द में समाहित है। पहली पंक्ति परिचय है:

 typedef struct bih_hdr_t { uint16_t unknown[3]; uint16_t text_offset; } bih_hdr_t; ... uint8_t r1_bih[12288]; assert(resource_manager_load("R1.BIH", r1_bih)); bih_hdr_t *hdr = (bih_hdr_t*)r1_bih; char *intro = r1_bih + hdr->text_offset; 

इसके अलावा, मूल पर भरोसा करते हुए, मैंने मूल स्ट्रिंग के विभाजन को सबस्ट्रिंग में लागू किया ताकि वे पाठ आउटपुट के लिए क्षेत्र में फिट हो, इन पंक्तियों के माध्यम से स्क्रॉल करें, और अगले बैच को जारी करने से पहले इनपुट की प्रतीक्षा करें।

Intro.GIF

प्रकाशन के समय, इसके अलावा जो पहले से ही तीन भागों में वर्णित है, मैंने ध्वनि के प्रजनन का पता लगाया। अभी तक यह केवल मेरे सिर में है और इसे मेरे प्रोजेक्ट में इसे साकार करने में कुछ समय लगेगा। तो चौथा भाग पूरी तरह से ध्वनि के बारे में होने की संभावना है। मैं इस परियोजना की वास्तुकला के बारे में थोड़ा बताने की योजना भी बना रहा हूं, लेकिन देखते हैं कि यह कैसा होता है।

न्यूरोमांसर का उलटा। भाग 4: ध्वनि, एनीमेशन, हफमैन, जीथूब