Pokemon Emerald Ported to WebAssembly (100k FPS)(pokeemerald.com) |
Pokemon Emerald Ported to WebAssembly (100k FPS)(pokeemerald.com) |
https://holy-lake-f6df.sdreyesg.workers.dev/
took me 3 hours with Opus. Opus knew the whole ISA, clock, bus quirks, etc. from their training without any external docs
Btw, it seems there's a crash when you choose "Pokemon" in the "Fight/Bag/Pokemon/Run" menu:
X link: https://x.com/AlexStLouis10
I used an emulator on my laptop with increased speed so it made everything like walking and combat way faster which was really nice and I probably would have given up if it wasn't for that
Then I start to explore another Pokémon hacks and find out that those project has big fan community that are very enthusiastic about bringing new features to classical Pokémon formula. Documents/wiki on web are more detailed than original games has!
For example R.O.W.E mix all kind of modes that you can select, connect Johto and Kanto maps togather, gives you options to limit avalible generations of Pokémon's, so as veteran you can feel more like home.
Another hacks that I need to explore more - Pokémon Gaia and Pokémon Odyssey.
I find it improves the game when I don't have to spend a bunch of time leveling up or earning gold for equipment.
Enter is off by itself, so you have to move a hand to press start. Switching to space would solve that.
(I prefer wasd for arrows, and h/j for b/a with y/u or u/I for start/select, but I think most b̵r̵a̵i̵n̵ ̵d̵a̵m̵a̵g̵e̵d̵ right handed people prefer arrows.)
...Why is the D-pad always on the left on all of the controllers/handhelds anyhow, and the buttons on the right? After all, they're aimed mainly at the right-handed people, right?
Another reason I prefer wasd is I mainly use laptops, they always have tiny arrow keys.
(Not original creator of the port!)
I had a project 'discord plays pokemon' written in TypeScript that allowed users to play Pokemon together.
The architecture was a GPU accelerated Docker container running a full browser and desktop environment.
With this it can all be done in-process. I threw Claude at the problem and it worked!
https://github.com/shepherdjerred/monorepo/tree/main/package...
AND - I didn’t have to blow air on the cartridge connector for it to work?
Is this the future?
If anyone has emulator suggestions, I recently attempted a playthrough and found that midway through my copy of red, the game was corrupted? Oddest thing -- hadn't reading the point where you do the "Missingno trick" near cinnebar.
Anyways, I suspect the save got corrupted somehow but it made me swear off emulation and try a physical copy. (Which had the battery I replaced fail... it's been a comedy of errors).
So you have available all of the original Pokémon
I have a copy of red, but even with a new battery the save function keeps failing. I suspect I didn't seat the battery well and I need to solder it, but I am not trained in that and reluctant to have my first project involve an expensive retro cart.
The one caveat is that a PWA needs an icon but the project doesn't currently have one, so you'd have to design, find, or LLM-generate one.
https://github.com/rh-hideout/pokeemerald-expansion/blob/mas...
If there's already C code (for pokemon emerald there already was a decompiled C/ASM codebase), you usually just compile it and it works, or swap a few native dependencies with portable ones. If you have some ASM code already for some old architecture, then it's a pretty straight forward translation to WASM (not really, but iterable enough with LLMs). So yeah, you can have the first target for your thing to compile, then take a screenshot of first few frames for you to check visually and some framebuffer hashes for automatic verification and use those as an oracle for if it also works correctly. Then iterate a little more, maybe implement saving/loading and load a few checkpoints and register a few deterministic inputs and see some more framebuffer hashes, crashes, state checksums and you're good.
It didn't used to be this way.
I think 20-30 years of copyright should be plenty to extract whatever profits you deserve from the fruits of your labor. Anything beyond that is just holding culture hostage for the benefit of a few. It doesn't serve society in any meaningful way.
This browser based version on the other hand, is in far murkier territory. The fact you don't need a ROM means the assets are definitely included by default on this site, and Nintendo would have a way better case for getting it taken down.
It's basically equivalent to those ROM sites that let you play GBA ROMs in the browser through an emulator written in JavaScript or WebAssembly.
But Nintendo's lawyers pay a lot less attention to anything prior to the Switch generation, and the same presumably goes for the Pokemon Company ones. If this project gets a lot of media coverage it's probably toast, but if it's mostly discussed on the odd programming forum like this one, it could survive a very long time.
There also a craze of DS style emulators popping up. They all give you comfort knowing that your saves will be fine forever if you back them up, even if the device dies.
Anyways, I just want a "known good" emulator for the game boy. It could be a GBA emulator since that's backwards compatible, but I just want something simple to play Pokémon.
To be clear I was weirded out because an emulated copy glitched out, not the physical one. Physical one just had a battery issue.
1. those assets are stored in proprietary formats that only the game code itself understands, and
2. no tool exists in the project to extract the assets from these proprietary formats into open formats, unless that tool itself exists only in source-code form in the codebase, and requires the ROM as an input to compile it (even if in the case of such a tool, the ROM is doing nothing but serving as a "key" to unlock compilation.)
Basically, if you have to prove you have your own copy of the IP in order to make their embedded copy of the IP "legible", then it's very hard to construct an evidence-based DMCA takedown order that actually makes any coherent point about the project "distributing" said IP.
That being said, shipping assets like this at all, even if you "can get away with it", is ultimately just a kind of laziness / shortcut-taking. They do it because there's either no clear/simple/obvious way to automatically extract the given asset data from the ROM (e.g. because the relevant data is split up into various data planes + metadata bits that are stored "exploded" all over the ROM), so they just did it once by hand, committing the results; or because there's no clear/simple/obvious way to store the extracted asset data such that a regular compiler/assembler natively understands how to embed it into the binary in the particular form it was found in the original ROM. (Remember, re-assembling/compiling to the original ROM is always the test these projects use to ensure their disassembly/decompilation is preserving semantics. So they need to replicate every weird layout quirk the original dev tooling imposed upon the original ROM. And sometimes the original dev tooling included special-purpose domain-specific asset-codegen tools that aren't part of regular compiler toolchains.)
What these projects should actually be doing, is taking on the schlep: writing the extract tooling anyway, even if it's just "copy these bytes from here and these bytes from there, and spit them out as hex in an .asm file with this header"; and/or writing matching asset-codegen tooling to the tooling that likely existed in the platform SDK, to run before compile/assemble time, converting the extracted ROM asset files into a form (probably a bunch of little assembly files) that will land in the right places when linked back together to form the original ROM.
And, to be clear, they mostly do do this! These projects are very good at doing this!
But sometimes — especially on a larger project with many contributors — one or two things like this aren't audited properly, and fall through the cracks. Or they start out as temporary "bootstrap" approaches made during a private phase of development to get things working + compiling to a correct image; and then not all of those get cleaned up before the repo gets made public.
To be clear; I don't really understand the law around this - my own country is based on case law which means that even if I wanted to open source some of my reverse engineered games (I have a few private partial implementations of some old defunct game engines in-progress), the distinct lack of prior cases means, sadly, it's prudent not to release them at all while the companies are still active.
