เกม Nintendo 64 เกือบทั้งหมดสามารถรีคอมไพล์เป็นพอร์ต PC แบบเนทีฟได้
(tomshardware.com)- เกม Nintendo 64 ที่วางจำหน่ายในปี 1996 สามารถรีคอมไพล์เป็นพอร์ต PC แบบเนทีฟแทนการอีมูเลชันได้แล้ว ทำให้เพิ่มการปรับปรุงอย่างเรย์เทรซซิง, อัลตร้าไวด์ และ FPS สูงได้
- เครื่องมือหลักคือ N64Recomp และ Zelda64Recomp ที่ Mr-Wiseguy เผยแพร่บน GitHub โดย Zelda64Recomp ใช้พอร์ต The Legend of Zelda: Majora's Mask มาลง PC
- วิธีนี้ต่างจาก Super Mario 64 PC port แบบถอดประกอบโค้ดทั้งหมดที่เผยแพร่ในปี 2020 แต่ทั้งสองแบบต่างก็รันแบบเนทีฟบน PC ได้ จึงเพิ่มประสิทธิภาพและความแม่นยำของเอฟเฟกต์ได้
- ขณะที่การถอดประกอบโค้ดด้วยมือต้องใช้เวลาหลายปีและคนทำอย่างน้อยหนึ่งคน N64Recomp เป็นแนวทางที่เปลี่ยนเกม N64 ให้กลายเป็นรูปแบบที่รันบน PC ได้เร็วกว่า
- ผลลัพธ์ไม่ได้รวมแอสเซ็ตไว้ จึงยังต้องใช้ ROM เพื่อเล่น และมีการยกตัวอย่างการรันของ Banjo-Kazooie, Rocket Robot และ Superman 64
การเปลี่ยนแปลงของวิธีพอร์ตเกม N64
- แม้ในปี 2024 ฮาร์ดแวร์ต้นฉบับและเกมของ Nintendo 64 ก็ยังได้รับความสนใจอย่างต่อเนื่องจากชุมชนผู้ชื่นชอบ
- มีความเป็นไปได้มากขึ้นว่าก้าวถัดไปของการเล่น N64 ขั้นสูงจะไม่ใช่อีมูเลชัน แต่เป็น พอร์ต PC แบบรีคอมไพล์
- Mr-Wiseguy ได้เผยแพร่ N64Recomp และ Zelda64Recomp บน GitHub
- N64Recomp เป็นเครื่องมือพื้นฐานสำหรับสร้างเกม N64 ให้เป็นพอร์ต PC แบบเนทีฟ
- Zelda64Recomp พอร์ต The Legend of Zelda: Majora's Mask มาลง PC และนำการปรับปรุงด้านกราฟิกกับความสะดวกในการใช้งานของ N64Recomp มาใช้
การปรับปรุงที่ทำได้บนพอร์ต PC
- พอร์ต PC แบบรีคอมไพล์สามารถเพิ่มการปรับปรุงสำหรับสภาพแวดล้อม PC ให้กับเกม N64 ต้นฉบับได้
-
เรย์เทรซซิงจริง
- ปลดล็อกข้อจำกัดของเฟรมเรต
- รองรับอัลตร้าไวด์ได้อย่างเหมาะสม
- การปรับปรุงด้านกราฟิกและความสะดวกในการใช้งานตามที่คาดหวังบน PC
- Majora's Mask ถูกใช้เป็นกรณีเปรียบเทียบการรันแบบอัลตร้าไวด์ระหว่างวิธีอีมูเลชันกับการรีคอมไพล์แบบเนทีฟบน PC
-
ความแตกต่างจาก Super Mario 64 PC port
- Super Mario 64 PC port แบบถอดประกอบโค้ดทั้งหมดที่เผยแพร่ในปี 2020 เปิดทางให้มีฟีเจอร์อย่างเรย์เทรซซิงและการเปลี่ยนโมเดลทั้งหมด และจนถึงตอนนี้ก็ยังมีม็อดออกมาอย่างต่อเนื่อง
- พอร์ตแบบรีคอมไพล์มีวิธีการสร้างต่างจากพอร์ตแบบถอดประกอบโค้ดอย่าง SM64 PC port
- ทั้งสองวิธีต่างก็รันแบบเนทีฟบน PC และสามารถเพิ่มประสิทธิภาพกับความแม่นยำของเอฟเฟกต์เมื่อเทียบกับฮาร์ดแวร์ต้นฉบับ พร้อมทั้งมอบการปรับปรุงสไตล์ PC ที่คาดหวังจากอีมูเลชันได้
เหตุผลที่ N64Recomp สำคัญ
- N64Recomp เป็นเครื่องมือที่ใช้แนวทางรีคอมไพล์เพื่อดึง ข้อดีของอีมูเลชันและพอร์ตแบบเนทีฟ มารวมกัน
- การถอดประกอบโค้ดเกม N64 ด้วยมือต้องใช้เวลาหลายปีและอย่างน้อยต้องมีคนทำหนึ่งคนขึ้นไป
- เครื่องมือที่เปลี่ยนเกม N64 ให้กลายเป็นสภาพที่รันบน PC ได้รวดเร็วขึ้นอย่างมีประสิทธิภาพ อาจมีประโยชน์ต่อผู้ทำงานด้านการอนุรักษ์ด้วย
RT64 และตัวอย่างการรัน
- Dario เป็นนักพัฒนาที่สร้าง RT64 plugin ซึ่งถูกใช้กับ N64Recomp และอีมูเลเตอร์ N64 บางตัว
- ตามโพสต์ของ Dario ระบุว่า Wiseguy ได้พัฒนาเครื่องมือสำหรับสร้างพอร์ต PC ของเกม N64 โดยไม่ต้องถอดประกอบโค้ดทั้งหมดแบบปิดเงียบมาเป็นเวลา 1 ปี
- ผลลัพธ์ไม่ได้รวมแอสเซ็ตไว้ และต้องใช้เพียง ROM เพื่อเล่น
- เกมที่ถูกยกมาเป็นตัวอย่างการรันมีดังนี้
- Banjo-Kazooie
- Rocket Robot
- Superman 64
ความเคลื่อนไหวอื่นในระบบนิเวศ N64
- ยังมีความก้าวหน้าอื่น ๆ สำหรับแฟนของไลบรารี N64 และฮาร์ดแวร์ต้นฉบับอย่างต่อเนื่อง
- SummerCart64 แบบโอเพนซอร์สคือแฟลชคาร์ตสำหรับคอนโซลเดิม และยังรองรับ 64DD ได้ด้วย
- เกมโฮมบรู N64 และ ROM hack ที่เข้ากันได้กับฮาร์ดแวร์จริงก็ยังถูกปล่อยออกมาอย่างต่อเนื่อง
- Smash Remix ที่มีตัวละครต่อสู้ 30 ตัว
- Peach's Fury โครงการเขียนเอนจิน Mario 64 ใหม่
2 ความคิดเห็น
ความคิดเห็นจาก Hacker News
หากจะใช้เครื่องมือนี้ ยังต้อง ถอดแอสเซมบลี ROM ก่อน แล้วใส่คอมเมนต์จำนวนมากเพื่อให้คอมไพล์ใหม่ได้
ตัวเครื่องมือเองยอดเยี่ยม แต่การโฆษณาว่ามันแทบจะแปลง ROM ใด ๆ ให้เป็นไฟล์ executable แบบสแตนด์อโลนได้ในคลิกเดียวดูจะเกินจริงไปหน่อย
ในวิดีโอของโพสต์ เขาคอมไพล์เกม N64 ที่ไม่ได้ระบุชื่อขึ้นมาใหม่และรันได้ดี โดยดูเหมือนไม่ต้องมีคอมเมนต์พิเศษอะไรด้วย
ROM คือหน่วยความจำอ่านอย่างเดียวตามชื่อ ดังนั้นจึงเป็นไปได้ที่จะใส่ ROM เข้าไปแล้วได้ พอร์ตเนทีฟ ออกมา
การแปลงไบนารีเป็นไบนารี น่าจะตรงไปตรงมากว่า และดูเหมือนไม่ต้องอาศัยอินพุตจากมนุษย์ด้วย
เจ๋งมากจริง ๆ
เครื่องมือพื้นฐานหลายตัวที่สร้างขึ้นมาเพื่อ decompile N64 กำลังแพร่ไปสู่แพ็กเกจ decompile ของระบบอื่น ๆ
https://decomp.me/ ที่เพิ่งเห็นไม่นานมานี้รองรับ การ decompile แบบร่วมมือกัน สำหรับหลายระบบ พร้อม SDK ที่เกี่ยวข้องและพรีเซ็ตฮาร์ดแวร์
คิดว่าในอีกไม่กี่ปีข้างหน้าจะเห็นกระแสแบบนี้เกิดขึ้นกับระบบต่าง ๆ มากขึ้น
ตอนที่สิ่งนี้ออกมา ผมก็เห็นแล้ว แต่ในฐานะคนที่ไม่ได้ตามสาย ROM hacking ก็สงสัยว่าทำไมแนวทางแบบนี้ถึงเพิ่งออกมาช้าขนาดนี้
การแปลคำสั่งแอสเซมบลีเป็น C แล้วคอมไพล์ใหม่ดูเหมือนเป็นวิธีที่ชัดเจนซึ่งน่าลองตั้งแต่แรก ๆ เลย จึงสงสัยว่าเมื่อก่อนมันเป็นไปไม่ได้หรือมี breakthrough อะไรที่ทำให้ตอนนี้ทำได้
ลองไล่ดู GitHub repository แล้ว ดูเหมือนว่าภายในจะใช้ rt64 เพื่อรองรับ ray tracing (https://github.com/rt64/rt64)
rt64 ใช้เทคนิค ubershader เพื่อจำลอง GPU และบทความยอดเยี่ยมนี้อธิบายว่า ubershader คืออะไร ทำไมถึงจำเป็น และมันชวนปวดหัวแค่ไหน: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
การรีคอมไพล์แบบสแตติก จากภาษาเครื่องหนึ่งไปเป็นอีกภาษาหนึ่งอยู่ในขอบเขตระหว่าง “ยากมากในงานจริง” กับ “โดยทั่วไปเป็นไปไม่ได้” [1]
หากจะทำรีคอมไพล์แบบนี้ให้ถูกต้อง ก็ต้องมีความช่วยเหลือจากฝั่งไบนารีที่ทำให้รีคอมไพล์ง่ายขึ้นด้วย [2] และยังต้องมีแพตช์เพื่อให้มันทำงานได้อีก [3]
การรีคอมไพล์แบบไดนามิกไม่มีปัญหาเหล่านี้ ดังนั้นเมื่อใส่ไบนารีต้นฉบับและแอสเซต หรือก็คือ ROM เข้าไป โดยทั่วไปก็จะสร้างซอฟต์แวร์ที่ถูกอีมูเลตได้
มีความสับสนมากว่าแนวทางนี้ใช้ได้ทั่วไปแค่ไหน
ในแง่การลดปริมาณงานที่ทำให้การรีคอมไพล์หรือการพอร์ตง่ายขึ้นมาก มันน่าประทับใจและมีคุณค่ามาก แต่ยังไม่สามารถแทนที่ความจำเป็นของอีมูเลเตอร์แบบดั้งเดิมได้
[1]: https://cs.stackexchange.com/questions/155511/why-is-static-...
[2]: ไบนารีเกม N64 อาจช่วยแนวทางนี้ได้ เพราะบังเอิญหลีกเลี่ยงปัจจัยหลายอย่างที่ทำให้การรีคอมไพล์แบบสแตติกทั่วไปทำได้ยาก แต่จริง ๆ แล้วก็ไม่แน่ใจ
[3]: repository สำหรับรีคอมไพล์ Majora's Mask มีแพตช์ที่ทำด้วยมือจำนวนมากเพื่อให้ทำงานได้: https://github.com/Mr-Wiseguy/Zelda64Recomp
Jamulator เคยทำสิ่งนี้กับ NES ตั้งแต่ปี 2013 แล้ว แต่ดูเหมือนไม่ค่อยมีใครสนใจเท่าไร
https://andrewkelley.me/post/jamulator.html
ยังมี Winlator ที่ใช้รันโปรแกรม Windows บน Android ด้วย
https://github.com/brunodev85/winlator
แล้ววิดีโอ YouTube ที่ลิงก์ไว้ในบทความใช้ เสียง AI หรือเปล่า?
ในรีโพสิทอรี GitHub ของ N64Recomp[0] เขียนไว้แบบนี้:
"This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
[0]: https://github.com/Mr-Wiseguy/N64Recomp
ในสถานการณ์แบบนั้น การรีคอมไพล์มีแต่ทำให้เรื่องซับซ้อนขึ้น และไม่ได้ให้ประโยชน์มากนัก
N64 เป็นฮาร์ดแวร์แบบตายตัว เลยง่ายกว่านิดหน่อย
ถึงอย่างนั้นโปรเจกต์นี้ก็ยังใช้การอีมูเลตกับ RDP อยู่
ไม่รู้ว่าเขาจัดการกับไมโครโค้ด RSP ที่สร้างขึ้นอย่างไร และอาจจะไม่ได้จัดการเลยก็ได้
เกมจำนวนมากก็แค่ใช้ไลบรารีทางการ
ถ้า Jamulator ออกมาพร้อมฟีเจอร์ปรับปรุงคล้าย ๆ กันสำหรับ Zelda ก็คงได้รับความนิยมมากกว่านี้มาก
ดูเหมือนว่าความสนใจตอนนี้มาจากว่าเราทำอะไรกับมันได้มากกว่าวิธีการเอง
เสียงบรรยายในวิดีโอเป็นคนจริง ๆ ชื่อ Nerrel เท่านั้น
น่าทึ่งในแง่ที่น่าสนใจว่าเสียง AI สมัยนี้ดีขึ้นมาก จนเรากลับสงสัยว่าคนที่ไม่ได้พูดในแบบที่เราคาดหวังเป็น AI
น้ำเสียงบรรยายราบเรียบมากจนฟังดูเหมือน AI มาตั้งนานแล้ว และผมชอบความรู้สึกที่มันผสมกับอารมณ์ขัน
คงดีถ้าไฟล์ปฏิบัติการของเกมทุกเกมเป็นอิสระจากระบบปฏิบัติการ คล้ายกับ WebAssembly
เช่น GameAssembly อะไรทำนองนั้น
ตอนนี้ macOS รุ่นใหม่เล่นเกม 32 บิตไม่ได้แล้ว และ Wine ก็รันเกม Windows 32 บิตไม่ได้ด้วย
แทบเป็นไปไม่ได้เลยที่จะหาไฟล์
.exe64 บิตที่รันได้ดีใน Wine/Crossoverสำหรับคอนโซล โดยเฉพาะเกมเก่าและเกมเอ็กซ์คลูซีฟของแพลตฟอร์ม มักพึ่งพา รายละเอียดการใช้งาน GPU ระดับต่ำมาก
คอนโซลที่เก่ากว่านั้นยังมีชิปเฉพาะทางที่ทำงานสำคัญนอกเหนือจาก I/O ธรรมดาอีกด้วย
ตัวอย่างเช่น ชิปเสียงของ SNES เป็น CPU อิสระอย่างสมบูรณ์ที่รันโปรแกรมเล็ก ๆ ของตัวเองขนานไปกับ CPU และ GPU
แน่นอนว่าเราอาจบังคับให้การพัฒนาเกมทั้งหมดในอนาคตใช้ virtual machine ระดับสูงได้ แต่เมื่อคิดถึงข้อเท็จจริงว่าสเปกฮาร์ดแวร์คอนโซลถูกกำหนดตายตัวแล้ว มันคงไม่มีความสามารถแข่งขันสำหรับเกมที่ต้องการใช้กราฟิกสมัยใหม่
บน Debian ต้องรันคำสั่งนี้
dpkg --add-architecture i386 && apt-get updateจากนั้นก็ติดตั้งแพ็กเกจ
wine32เกมต้องใช้ API หลายอย่าง เช่น graphics API, window API, input API, sound API, disk API ฯลฯ
บางครั้งยังต้องใช้ kernel module เพราะระบบป้องกันโกงหรือป้องกันการคัดลอกด้วย
สิ่งที่น่าเสียดายคือระบบปฏิบัติการโอเพนซอร์สไม่ได้พยายามจัดชุด API กลางที่ทำให้นักพัฒนาเขียนและทดสอบโค้ดครั้งเดียวแล้วทำงานได้ทุกที่
มี Flatpak อยู่ก็จริง แต่เท่าที่ผมเข้าใจ มันใกล้เคียงกับการห่อ Linux distribution ไว้ใน virtual machine โดยไม่มีสเปกหรือเอกสาร มากกว่าจะเป็นการจัดชุด API
มันดูเทอะทะ และไม่เข้ากันได้กับระบบปฏิบัติการขนาดเล็กที่ไม่ใช่ Linux ด้วย
ผมรัน GTA IV บน M1 mini
ดูเหมือนว่าใน Wine เวอร์ชัน 32 บิตที่ PlayOnMac ติดตั้งจะมีการอีมูเลตแบบ "32 on 64" อยู่บางอย่าง แต่ค้นหายากมากจนไม่รู้ว่าจริง ๆ แล้วมันทำงานอย่างไร
น่าสนุกดีที่ Mac เข้ากันได้กับโปรแกรม Windows เก่า ๆ มากกว่าโปรแกรม Mac เก่า ๆ เสียอีก
ถ้าไม่มี JVM ก็สงสัยว่า Minecraft จะรองรับ Linux หรือกลุ่ม BSD หรืออะไรทำนองนั้นหรือไม่
Bedrock Edition ที่ไม่ใช่เวอร์ชัน JVM รองรับ Windows, คอนโซล และโทรศัพท์มือถือ แต่กลับไม่รองรับ macOS ทั้งที่น่าจะทำได้แน่ ๆ
หวังว่าสุดท้ายแล้วสิ่งนี้จะทำงานบน Linux ได้ด้วย เพื่อให้เล่นเกม N64 ได้อย่างเสถียรบนอุปกรณ์พกพาสเปกต่ำมาก
N64 ขึ้นชื่อว่าอีมูเลตได้ยาก แต่ถ้าทำเป็น เนทีฟบิลด์ สำหรับแพลตฟอร์ม ปัญหาด้านประสิทธิภาพก็จะหายไป
ดูตัวอย่างได้ที่นี่: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
ผมไม่รู้รายละเอียดของการอีมูเลต N64 มากนัก แต่ตั้งแต่ช่วงต้นทศวรรษ 2010 ก็รันอีมูเลเตอร์ N64 ได้สมบูรณ์มาตลอด
ส่วนใหญ่เล่นแต่เกมคลาสสิกดัง ๆ เลยไม่ค่อยรู้ว่าเกมเฉพาะกลุ่มกว่านั้นมีประสิทธิภาพเป็นอย่างไร
เล่นไปประมาณหนึ่งชั่วโมงก็ไม่มีปัญหา
ผมทดสอบเองแล้ว
สิ่งนี้น่าจะมีประโยชน์มากกับเกมอย่าง GoldenEye
เกมนี้เล่นบนพีซียากเพราะตั้งสมมติฐานกับอินพุตจอยสติ๊กแปลก ๆ ไว้ แต่ถ้ามี พอร์ต GoldenEye แบบเนทีฟ ที่มีการทำงานของเมาส์ปกติเหมือน FPS อื่น ๆ ก็น่าจะเยี่ยม
วิธี สลับโหมด ในการเล็ง และเวลาที่เคอร์เซอร์เคลื่อนที่แล้วกลับเข้ากลาง เป็นส่วนหนึ่งที่ทำให้เกมสนุก
ถ้าสามารถเล็งอิสระระหว่างวิ่งได้แบบ FPS บนพีซี แคมเปญน่าจะพังเสียมากกว่า เพราะมันถูกออกแบบบนสมมติฐานเดิม
เสน่ห์คือการเลือกว่าจะหยุดตรงไหนเพื่อเล็ง และรักษาความนิ่งขณะกำลังเล็ง
แต่ถ้ายังคงการสลับโหมดไว้ และให้เมาส์ 1) หมุน Bond เหมือนแกนซ้าย-ขวาของสติ๊ก และ 2) ควบคุมเคอร์เซอร์เฉพาะตอนกด R เข้า “โหมดเล็ง” ก็อาจสนุกได้
พูดตรง ๆ เสียดายที่เกมยิงทั้งหมดมุ่งตรงไปสู่การเล็งอิสระแบบ Quake ด้วย WASD+เมาส์
วิธีสลับโหมดให้สัมผัสทางกายภาพแบบที่ผมชอบใน GoldenEye
https://github.com/Graslu/1964GEPD/releases/tag/latest
ใช้กับ Perfect Dark ได้ด้วย
น่าสนใจทีเดียว แต่สงสัยว่าสิ่งนี้จะนำไปสู่เวอร์ชัน Conker ที่ทำงานบน MiSTer ได้อย่างถูกต้องหรือไม่
เช่น ใช้สิ่งนี้ช่วยในการดีคอมไพล์ แล้วให้ใครสักคนทำเวอร์ชันแก้ไขได้ไหม?
สงสัยว่าข้อดีเมื่อเทียบกับอีมูเลเตอร์คืออะไร
สุดท้ายแล้วมันไม่ใช่อีมูเลเตอร์แบบแปลล่วงหน้าหรือ?
วิธีแบบนี้เคยมีมาก่อนอย่าง Bleem และอาจได้เปรียบด้านประสิทธิภาพ แต่บนพีซีสมัยใหม่ ถ้าเป็นอีมูเลเตอร์ดี ๆ โดยทั่วไปก็ทำงานได้ดี
https://en.wikipedia.org/wiki/Bleem!
เป้าหมายของอีมูเลเตอร์ N64 โดยปกติคือการจำลองพฤติกรรมของคอนโซลดั้งเดิมให้ถูกต้อง
ในทางกลับกัน มีคนจำนวนมากที่อยากเล่น SM64, OOT, MM พร้อม การปรับปรุงกราฟิก หลายอย่าง เช่น 60fps, ไวด์สกรีน, texture pack, randomizer
สำหรับคนเหล่านี้ ความจริงที่ว่าเกมเหล่านี้เคยรันบน N64 ดั้งเดิมแทบจะไม่สำคัญ
กลับเป็นเหมือนอุปสรรคมากกว่า
กราฟิกไปป์ไลน์ของ N64 นั้นอีมูเลตยุ่งยาก และขัดขวางการปรับปรุงแบบสมัยใหม่อย่างมาก
โปรเจกต์นี้ดูเหมือนจะเน้นการจัดการตัวเกมเองให้ทันสมัย และตัดองค์ประกอบที่ยึดกับ N64 ออกจากสมการไปโดยสิ้นเชิงมากกว่า
ตอนนี้คอมพิวเตอร์เร็วกว่า N64 มากแล้ว ความต่างอาจไม่สังเกตเห็นก็ได้
อีมูเลเตอร์ทั่วไปคอมไพล์ล่วงหน้าหรือใช้ JIT กัน?
ถ้าไม่ใช่ ก็สงสัยว่าทำไมไม่ทำ
แนวทางนี้ คือการคอมไพล์ล่วงหน้า ดูเหมือนมีข้อดีมาก
แต่ถ้า TeknoParrot ไม่ได้ทำงานแบบนั้น ผมก็ไม่ค่อยรู้เรื่อง การแปลล่วงหน้า
เช่น สามารถใช้ TeknoParrot รันเกมอาร์เคด Linux ที่ใช้ไบนารี ELF บน Windows ได้ แต่เพราะสถาปัตยกรรมเดียวกัน ผมคงไม่เรียกทั้งสองกรณีว่าเป็นการอีมูเลต
การรันแบบตีความคือการเขียน เครื่องเสมือน ที่แสดงสถานะของส่วนต่าง ๆ ของเครื่อง แล้วรันคำสั่งที่เปลี่ยนสถานะนั้นด้วยระดับความถูกต้องที่ต่างกัน
พลังของเหล่าเนิร์ดนี่มันสุดจริง! จากการใส่ JIT compiler ให้กับอีมูเลเตอร์ ตอนนี้ไปไกลถึงขั้นแปลงด้วย binary lifting เป็น C แล้วคอมไพล์ใหม่ได้เลย