Nostr notes by Matthew Stanley (Unofficial)

Decomps & Recomps in 2026 There are a lot of misconceptions ...

2026-10-26T03:19:28Z

Decomps & Recomps in 2026

There are a lot of misconceptions about decompilation and recompilation in the retro game scene. Some believe decompilations are inherently more accurate, easier to modify, or better for game preservation. Others dismiss recompilations as little more than emulators.
I've spent years reverse engineering games, and more recently I've been developing recompilation tools and helping others use them. I think much of this discussion misses the point.
Neither approach guarantees accuracy, modding potential, or preservation. What matters is how developers use these tools.
What are decompilation and recompilation?
A decompilation attempts to recover source code from a game's machine instructions. A static recompilation translates those instructions into code that can be compiled for another system.
Importantly, neither one is automatically a PC port. They're methods of working with a game's code. Turning that code into a playable PC game requires additional work.
Let's imagine we recovered a function that controls Mario's jump.
A basic decompilation, perhaps generated by an AI-assisted tool, might look like this:
void func_1234() {
x = -y;
}
We can see what the code does, but the names tell us nothing about its purpose. Today, automated tools and AI can help produce this kind of first-pass result. Historically, developers had to do much more of this recovery work themselves through effectively brute forcing.
After studying the game, someone might give the function and its variables meaningful names:
void MarioJump() {
marioVerticalSpeed = -jumpStrength;
}
Now we can immediately understand what this function controls. This is an annotated decompilation, where someone has identified and documented what the game's code does.
Both examples can compile into the exact same machine-code bytes. Variable and function names exist to help humans understand the code. Changing those names doesn't change the machine instructions produced by the compiler.
A static recompilation might instead produce something like this:
void translated_1234() {
ram[0x20] = -ram[0x24];
}
These are simplified examples of the same basic operation. The recompilation doesn't need to understand what a jump is. It only needs to reproduce what the original instructions do.
A well-annotated decompilation is easier for a human to navigate. But both unannotated decompilations and recompilations lack that helpful documentation. We can also use knowledge from a decompilation to annotate a recompilation, combining the advantages of both.
Why I use "recompilation" as a catch-all term
There's a technical detail worth explaining. Many games on older systems like the NES, SNES, Genesis, and Game Boy were written in assembly language. Their code was assembled into machine instructions, rather than compiled from a language like C.
Strictly speaking, translating those games into C and compiling them for a modern computer isn't technically recompilation in the literal sense.
So what should we call it? Disassembly-based translation followed by native compilation? Assembled-then-compiled? Neither exactly rolls off the tongue.
I chose recompilation as a public-facing term because it communicates the idea without requiring people to understand the entire process. More precisely, my tools perform ahead-of-time static binary translation and provide outcomes similar to what people expect of recompilation ports today. The terminology is useful, but understanding what the tools accomplish matters far more.
A decompilation is not automatically more accurate
A matching decompilation can reproduce the original game's machine code exactly. That's an impressive achievement, but it doesn't guarantee that a PC port built from it will behave correctly.
Old games relied on very specific hardware. When developers move that code to modern computers, they still need to reproduce or replace things like graphics, sound, timing, and memory behavior.
A decompilation-based port can introduce bugs, break physics, or lose behaviors from the original game. A recompilation-based port can make those same mistakes.
A poorly implemented decompilation port can be less accurate than a well-implemented recompilation port. Neither approach automatically makes a good port.
Mega Man X's Magic Carpet
One example comes from my work with Mega Man X using snesrecomp.
The game contains a trick known as the Magic Carpet bug, used by speedrunners. I was able to reproduce this behavior in the recompiled game while running in its original 4:3 aspect ratio. The fact it was able to reproduce despite its port is a statement of faithfulness to the original game.
The game has seen extensive modifications since. Anything from X2 and X3 weapons, to Zero from X3 being backported, to Zero being given custom saber animations -- all the way up to widescreen.
Of all the things, it was widescreen that actually broke the magic carpet. The wider viewport changed what was in memory. It would have broken on real hardware too, if it could manage the wider screen.
But even still, given that I had a faithful foundation, I was able to restore it through a few quick tricks. Now the magic carpet bug can be done in widescreen just the same, preserving a sense of authenticity to the original game while also offering modernizations.
0:00
/0:27
1×
The Magic Carpet bug in Storm Eagle's stage, performed in widescreen.
This is why I prioritize accuracy in my recompilers. Once the original game works correctly, we can begin changing it while testing what those changes affect.
Recompilations aren't inherently less modifiable
A well-annotated decompilation is generally easier for a human to navigate. But that's largely because someone has already identified and explained the code.
That distinction is becoming increasingly important with AI.
Consider how someone discovers cheats using a tool like Cheat Engine. They might search for a health value in memory, take damage, search again, and repeat until they've identified the correct value. This process can involve hundreds or thousands of comparisons and multiple iterations from a human.
An AI agent with the right tools can automate that investigation, performing repetitive searches potentially thousands of times faster than someone doing them manually.
Now apply that same idea to understanding a game's code. Instead of searching for a health value, imagine trying to find the function responsible for jumping, enemy behavior, or the camera.
For a human, searching through thousands of unnamed functions and following how they interact can take days or even weeks. An AI agent can rapidly search code, trace instructions, compare values, run tests, and investigate possible matches. It isn't limited to memory searches, either.
It still needs verification, but the difficulty of navigating undocumented code is no longer the same obstacle it once was.
What we're seeing today in recomps
Rather than pre-emptively dismissing what a recompilation can do, look at what's already being done.
0:00
/0:47
1×
Sonic, Captain Falcon, and Pikachu in Mario games; voxel 3D Mario; The Minish Cap's Link entering the original Zelda overworld.
These experiments include character swaps, new rendering techniques, and even connections between different games. They're all powered by recompilation.
The multiplayer experiments go further. I've demonstrated six-player Sonic 2, where every player has their own camera, and four-player cooperative Mario. My Mega Man X boss rush experiment features X and Zero playing together with independent cameras, widescreen, and online netplay.
0:00
/0:25
1×
Six-player Sonic 2, each player with their own camera.
0:00
/0:33
1×
Four-player cooperative Super Mario Bros.
Another experiment brings Mario into Tomba! 2, a completely different PlayStation game.
These projects demonstrate changes far beyond what the original consoles supported. A decompilation could also support ambitious modifications like these, and that's exactly the point.
The approach doesn't determine what's possible.
Are these just "prepackaged emulators"?
Sometimes recompilation projects are dismissed as "prepackaged emulators," as though it's some sort of criticism implying these are incapable of extensibility. It's a strange semantic that doesn't at all represent what is being implied.
Words have both a denotation, their literal meaning, and a connotation, what people associate with them.
To emulate something is to imitate or reproduce its behavior. In computing, an emulator recreates the behavior of another system. By that broad meaning, even a native port built from a decompilation are emulating the game's behavior. That's the entire point, isn't it?
But when people hear "emulator" in gaming, they usually imagine a program that loads an old ROM and runs it by pretending to be the original console.
Calling something a "prepackaged emulator" creates the impression that someone simply bundled a ROM with an emulator core and called it a PC port.
If that were true, none of the showcases above would be realistically possible.
How my approach works
My recompilers do have traditional components of emulation inside of them. They're a sort of a hybrid. The primary starting differentiator is the ahead of time nativization of the code.
Since my recompilers aim to be a foundation for all games for the system, it will include a set of correctness beyond what an individual game may need. But it's all permitted to be extensible. Add to it, remove from it. Adjust it to your game's needs.
This provides opportunities for optimization and makes it practical to modify or replace individual systems. We can change the renderer, remove hardware restrictions, and adapt components for individual games.
For example, when I originally stood up Tomba, I did not have simulated cycle accounting in psxrecomp. Everything would resolve as fast as possible, and it often led to softlocks. I had to implement that to ensure that Tomba would behave. Ape Escape, on the other hand, was able to handle some changes in timing. In fact, removing some of the simulated accounting actually allowed it to speed up in areas that it would slow down on in original hardware. This is a great applied example of where it was important to one game while a hindrance to another. My recompilers are a safe baseline, but not necessarily a one-shot end result for every game.
In Tomba's case however, once I had that accurate baseline, I was able to then optimize it. In the end, I ended up actually pre-loading assets onto disk and replacing the load screen altogether to replace load screens outright, giving an experience that is effectively, if not faster than, cartridge load times for an original PSX game.
0:00
/0:17
1×
Loading the same save in Tomba! Recompiled: the original load path, then Seamless Loading.
This approach also makes reusable tools possible. Projects like recomp-net provide networking support that multiple recompilation ecosystems can use. Developers who use these platforms get infrastructure and integrations like netplay effectively for free and don't have to recreate netplay logic themselves from the ground up.
Trying to draw semantics around whether something is a [traditional] emulator or not is a misnomer. It doesn't help define anything's limitations or intents.
Preservation isn't a competition
I also disagree with the idea that recompilation or AI-assisted development somehow takes away from traditional game preservation.
There are several valuable things we can preserve:
Original game binary: The ROM, disc image, or executable that preserves the released game data.
Game recompilation: A translated version that provides another way to run, study, and modify the game.
Game decompilation: Recovered source code that helps us study the game's original implementation.
Annotated decompilation: Recovered code enriched with meaningful names, explanations, and documentation.
These aren't necessarily steps that replace one another. They're different resources that can coexist.
In traditional archaeology, studying a physical site can sometimes damage or disturb it. Digital reverse engineering is different. Studying a copy of a ROM or disc image doesn't consume or damage the original data. We can investigate the same game through multiple approaches without taking anything away from another project.
Creating a recompilation doesn't destroy a decompilation. Using AI doesn't prevent someone else from conducting traditional research.
Of course, proper documentation and preservation still matter. But more ways to understand and experience a game are a benefit to preservation, not a threat to it.
The goal should be more games, not fewer tools
Traditional decompilation has produced incredible work, and it will continue to be valuable. So will emulation, recompilation, and AI-assisted reverse engineering. These approaches can complement one another.
What excites me most is that we're beginning to see games receive attention that might never have been decompiled or recompiled in our lifetimes.
Historically, reverse engineering a single game could require a team years of dedicated work. That made it difficult for smaller games, less popular games, or entire libraries to receive the same attention as major titles.
Modern tooling, including AI, is changing what's practical. Projects that once seemed unrealistic are becoming possible for smaller teams, sometimes even individual developers.
Through RetroPortingToolkit, my goal is to lower the barrier to entry for this work, make our tools reusable, and encourage more developers to participate and contribute.
We should celebrate the fact that more games are being explored, preserved, and brought to modern hardware. These are opportunities we might otherwise never have had.
We shouldn't judge a project by whether it started with decompilation or recompilation. We should judge it by what it accomplishes, how well it works, and what it contributes to the future of these games.

https://1379.tech/decompilation-vs-recompilation-wrong-questions/

#recomps #game #both #neither

#rss #feeds #linksharing #qwibbit

Megaman X: Boss Rush Megaman X is by far my favorite of all the X ...

2026-10-25T03:37:46Z

Megaman X: Boss Rush

Megaman X is by far my favorite of all the X games. While I don't speedrun games, I do enjoy replaying X quite often. Fighting the 8 bosses is probably the most fun part of all of the game.
I know their routines quite well at this point, and there's a lot of setup to go through a stage for each fight. I wanted a way to keep the thrill going longer, and add an element of dynamics I hadn't before with mechanics I already knew. So I had the idea of trying to build out a boss rush from the original game where you'd fight two bosses at any game time. Suddenly, you have to consider the mechanics of how one boss will impact the other, setting a whole new dynamic of how to interact.
I'd already spent considerable time building Zero into the game via a co-op mode. It was an easy choice to bring this one forward into the co-op mode. I tried this out of my netplay developer, TechnicallyComputers, and we had an absolute blast. We tried to figure out a cadence of how to take on a perpetual 2v2 throughout.
0:00
/3:21
1×
Boss Rush Featuring X and a new Saber variant Zero
Boss Rush added to the main menu
The gameplay loop
You spawn in just before Flame Mammoth's boss room. It has a few small modifications to accommodate some of the other bosses. When you get to the other side, you get not one, but two bosses that are randomly chosen.
Each time a boss is defeated, a health pack drops and another boss spawns to take its place.
Players start with all weapons and full health tanks. Special weapon ammo remains independent, but health tanks are shared across players.
Playable Now
You can download the latest release here.
The mod is still technically beta, so there could be some errors. If you come across anything, do file a bug report. With that said, my friend and I were able to have a blast in our last play session, so it should be good for some players looking for a test of attrition.

https://1379.tech/mega-man-x-recompiled-boss-rush/

#bossrush #megaman #rushfeaturing #zeroboss #players #flamemammoth

#rss #feeds #linksharing #qwibbit

Rocket Knight Adventures, Recompiled Rocket Knight Adventures is ...

2026-10-24T04:09:13Z

Rocket Knight Adventures, Recompiled

Rocket Knight Adventures is Konami's 1993 Genesis / Mega Drive platformer. You play Sparkster, an opossum knight with a sword and a rocket pack, and the game now runs as a native PC port, built with my Sega Genesis static recompiler.
0:00
/0:14
1×
Sparkster in stage 1 on the native recompiled build, rendered in 16:9: sword slashes, a jump, then a rocket dash over a wall. Captured headless from the recompiled build.
Rocket pack in flight. The picture is wider than a real Genesis ever drew.
What you get
Adaptive widescreen, on by default. Extra scenery and actors across all seven stages, including vehicle sections, boss arenas and cutscenes. It fits the window as you resize it, and fixed 16:9, 21:9 and 32:9 modes are there too.
Rewind. Browse snapshots of recent play and jump back to an earlier moment.
Visual save states. Nine slots with previews.
Launcher and controls. Keyboard and controller, remappable bindings.
Optional mods. Choose how early enemies activate in the wider view, plus Start Stage, Infinite Lives, Infinite Health and Invincible if you want them.
Stage 1, with the extra width showing more of the forest.
State of things
Version 1.0.0 is the first stable release. The game is playable end to end. Some visual hiccups still occur with the extended widescreen, but should be cosmetic and not hinder gameplay end to end.
💡
Special thanks to L0LL0 for extensive QA and playtesting.
Available now
Windows x64 and Linux builds of v1.0.0 are on the release page. You supply your own raw USA ROM, and widescreen is on from the first launch; you can switch it off under Mods. Source and bug reports are at github.com/mstan/RocketKnightAdventuresRecomp.

https://1379.tech/rocket-knight-adventures-recompiled/

#knightadventures #rocketknight #recompiled #megadrive #genesis #segagenesis #stage #sparkster #infinite #mods

#rss #feeds #linksharing #qwibbit

Monster Party Recompiled is available now Keeping the Halloween ...

2026-10-24T03:36:47Z

Monster Party Recompiled is available now

Keeping the Halloween releases going: Monster Party Recompiled 0.1.1 is available now for Windows and Linux, with adaptive widescreen and controller support, save states and rewind.
Download it here. You'll need your own Monster Party (USA) ROM.
If you give it a try, please report any bugs. Happy Halloween!

https://1379.tech/monster-party-recompiled-is-available-now/

#partyrecompiled #monsterparty #halloween #linux #rom #usa #download #happy

#rss #feeds #linksharing #qwibbit

Getting into the Halloween Spirit with Recompilations! 🎃 Early ...

2026-10-20T03:15:49Z

Getting into the Halloween Spirit with Recompilations!

🎃
Early alphas: MediEvil II Recompiled and Jersey Devil Recompiled are available now. Please report any bugs and rough edges.
0:00
/0:53
1×
MediEvil II Recompiled: the museum, in adaptive widescreen. Early alpha.
It was around this time last year that I started experimenting with my first ever agent on the CLI. The first thing I tried to do was a recompilation, and it failed miserably. It wasn't until nearly February that my first project got any sort of legs.
Now, we're one year later with so much that has advanced. It seemed like the right time to celebrate in the best way possible – with a few recomps.
Growing up, I had a copy of MediEvil II and a demo disc for Jersey Devil. So these games always stuck out to me, and seemed right for the holiday season.
I've been touching these up over the month. I'd love to give them more refinement, but I think now is the right time to release and capture the holiday spirit. Here's a few of my favorite spooky titles here for the original Playstation, recompiled!
Both are alpha releases, but each make use of the psxrecomp which has been increasingly maturing. Ideally, it makes the alpha experience a bit less alpha.
MediEvil II Recompiled
Sir Daniel Fortesque is back from the dead once again, this time in Victorian London. The recompiled version turns on the full set of enhancements by default:
Adaptive widescreen that follows your window, including ultrawide, with extended terrain visibility and the HUD anchored to the screen edges.
Smooth rendering at 60 FPS or your display’s refresh rate. The game still runs at its original speed underneath.
Higher internal resolution and precise geometry (PGXP), so the 3D no longer wobbles.
Right-stick camera and optional mouse and keyboard controls.
Pre-cached fast loading between areas.
The museum library hall, with the full width of the room in view.
Download the latest release from the MediEvil II Recompiled releases page. Supply your own MediEvil II USA (SCUS-94564) disc image. OpenBIOS is included, so you don’t need a PlayStation BIOS.
Jersey Devil Recompiled
0:00
/0:39
1×
Jersey Devil Recompiled: the town square in widescreen. Early alpha.
Jersey Devil is a 1998 3D platformer starring the purple, bat-winged legend of the New Jersey Pine Barrens. Turn on the enhancements from the launcher’s Mods page:
Widescreen, either Adaptive (fits your window) or a fixed 16:9, with the HUD kept in the corners at its original size.
Higher internal resolution through the launcher’s video settings.
The town square fountain. The HUD sits in the corners at its original size.
Download the latest release from the Jersey Devil Recompiled releases page. Supply your own Jersey Devil USA (SCUS-94907) disc as a .cue with all of its track files. OpenBIOS is included.
It’s an early alpha
These are previews. Full playthroughs haven’t been certified yet, so expect bugs, especially in later levels. If you run into a problem, enable Playtest Diagnostics on the Mods page, reproduce the problem, quit normally and send the newest diagnostics folder with your report. It records your inputs and timing so I can replay exactly what happened. It’s off by default, and it never includes your disc or BIOS.
Bug reports are welcome on each project’s GitHub issues page. Happy Halloween! 🎃

https://1379.tech/getting-into-the-halloween-spirit-with-recompilations/

#rss #feeds #linksharing #qwibbit

SyncScribe vs Happy Scribe, Rev, Kapwing and Subtitle Edit: AI ...

2026-10-17T03:30:23Z

SyncScribe vs Happy Scribe, Rev, Kapwing and Subtitle Edit: AI Subtitle Generators Compared (2026)

SyncScribe is a pay-as-you-go AI subtitle generator. You drop a video or audio file into your browser, pick a language, and get back SRT and VTT subtitle files, or an MKV with the subtitle tracks embedded.
This post explains what SyncScribe does and how it compares to Happy Scribe, Rev, Kapwing and Subtitle Edit. Each of these tools fits a different job, and the right pick depends on what you're subtitling.
What SyncScribe does
Your video stays on your device. Audio is extracted in the browser with WebAssembly (ffmpeg). Only that compressed audio track is uploaded, never the video itself. This also makes uploads small and quick, even for multi-gigabyte MKV files.
Whisper transcription in 55 languages, with automatic language detection.
Translation into extra languages at half the credit cost of transcription per language. For example, one episode can get English, Spanish and Japanese subtitles in a single job.
Automatic name correction. Speech-to-text often gets character names, places and made-up terms wrong ("Ezak" for Yzak, "Afrin" for Athrun). SyncScribe works out which show or film you uploaded from the file name and the dialogue, looks up its character and place names, and fixes the misheard ones. You don't type anything. It only makes a fix when the reference data supports it.
SRT, VTT, or embedded MKV. You can download plain subtitle files for Plex, Jellyfin, VLC or YouTube. Or you can get an MKV back with the subtitle tracks muxed in. This step also happens in your browser.
Shareable result links, so someone else can download the subtitles without an account.
Credits never expire. You buy minutes when you need them, and there's no monthly plan to remember to cancel.
Who it's for
SyncScribe was built for one specific annoyance. You have an English dub of an anime whose subtitles are a translation of the Japanese script, so the subtitles don't match what's being said. More generally, it's useful whenever you have a video file and just need accurate subtitles for it:
Your own media library (movies, TV episodes, anime, home videos) where subtitles are missing or out of sync
Lectures, talks, interviews and podcasts that need a transcript or captions
Creators who want an SRT to upload to YouTube or Vimeo, without a full video editor
Anyone who needs subtitles a few times a year and doesn't want a subscription
SyncScribe vs Happy Scribe vs Rev vs Kapwing vs Subtitle Edit
Prices are from each vendor's public pricing page as of October 2026. Check them before you buy, because they change often.
SyncScribeHappy ScribeRevKapwingSubtitle Edit
Pricing modelPay-as-you-go creditsSubscription + $0.20/min top-upsSubscription (AI) or per-minute (human)SubscriptionFree, open source
Entry price$9.99 for 120 min$17/mo for 120 min$29.99/mo (Essentials)$24/mo ($16/mo annual)$0
Approx. cost per hour (AI)$3–$5$8.50 on Basic, $12 top-upBundled in planBundled in planYour own hardware
Free tier10 min on signup10 min trial45 min/month10 min, watermarked exportsUnlimited
Credits expire?NeverPlan minutes reset monthlyPlan minutes reset monthlyPlan minutes reset monthlyn/a
Is your video uploaded?No, audio onlyYesYesYesNo, runs locally
Human transcription optionNoYes (~$2/min)Yes ($1.99/min)NoNo
Subtitle editorNo (download and edit elsewhere)YesYesYes, with stylingYes, very powerful
Burned-in / styled captionsNo (soft subtitles / MKV tracks)YesLimitedYesVia external tools
SetupNone (browser)None (browser)None (browser)None (browser)Desktop install; a GPU helps a lot
Which one should you use?
You need guaranteed accuracy, such as legal, broadcast or accessibility compliance: use Rev or Happy Scribe human transcription. AI subtitles, including SyncScribe's, still make mistakes on crosstalk, heavy accents and noisy audio.
You make social videos and want styled, burned-in captions: use Kapwing (or VEED). They're video editors first, and their caption styling is the main draw.
You want it free and are comfortable with desktop software: use Subtitle Edit with its built-in Whisper support. It's excellent, but it takes setup, and it's slow without a decent GPU.
Your team transcribes every week: a Happy Scribe or Rev subscription gives you collaboration features and editors that SyncScribe doesn't have.
You have video files and just want accurate SRTs, cheaply, without a subscription or uploading the whole video: use SyncScribe. It's especially good for TV, anime and movies with lots of character names, because it corrects them automatically.
FAQ
What's the cheapest way to generate SRT subtitles for a video?
Free local tools like Subtitle Edit with Whisper cost nothing if you have the hardware and patience. Among hosted tools, SyncScribe's pay-as-you-go packs work out to roughly $3–$5 per hour of audio, with no subscription. If you only subtitle occasionally, that's less than paying for a monthly plan you won't use up.
Can I generate subtitles without uploading my whole video?
Yes. SyncScribe extracts the audio in your browser and uploads only the audio track. Subtitle Edit runs fully offline. Most hosted editors (Happy Scribe, Rev, Kapwing, VEED) upload the full video.
Is there a Rev or Happy Scribe alternative without a subscription?
SyncScribe sells one-off credit packs ($9.99 for 120 minutes, $24.99 for 400, $74.99 for 1,500) that never expire.
How do I fix anime or TV subtitles that don't match the English dub?
Dub scripts are often rewritten, so translated subtitles drift from what's actually said. Generating subtitles from the dub's audio gives you text that matches word for word. SyncScribe recognizes the show and corrects character names automatically.
Which languages does SyncScribe support?
55 languages for transcription, including English, Japanese, Spanish, French, German, Korean, Chinese and Portuguese, with automatic language detection. Any of them can also be a translation target.
Can SyncScribe put the subtitles into my video file?
Yes. It can mux the subtitle tracks into an MKV in your browser, with one track per language. These are soft subtitles that you can switch on and off in your player, not burned into the picture.
Try SyncScribe free. You get 10 minutes on signup, and no credit card is required.

https://1379.tech/syncscribe-vs-happy-scribe-rev-kapwing-subtitle-edit/

#happyscribe #subtitleedit #rev #mkv #srt #editprices #vtt #audio #english #scriberevkapwingsubtitleedit

#rss #feeds #linksharing #qwibbit

Mega Man X4 Recompiled: X and Zero, together (Preview) 🚧 Co-op ...

2026-10-16T03:33:51Z

Mega Man X4 Recompiled: X and Zero, together (Preview)

🚧
Co-op alpha: Playtest 22 is available for Windows and Linux. Expect bugs and rough edges.
0:00
/0:48
1×
X and Zero together: a look at local co-op and independent netplay cameras. Work in progress.
Mega Man X4 already gives X and Zero their own campaigns. I’ve been working on letting them share one. Both heroes can now play through X’s or Zero’s story together in Mega Man X4 Recompiled, locally or over netplay.
If you saw the Mega Man X co-op preview, this is the next one to try: X4’s own X and Zero, each with their attacks, voices and effects, in the same stages.
Two heroes, one campaign
Player 1 chooses the campaign and owns the story, boss clears and permanent progress. Player 2 joins as the other hero. Each has a separate lifebar, while retries belong to the team. You’re bringing a partner through one campaign, with both characters fighting on screen.
X and Zero at the Jungle waterfall. The stacked lifebars are the default.X and Zero take on the opening boss together. A frame from the showcase.
For couch co-op, enable X + Zero Co-op in Mods, assign two controllers in Controls, and press Play. Separate keyboard bindings work too. The same co-op option is available when hosting or joining from the launcher’s Netplay page.
One camera or two
Unified is the default: one shared view for the pair. It’s also the camera used for local play. Over netplay, Split (Experimental) lets each player have an independent screen following their own character. You can take different routes through the same shared world without keeping both heroes inside one camera.
Two views from the same netplay match: X on the left, Zero on the right. Split cameras are experimental.
The launcher supports Online Netplay and LAN / Direct IP. Both players need the same release, and the host chooses the shared co-op options. Split is still experimental and can slow down; Unified is the place to start.
Make it your run
Optional rules let you tailor the run:
Boss doors: either player can open them normally, or you can require both living, present players to arrive.
Boss scaling: double effective boss health with shorter shared hit cooldowns.
Double and Iris: fight both story bosses in sequence. Return to the inner door after the first encounter to start the second.
Character codes: enable Ultimate Armor X’s code and Black Zero together. X still needs to visit a capsule for the armor.
Boss scaling, the extra encounter and character codes are off by default.
Double in co-op. The option to fight both story bosses is off by default.Iris in the same co-op run, with the optional encounters enabled.
Try Playtest 22
Download the Windows ZIP or Linux x86_64 AppImage. Linux needs glibc 2.38 or newer. Supply your own Mega Man X4 USA (SLUS-00561) disc image; choose the .cue from a .cue + .bin set. OpenBIOS is included. Co-op requires OpenGL and a fresh game boot.
This is still an active alpha, so expect bugs and rough edges. Normal memory-card saves keep your campaign progress between playtests.
If you hit a problem, leave Playtest Diagnostics enabled, reproduce it, quit normally, and send the complete saves/diagnostics folder with your release version and a video timestamp. For netplay, collect both players’ logs. The playtesting guide has the details, and bug reports are welcome.

https://1379.tech/mega-man-x4-recompiled-x-zero-coop-preview/