Standalone game vs ROM patch: what changes?
First identify what the developer distributes. A ROM patch modifies your own matching base game, a standalone project arrives as a complete application, and a source-built project must be compiled locally. Those routes are not interchangeable.
Bring the matching base
The developer supplies a patch, not the complete game. You apply it locally to the exact legally obtained base game named in the project instructions.
Needs: patch + matching base + compatible patcherInstall the complete application
The developer distributes a complete game for one or more supported operating systems. You follow that project's install instructions without supplying a ROM.
Needs: official installer or package + supported deviceCompile the official code
The developer publishes source code and a toolchain. You create the playable output locally instead of downloading an unofficial ready-made build.
Needs: source + documented toolchain + build stepsWhat you receive—and what you must provide
The profile's Distribution field decides which column applies. Never infer the route from the project's name or visual style.
| Model | Developer provides | You provide | Main action | Never substitute |
|---|---|---|---|---|
| ROM patch | A patch containing the project's changes | The exact legally obtained base game required by the developer | Apply the patch locally with a compatible patcher | A prepatched download or mirror |
| Standalone install | The complete game application through an official source | A supported computer or device | Follow the project's operating-system-specific instructions | A ROM, emulator or patch |
| Build from source | Source code and build instructions | The exact toolchain named by the project | Compile the project locally, then follow its runtime instructions | An unofficial ready-made build |
Choose the correct route in four checks
- Open the profile. Read its Distribution field before downloading or installing anything.
- Use the developer-owned source. Do not replace an unavailable official page with a mirror, repost or prebuilt copy.
- Follow that project's exact requirements. Base revision, operating system and toolchain can differ between projects.
- Back up before updating. Keep the previous working build and an independent copy of the in-game save.
Pocket Deal Radar never hosts or links ROMs, BIOS files, prepatched games, mirrors or unofficial compiled builds.
Three files that can look like downloads but need different actions
A ZIP extension tells you how files are packed, not how the game is installed. Inspect the official instructions and extracted contents before choosing a patcher or emulator.
| Illustrative contents | Question to answer | Next action |
|---|---|---|
| A BPS patch and README | Which exact base does the README require? | Match the base and use a BPS-capable patcher |
| A complete game folder with an executable | Which operating system or runtime does the creator support? | Follow the standalone instructions, keeping the folder together |
| Source files and build instructions | Which toolchain and revision are required? | Compile according to the project's instructions |
These are examples, not a file-extension detector for every project. A source repository may contain assets or patches too; the documented distribution route is still the deciding evidence.
Pokémon Nova's Windows route demonstrates complete-folder installation. Renegade Platinum demonstrates why an xdelta package needs a different tool from our browser patcher. Read each game's own requirements rather than combining their steps.
Choose the software path before buying or configuring a handheld
“Plays Pokémon” is too broad to identify a runtime. A GBA-capable device can provide a route for a prepared GBA hack, while a standalone Windows game needs a documented application or compatibility path. A source-built project must first produce its output before that runtime question can be answered.
- Identify the project and its distribution field.
- Identify the intended platform and the creator's supported runtime.
- Check the handheld's actual operating system and available software.
- Check input, readable screens and save handling after the game launches.
Use the GBA handheld setup guide for GBA patch outputs and the DS guide for DS outputs. Check the selected device’s emulator or runtime requirements before installing.
For example, copying a Windows executable into a retro handheld's GBA folder does not transform it into a cartridge game. Likewise, a patch file does not become playable simply because an emulator can browse to it.
Updates follow the model, but save rules follow the game
A patch update may require a new output from the clean base. A standalone update may replace an application folder. A source update may require another build with the documented tools. None of these descriptions, by itself, proves that an old save will carry over.
Keep the previous working game and a readable save backup. Read the creator's release-specific migration rules, then verify the intended new version, Continue and another in-game save. If you also move devices, complete the same-build transfer first where compatible.
The comparison table and profiles help distinguish distribution and recorded save-compatibility statements. Use the maker's actual conditions rather than treating a shared game name or platform as a migration guarantee.
Use the guide that matches the model
A patch guide cannot safely replace standalone or source-build instructions. Continue only through the route shown on the profile.
Based on the creator's documentation, checked 21 Sep 2026. Not hands-on tested unless a section says 'We played it'.
How we check