Comments
158 total · 158 loaded
What's actually happening is a 13 year old downloading Pokemon.rom.exe and clicking on it.
The price of carelssness is too high of an irreversible lesson.
0 - https://www.theguardian.com/business/2026/sep/08/ai-cure-can...
https://old.reddit.com/r/SteamDeck/comments/1x0vzyb/speedbre...
Forza Horizon recomp: https://github.com/arcanite24/pinyon-shift
More Xbox 360 projects here:
It's an emulator with an embedded rom. The only thing that was saved is precompiling a switch statement to function calls.
Stop calling these static recompilations.
And the cherry on the top: "port.sh takes a disc image (an ISO, or a ZIP or 7z archive holding one) and does the whole job. It reads the boot program named in the disc's SYSTEM.CNF, translates its machine code to C++, and then runs the game headless a few times. Static analysis cannot see every function a game reaches through pointers, so each run writes down the addresses it could not find, the script adds them as entry points and translates again, until a run gets through without new ones. The same runs record the vector unit microprograms the game uploads, which are compiled ahead of time as well. Last it builds the page into build/web-mygame and the native runner into build/native-mygame. God of War II goes from ISO to page in three and a half minutes on an 8-core laptop. The exploring runs press start and then cross every five seconds, which gets most games through their title screens, and put an empty memory card in slot 1 the way the page does, so they follow the path a player takes. --press 900:cross replaces that with your own inputs and --frames sets how long each run lasts. Frames from the last run land in games/mygame/shots, which is the quickest way to see how far a new game gets. scripts/build_web.sh mygame rebuilds only the page."
So it's not even a static recompilation, it's completely heuristic based. "Porting" the full game involves [playing through all of it, just in case the devs decided to add some special effects in the last level. This step could be completely omitted, by just dispatching at runtime, since all you're doing is replacing instructions with function calls. But at that point it's literally an emulator all the way through. BTW emulators also do all of this..... but they do it dynamically, automatically, at runtime, without having the game crash, and sometimes even caching the results, so the above is objectively NOT the whole job, but stopping midway and hoping it works.
And also hilariously, it also misses the fact that a lot of japanese games usually used circle instead of X to confirm, so the "automated static recompilation pipeline" wouldn't even get past their title screens.
But instead of single games, I "built" an ARM-to-WASM transpiler in WASM. Also cool transcoding of WebGPU shaders, audio, and more.
Only have tested a few games so far, it's early days, but works quite well in Chrome mobile on flagship Android phones.
Even using the original ps2 or ps3 controller with the right drivers on PCSX2 doesn't really reproduce the same smooth acceleration/brake curve of the PS2.
Playing them on a keyboard or fully digital inputs is just a miserable experience.
why not? if we're at the point of byte perfect recomp of system firmware+games, surely we could find a patch that would fix that in both pcsx2 or this project
So apparently, to make pressure sensitive PS2 controller work in PCSX2, you need ShanWan PS2-to-PS3 adapter (or equivalent), DSHidMini, and set input mode to SDL. Since I lack both pieces of hardware, I can't test it myself. Or skip the middleman and get a PS3 controller, which is a better option anyway for several reasons.
Patching that is possible I guess, but it would also require setting up some sort of calibration in the game.
Analog buttons were always a bad idea and should never be used.
These days you can map analog triggers to the sticks for a modern experience if you want that.
It gets wonky if you press both analog triggers at the same time though. I've also tried mapping them to X and O to simulate the pressure, but the range is also somewhat off, with a way steeper curve (half pressing a trigger gives nearly 100% intensity of the OG buttons).
An alternate solution I've seen around is using a GMIX or similar devices and mapping the g29 wheel controls from the game to a modern Xbox/PS controller, but I've never tried it myself.
I assume it would require some additional patching in those GT / NFS games though...
I'm sure music stores got fucked for awhile but now independent ones are doing well with a huge vinyl resurgence.
Now it appears live nation and ticketmaster are the thieves.
Sharing cracked PC games has been a thing since the dawn of the industry, yet it has continued to grow and thrive.
Console…maybe? But good Switch emulators have been around for years, yet Switch hardware and exclusive games that ran better-than-native under emulation continued to sell in record numbers, and Sony has always delayed the release of PC ports of PlayStation exclusive titles to ensure healthy console sales.
The internet sparked interest in independent music, artists had been fed up for a long time regarding earnings, and the music being made by the big labels was already pretty lackluster by this point in time.
If they actually embraced the digital era of mp3s rather than throwing lawsuits at the problem they would of been on top.
Music should be free, however these dinosaurs are stuck in tar and will continue to sue, hoard and milk their old ways restricting innovation and progress.
No sympathy for any of the wet teabags in the music industry.
Aka lost sales.
Anything that shows its no longer worth it will accelerate that industry using newer tools to make games faster with multimodal language models powering audio, voice, asset generation, rendering as well as agentic workflows for the manual work humans would still be involved in
right now, AAA studios won’t do it and their audiences wont want them to do it, but any dedicated indie developer that would have never hired the teams of people needed for those aspects can do it. a nearby parallel reality where AAA do it based on no ability to protect high valued IP now looks closer with the decompilation route
Emulators + ROM is one way to do that. Recompiling from the ROM is another. I think that for most people, your stance on if emulating is stealing or piracy, will well-predict how you feel about recompilation tools.
I swear gamers have the most insane Stockholm syndrome. It's super common to see them say that it's a problem that there aren't enough "exclusives" for a console. Like, dude, the problem is that the console sucks next to its competition. You shouldn't want product tying to try to make you buy it. They're literally all just branded commodity computers that are locked down to tie purchases (an illegal, anti-competitive practice) at this point. This was already litigated multiple times 20-30 years ago and the big companies consistently lost every case. Sega even lost a case where a company displayed the message "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES LTD" for a game that Sega had not approved because it was required for the console to boot, and they couldn't try to use trademarks to stop someone from developing for their console.
You can also buy third party products that take original cartridges, but again the companies aren't interested in selling cartridges, so no surprise if they end up pirated.
It's like the Sega case: "we made it impossible to use our hardware without violating our trademark, and then they violated our trademark. OMG!" Okay? Don't do that.
Especially when, for games of this age, we're talking about going through the secondary market, and paying potentially hundreds of dollars for a physical copy, without the creators seeing a dime of that transaction to begin with.
- might interest you, if you like the topic you're currently reading: https://thegamingemporium.com/recent/
https://github.com/snuri00/ps2-web-recomp/blob/1066c9eea78c2...
"PlayStation 2 games running in the browser without an emulator. The game's Emotion Engine machine code is translated ahead of time into C++, compiled to WebAssembly, and linked against a reimplementation of the PS2's operating system and hardware that draws with WebGPU."
Instead of high-level emulation, the decompiled C source is compiled directly to Xtensa machine code for the ESP32-S3. We replaced the PlayStation SDK/GPU/GTE with custom software routines, running on a DIY handheld built around a Seeed XIAO ESP32-S3 Sense.
To speed up development without constantly flashing hardware, we run the compiled firmware image directly inside a browser-based hardware simulator CLI (velxio-cli) to verify serial outputs and execution in seconds.
Having 100% matching C code makes native ports to embedded platforms completely feasible without relying on heavy JIT/interpreter glue.
Fucking amazing that this person can prompt to embed an emulator into a binary and call it "no emulation recompilation" and get not one but two threads on the front page. LLMs are such an amazing tool for liars to produce upvotable slop, nobody gives a fuck about verifying whether the claims are true.
"PlayStation 2 games running in the browser without an emulator. The game's Emotion Engine machine code is translated ahead of time into C++, compiled to WebAssembly, and linked against a reimplementation of the PS2's operating system and hardware that draws with WebGPU."
I am not an emulator! Here is how I'm emulating the ps2!
I've been building the tooling around the PS2 binaries and hope to have a standalone PSS player out soon that can play PSS files as they are encoded, via simulated renderer, and via in-game engine renderer. The future is so bright with LLMs!
Physical disc production ending in January 2028
https://blog.playstation.com/2026/07/01/physical-disc-produc...
What's the performance like on heavier titles?
Have a look at Decky loader and Emudeck.
And can just port the emulator to wasm, and have people able to run their own roms. That would mean you're suddenly retroactively making all of those ps2 games platform agnostic.
This just makes one game playable, by artificially limiting the emulator to running this one game. If you're recreating a ps2 in software (which this project is), you should be able to run any game.
there's an actual sku of one lenovo handheld that officially runs SteamOS, i assume that's what GP is referring to
At the time you needed a fairly capable gaming PC for PS2 emulation, which is a far cry from the igpu in an atom. Given a PSP is basically a cut down PS2, I don’t think emulation on that calibre hardware is an achievable goal. An atom doesn’t even have a hardware programmable vertex shaders, on windows I don’t even think they had GL 2.1.
I never thought I’d see the day where an atom would be vintage tech, and people would still be rocking said vintage tech. It’s amazing you’ve kept it running and usable. Modern PCs can’t even keep up with modern OS, and you’re still rocking the good old days of single core single thread. Rock on!
I've got GL 2.1 running under n270 perfectly well, up to the point to test Yandex Maps to roam around Prypiat.
Even for emulation PPSSPP was far less demanding than PCSX2.
Newer APIs are also more flexible, making fewer assumptions about how things in the pipeline should run. E.g. the way a buffer clamps or overflows compared to the PS2 may be hardcoded in OpenGL 2.1 meaning you have to write emulation of that feature inside the older API to then run the code to emulate the buffer. In OpenGL the shaders types are limited in this manner, in WebGPU you can just use arbitrary compute shaders instead of having any assumptions at all about the rendering pipeline.
There are tradeoffs to selecting the older APIs just as there are tradeoffs selecting the newer APIs. Generally, the latter is easier on the implementation side for emulators.
That doesn't necessarily stop you from pointing an LLM at it and getting a working WebGL 1 version of course, it's just not a universal answer to "how should someone spend their tokens.
Now, OpenGL ES 2.0 isn't OpenGL 2.0, this is the trap of those that think OpenGL is the same everywhere.
Also OpenGL 3.3 is from 2010, whereas OpenGL 2.1 was designed for 2006 hardware, how back you want to get?
Because not every hardware capable of running PS2 level games supports the newer APIs.
> Also OpenGL 3.3 is from 2010, whereas OpenGL 2.1 was designed for 2006 hardware, how back you want to get?
Doesn't matter how old it is, what matters is if it has the required features or not. For the use case being discussed, GL 2.1 is sufficient so there's no good reason to not target it. That's my philosophy at least. When I write code, I always use the oldest library or API that has the stuff I need. I don't just go automatically for the latest one.