ReC98
versary Edition)
| ย้อนกลับวิศวกรรม: | |
|---|---|
| สรุป: | |
| ตำแหน่งอิสรภาพ: |
ตรวจสอบหน้าแรกสำหรับหมายเลขความคืบหน้าโดยละเอียดและข้อมูลเกี่ยวกับการระดมทุน!
โครงการนี้มีจุดมุ่งหมายเพื่อสร้างซอร์สโค้ดใหม่อย่างสมบูรณ์แบบของเกม Touhou Project ห้าเกมแรกโดย Zun Soft (ตอนนี้ ทีม Shanghai Alice ) ซึ่งเดิมเปิดตัวโดยเฉพาะสำหรับระบบ NEC PC-9801
เกมดั้งเดิมที่เป็นปัญหาคือ:
เนื่องจากเรามีเพียงไบนารีเราจึงไม่สามารถรู้ได้ว่า Zun ตั้งชื่อตัวแปรและฟังก์ชั่นใด ๆ อย่างไรและความคิดเห็นใดที่รหัสต้นฉบับถูกล้อมรอบด้วย ดังนั้นจึง สมบูรณ์แบบ หมายความว่าไบนารีที่รวบรวมจากรหัสในที่เก็บ Rec98 นั้นแยกไม่ออกจากการสร้างดั้งเดิมของ Zun ทำให้เป็นไปไม่ได้ที่จะ พิสูจน์หักล้าง ว่ารหัสดั้งเดิม ไม่สามารถ ดูได้เช่นนี้ สถานที่ให้บริการนี้ได้รับการบำรุงรักษาสำหรับทุก GIT ที่กระทำระหว่างทาง
นอกเหนือจากมุมการเก็บรักษาและความเข้าใจลึกซึ้งที่ลึกลงไปในกลไกของเกมแล้วรหัสสามารถทำหน้าที่เป็นรากฐานสำหรับ mod ทุกประเภทหรือพอร์ตใด ๆ ไปยังแพลตฟอร์มที่ไม่ใช่ PC-98 ที่พัฒนาโดยชุมชน นี่คือเหตุผลที่ rec98 ค่า ที่อ่านได้และเข้าใจได้ มากกว่าการสลายตัวที่บริสุทธิ์
มีหลายประการที่ทำให้การปรับเปลี่ยนได้ผ่านการสลายตัวเต็มรูปแบบดูเหมือนจะคุ้มค่ากว่าสำหรับเกม PC-98 ในทางตรงกันข้ามกับการปรับปรุงกล่องดำในสไตล์ Pytouhou:
นับตั้งแต่คราวด์ฟันดิ้งได้นำกระแสการสนับสนุนอย่างต่อเนื่องความคืบหน้าได้มั่นคง การสลายตัวของ Th01 เสร็จสมบูรณ์ในเดือนสิงหาคม 2565 และเกมที่เหลือเป็นเพียงเรื่องของเวลา
ในช่วงหลายปีที่ผ่านมาโครงการนี้นำไปสู่ความเข้าใจอย่างลึกซึ้งเกี่ยวกับคอมไพเลอร์ดั้งเดิมและฮาร์ดแวร์ PC-98 จนถึงจุดที่การสลายตัวของตัวเองกลายเป็นกลไกที่ค่อนข้างสวย เพื่อให้แน่ใจว่าโครงการนี้ยังคงคุ้มค่าที่จะสนับสนุนและน่าสนใจในการทำงานการมุ่งเน้นของมันได้เปลี่ยนไปสู่เอกสารที่พิถีพิถันมากขึ้นและการทบทวนรหัสดั้งเดิมของ Zun บล็อกของโครงการให้รายละเอียดการค้นพบทั้งหมดในวิธีที่อ่านได้โดยทั่วไปและกลายเป็นแหล่งท่องเที่ยวหลักโดยการสร้างซอร์สโค้ดการสร้างใหม่เกือบจะกลายเป็นผลพลอยได้จากการวิจัยเชิงลึกพื้นฐานในเกมเหล่านี้
โครงการเริ่มต้นใช้งานได้ดีเช่นกัน ในระหว่างการพัฒนาแพทช์ภาษาอังกฤษแบบคงที่สำหรับเกมเหล่านี้เราระบุห้องสมุดหลักสองห้องที่ใช้ในเกมทั้งหมด 5 เกมและพบซอร์สโค้ดของพวกเขา นี่คือ:
ZUNSP.COM ของ TH03 (เข้าถึงได้ผ่าน ZUN.COM -4 ) เป็นรุ่นใหม่ของ Promisence Soft's SPRITE16.COM ซึ่งเป็นไดรเวอร์การแสดงผล PC-98 EGC 16 สีรุ่น 0.04 ซึ่งรวมกับเกม พายุพายุ ตัวอย่าง master.lib และรันไทม์ C/C ++ เพียงอย่างเดียวสร้างจำนวนรหัสที่มีขนาดใหญ่มากในการดำเนินการทั้งหมด ตัวอย่างเช่นใน Th05 พวกเขามีจำนวนถึง 74% ของรหัสทั้งหมดใน OP.EXE และ 40% ของรหัสทั้งหมดใน MAIN.EXE นั่นเป็นรหัสที่ค่อนข้างมากที่เราไม่ต้องจัดการ การระบุส่วนที่เหลือของรหัสที่ใช้ร่วมกันในเกมจะช่วยลดปริมาณงานให้เป็นจำนวนที่ยอมรับได้มากขึ้น
ด้วย DOSBOX-X และฉบับดีบักของ NEKO Project II เรายังมีอีมูเลเตอร์โอเพนซอร์สสองตัวที่สามารถเรียกใช้เกมได้ สิ่งเหล่านี้ช่วยตอบคำถามที่เกี่ยวข้องกับฮาร์ดแวร์มากที่สุดพร้อมกับหนังสือเล่มเก่าเกี่ยวกับการพัฒนา PC-98 และการทดสอบเป็นครั้งคราวเกี่ยวกับฮาร์ดแวร์จริง
zunsoft.com , op.exe , reiiden.exe , fuuin.exeongchk.comzuninit.com , zun_res.com , zunsoft.comop.exe , main.exe , maine.exeongchk.comzuninit.comzunsoft.comzunsp.com [-4], res_yume.com [-5]), op.exe , main.exe , mainl.exeongchk.comzuninit.com [-i], res_huma.com [-s], memchk.com [-m]), op.exe , main.exe , maine.exeongchk.comzuninit.com [-i], res_kso.com [-s], gjinit.com [-g], memchk.com [-m]), op.exe , main.exe , maine.exeไฟล์ Crossed-Out เหมือนกับเวอร์ชันของพวกเขาในเกมก่อนหน้า Ongchk.com เป็นส่วนหนึ่งของไดรเวอร์ PMD Sound โดย Kaja และดังนั้นจึงไม่จำเป็นต้องถอดประกอบเช่นกัน เราเพียงแค่ต้องรักษาไบนารีเพื่ออนุญาตให้มีการสร้างบิตที่สมบูรณ์แบบของ zun.com
โครงการนี้ไม่รวมข้อมูลสินทรัพย์ใด ๆ จากรุ่น PC-98 ดั้งเดิม การเรียกใช้ Executables ที่รวบรวมจะยังคงต้องมีสำเนาที่มีอยู่ของเกมต้นฉบับ
▶ master : รหัสต้นฉบับของ Zun โดยไม่มี mods หรือ bugfixes (คุณอยู่ที่นี่!)
debloated : รหัสของ ZUN เวอร์ชัน REARCHITECTED ซึ่งง่ายต่อการอ่านและแก้ไขและสร้างไบนารี PC-98 ที่เล็กลงและเร็วขึ้น กำจัดเพียง bloat และทุ่นระเบิด; ข้อบกพร่องและนิสัยใจคอทั้งหมดจากรหัสต้นฉบับของ Zun นั้นถูกทิ้งไว้ในสถานที่ พอร์ตควรเริ่มต้นจากสาขานั้น และเป็นฐานที่แนะนำสำหรับ mods ที่ไม่สนใจความคล้ายคลึงกับไบนารีดั้งเดิม
anniversary : ใช้ debloated และแก้ไขข้อบกพร่องเพิ่มเติมได้รับประสบการณ์การเล่นเกมที่ราบรื่นและไม่สั่นไหวบนแพลตฟอร์ม PC-98 ในขณะที่ยังคงออกจากนิสัยใจคอ อาจเป็นพอร์ตเริ่มต้นที่ดียิ่งขึ้นสำหรับ mods และพอร์ต
BossRush
th03_no_gdc_frequency_check : อนุญาตให้ TH03 ทำงานด้วยนาฬิกา GDC ตั้งค่าเป็น 5 MHz เกมต้นฉบับบังคับใช้ 2.5 MHz แต่ไม่ต้องใช้งานได้แม้ในฮาร์ดแวร์จริง
xJeePx : การเปลี่ยนแปลงรหัสสำหรับแพทช์การแปลภาษาอังกฤษของ XJEEPX 2014
th01_critical_fixes : แก้ไขข้อบกพร่องสำคัญสองข้อใน Th01:
th01_end_pic_optimize : เพิ่มความเร็วในภาพ blitting ใน cutscenes ของ Th01 ถึง 50% ของรันไทม์ดั้งเดิม ส่วนใหญ่ทำหน้าที่เป็นตัวอย่างของวิธีการเข้าใกล้รหัส blitting EGC ที่ดีที่สุดจาก Turbo C ++ 4.0J โดยไม่ต้องเขียนคำสั่ง ASM เดียว EGC ไม่ใช่เครื่องมือที่ดีที่สุดสำหรับงานนี้อย่างแน่นอน
th01_orb_debug : แสดงข้อมูลต่อไปนี้ในโหมดการดีบักของ Th01:
th01_sariel_fixes : แก้ไขข้อบกพร่องสไปรต์สามตัวในการต่อสู้ Th01 Sariel ซึ่งเป็นผลมาจากข้อผิดพลาดที่ชัดเจนลอจิกในรหัสดั้งเดิม
th03_real_hitbox : แสดงผลบิตแมปการชนของ Th03 ลงบนสนามเด็กเล่นทั้งสอง เล่นไม่ได้สูง
แก้ไขสำหรับ Th04 Stage 5 Yuuka No-Ems Crash:
th04_noems_crash_fix : เพิ่มขีด จำกัด ของหน่วยความจำที่กำหนดด้วยตนเองของ MAIN.EXE ของ Th04 ด้วยจำนวนที่เหมาะสมในการแก้ไขปัญหานั้นmem_assign_all : ลบขีด จำกัด ของหน่วยความจำที่กำหนดด้วยตนเองในการดำเนินการ Th02-TH05 ทั้งหมดรวมถึงการแก้ไขปัญหาที่เกิดขึ้นนอกหน่วยความจำอื่น ๆ ที่อาจเกิดขึ้นในระหว่างการปรับเปลี่ยนวิธีแก้ปัญหาสำหรับข้อผิดพลาดของ Th04 Kurumi Divide Crash:
th04_0_ring_ignoreth04_0_ring_as_single_bulletth04_0_ring_as_cap_bulletsth04_0_ring_as_gameoverวิธีแก้ปัญหาสำหรับข้อผิดพลาดของ Th04 Stage 4 Marisa Divide Crash:
th04_marisa4_crash_stillth04_marisa4_crash_moveth04_marisa4_crash_warp community_choice_fixes : การรวมกันของข้อผิดพลาด "ชัดเจน" ทั้งหมดที่ไม่ส่งผลกระทบต่อการเล่นเกมหรือภาพ:
th01_critical_fixesth03_no_gdc_frequency_checkth04_noems_crash_fix รวมถึงวิธีแก้ปัญหาต่อไปนี้สำหรับข้อผิดพลาด Divide Error ของ Th04 ของ Th04 ที่เลือกโดย Community Vote:
th04_0_ring_as_single_bullet (ผลการสำรวจ)th04_marisa4_crash_still (ผลการสำรวจ) Borland Turbo C ++ 4.0J
นี่คือคอมไพเลอร์ ZUN ที่ใช้เดิมดังนั้นจึงเป็นสิ่งเดียวที่สามารถรวบรวมรหัสนี้ให้เข้ากับการเรียกใช้งานที่สมบูรณ์แบบบิตกับรหัสดั้งเดิมของ Zun บอร์แลนด์ไม่เคยสร้างตัวเปรียบเทียบข้ามเป้าหมาย DOS 16 บิตที่ทำงานบนหน้าต่าง 32 บิตดังนั้นชิ้นส่วน C ++ จะต้อง ถูกรวบรวมโดยใช้โปรแกรม DOS 16 บิต
Rec98 ยังใช้ Turbo C ++ 4.0J เพื่อสร้างเครื่องมือที่กำหนดเองในท่อสร้างเช่นตัวแปลงสำหรับสไปรต์ hardcoded สิ่งเหล่านี้ต้องใช้งานได้โดยเฉพาะเป็นส่วนหนึ่งของกระบวนการสร้างดังนั้นจึงอาจปรากฏตัวต่อต้านการผลิตเพื่อรวบรวมพวกเขาลงในโปรแกรม DOS 16 บิตซึ่งจำเป็นต้องได้รับการจำลองในระบบปฏิบัติการ 64 บิต สิ่งนี้ยังคงสมเหตุสมผลด้วยเหตุผลหลายประการ:
ดังนั้นจึงมีเหตุผลเล็กน้อยที่จะเพิ่มการพึ่งพาค่อนข้างหนักในคอมไพเลอร์ C ++ ดั้งเดิม
Borland Turbo Assembler (TASM), เวอร์ชัน 5.0 หรือใหม่กว่าสำหรับหน้าต่าง 32 บิต ( TASM32.EXE )
REC98 ไม่เพียง แต่ต้องใช้แอสเซมเบลอร์สำหรับรหัสเกมที่ยังไม่ได้สลายตัว แต่ยังสำหรับห้องสมุดบุคคลที่สามของ PC-98 Touhou และรหัสแอสเซมบลีที่เขียนด้วยมือและไม่สามารถควบคุมได้ของ Zun โชคดีที่แอสเซมเบลอร์ 32 บิตของบอร์แลนด์ สามารถ ใช้สำหรับรหัส 16 บิตและทำงานได้ทั้งบนหน้าต่างทั้ง 64 บิตและ 32 บิตซึ่งมีประสิทธิภาพสูงกว่าเครื่องมือ TASM.EXE และ TASMX.EXE 16 บิต
เพื่อประโยชน์ด้านข้างการใช้เครื่องมือ Windows 32 บิตดั้งเดิมยังช่วยให้ชิ้นส่วน ASM ใช้ชื่อไฟล์ยาวที่ไม่จำเป็นต้องสอดคล้องกับอนุสัญญา DOS 8.3
ผู้เล่น MS-DOS (รวม)
ตัวจำลองที่มีน้ำหนักเบาสำหรับเรียกใช้เครื่องมือบรรทัดคำสั่ง DOS บนระบบย่อย Windows Console ใช้โดยอัตโนมัติเมื่อสร้าง codebase บนระบบปฏิบัติการ 64 บิต แม้จะมีธรรมชาติที่ถูกถอดออก แต่ก็ยังทำงานช้ากว่า Dosbox อย่างเห็นได้ชัดเนื่องจากใช้ Neko Project 21/W การตีความ X86 Core แทนที่จะเป็นนักรีดคอมไพล์แบบไดนามิก แต่การรวมคอนโซลที่ไร้รอยต่อ
การสร้างแบบรวมนั้นได้รับการปรับโปรไฟล์โดยเฉพาะสำหรับการสร้าง Rec98 โดยใช้แกน x86 ที่ลดลงซึ่งจะเลียนแบบ 386 โดยไม่มี FPU, เพจหรือการนับรอบ เมื่อเปรียบเทียบกับการสร้างต้นน้ำของ Takeda Toshiya การสร้างนี้จะเพิ่มความเร็วในกระบวนการสร้าง REC98 โดย≈60% สำหรับการสร้างใหม่ที่สมบูรณ์≈80% สำหรับการรวบรวมและเชื่อมโยงหน่วยการแปลที่ใหญ่ที่สุดและไบนารีที่ใหญ่ที่สุดและ≈70% สำหรับหน่วยแปลขนาดเฉลี่ยและไบนารี นอกจากนี้ยังมีข้อผิดพลาดที่จำเป็นสำหรับการเรียกใช้ Turbo C ++ 4.0J ในบริบทของระบบบิลด์ที่ไม่ได้มีอยู่ในการสร้างต้นน้ำ ณ เดือนมิถุนายน 2567
ดู bin/README.md สำหรับใบอนุญาตและสร้างข้อมูล
TUP สำหรับ Windows (รวม)
ระบบสร้างที่มีสติและขนานใช้เพื่อให้แน่ใจว่ามีการสร้างใหม่น้อยที่สุด ให้การติดตามการพึ่งพาที่สมบูรณ์แบบผ่านการฉีดรหัสและเชื่อมต่อไฟล์การเปิดไฟล์ของคอมไพเลอร์ทำให้สามารถเพิ่มไฟล์ #include d ทั้งหมดลงในกราฟการพึ่งพาการสร้างโดยอัตโนมัติ สิ่งนี้ทำให้มันเหนือกว่าการ make งานส่วนใหญ่ซึ่งขาดคุณสมบัติที่สำคัญนี้และดังนั้นจึงไม่เหมาะสมสำหรับภาษาการเขียนโปรแกรมใด ๆ ที่จินตนาการได้ ด้วยสิ่งที่เป็นนามธรรมสำหรับคอมไพเลอร์เฉพาะ TUP ก็เข้ากันได้อย่างสมบูรณ์แบบกับเครื่องมือ Borland โบราณที่จำเป็นสำหรับโครงการนี้
Build Windows 64 บิตที่รวมอยู่นั้นรวมถึงการแก้ไขข้อผิดพลาดที่สำคัญสำหรับการเรียกใช้เครื่องมือสร้างที่ใช้ DOS ผ่านเครื่องเล่น MS-DOS ที่ไม่ได้รวมเข้ากับที่เก็บต้นน้ำ ณ เดือนมิถุนายน 2567
ดู bin/README.md สำหรับใบอนุญาตและสร้างข้อมูล
เพียงเรียกใช้ build.bat บนแพลตฟอร์มการสร้างที่รองรับใด ๆ มันทำสิ่งที่ถูกต้องโดยไม่คำนึงถึงระบบปฏิบัติการที่คุณกำลังทำงานอยู่ กระบวนการจะยกเลิกด้วยข้อผิดพลาดหากไม่พบเครื่องมือที่จำเป็นใด ๆ ใน PATH Windows
ปฏิบัติการสุดท้ายจะถูกใส่ลงใน binth0? ใช้ชื่อเดียวกับต้นฉบับ การเรียกใช้พวกเขาต้องการสินทรัพย์ดั้งเดิมของแต่ละเกมในไดเรกทอรีเดียวกัน
ใน 64 บิต x86 กระบวนการสร้างใช้ TUP สำหรับการสร้างแบบขนานที่น้อยที่สุด แต่เครื่องมือบิลด์ที่ใช้ DOS ทั้งหมดได้รับการจำลอง ในวันที่ 32 บิต x86 กระบวนการสร้างจะกลับมาอยู่ในไฟล์แบตช์ตามลำดับที่สร้าง codebase ทั้งหมดเสมอ แต่เครื่องมือสร้างทั้งหมดจะทำงานที่ประสิทธิภาพดั้งเดิม
ระดับ 1 : การทดสอบการสนับสนุนที่ดีที่สุดรับประกันอย่างสม่ำเสมอ
ระดับ 2 : ควรจะทำงานเป็นไปได้ที่จะสนับสนุน แต่ไม่ได้ทดสอบเป็นประจำ ข้อบกพร่องที่สำคัญในกระบวนการสร้างจะได้รับการแก้ไขฟรี
เทียร์ 3 : ควรจะทำงาน แต่เป็นภาระในการรักษา การแก้ไขข้อบกพร่องที่เกี่ยวข้องกับการสร้างจะต้องใช้เงินทุน แต่ Bugfix PRS ก็มีแนวโน้มที่จะได้รับการยอมรับเช่นกัน
เทียร์ 4 : ไม่ได้รับการสนับสนุนอย่างชัดเจนและไม่สามารถทำได้โดยไม่ต้องซ่อมแซมอย่างจริงจัง จะต้องใช้เงินทุนเฉพาะหรือส้อม PRS ไม่น่าจะได้รับการยอมรับ
tlink ล้มเหลวด้วย Loader error (0000): Unrecognized Error บน windows 32 บิต≥Vista
สองสาเหตุที่รู้จัก:
ลองกำหนดค่าไดรเวอร์ NTVDM DPMI ที่จะโหลดลงในหน่วยความจำทั่วไปมากกว่าหน่วยความจำบนโดยการแก้ไข %WINDIR%System32autoexec.nt :
REM Install DPMI support
- LH %SystemRoot%system32dosx
+ %SystemRoot%system32dosxต้องมีการรีบูตหลังจากแก้ไขเพื่อให้มีผล
(แหล่งที่มา)
ลองสร้างในเปลือก cmd.exe ปกติแทน PowerShell หรือ Bash
ดู CONTRIBUTING.md .
