Back in 2021, the source code for The Simpsons Hit & Run leaked online. As someone who does a lot of WebGL for work, my first thought seeing the leak was "it'd be cool to get this running in a browser". So that's exactly what I did (for fun and science).
I did a full port of PC version of the game to WASM and WebGL. It runs at native resolution, fetches game data on-demand over the network, and comes with extra features from the Xbox version like lens flares, widescreen support, and the refraction effect on Frink's hover car.
Haven't done a full write-up on the process yet, but I'd say the hardest parts in order were:
1. Audio
The game models sound as many individual tracks with properties like gain and pan, and either a static or streaming buffer containing the raw audio samples. It expects a synchronous-style audio API from the host, e.g. if it tells a sound to play, then it expects to be able to immediately query the state of the track to see that it is playing and how many audio samples have elapsed.
In order to accurately match the mixing logic of the game, we need full control over the audio samples being played and for this to be done with low-latency. The Web Audio API gives you AudioWorklets to achieve this. They are called very frequently (a few hundred times per second) to deliver the next batch of samples. This means they need to return very quickly to avoid stalling the audio stream. They are also run on a separate thread, so it's up to you to figure out how to provide them with the data they need.
So I had to build a small set of lock-free shared memory structures (locks would be able to stall the audio) to transfer the constantly updating track descriptors (e.g. gain, pan) and their PCM data to the worklet. For example, for the track descriptors I used a double buffer in shared memory with an atomic flag to indicate which buffer is 'live'. When the main thread needs to write, it writes to the non-live side and flips the flag. When the worklet reads, it reads the flag and the data, then reads the flag again to make sure it didn't change in the middle of reading.
This was coupled with a bunch of state management needed so the game would see the current state of each track even if the worklet hadn't picked the changes up yet. Overall, audio was quite fiddly and hard to debug!
2. File I/O
The game has a lot of small assets read as whole files (e.g. 3D models, scripts), but also larger archives which it reads small slices from (e.g. sound). The former is easy to do with a simple fetch, but the latter would require either loading the whole ~500 MB file or using a Range header which doesn't cache very well. I also needed to serve all the assets somewhere where they'll load fast and not cost me a fortune in bandwidth.
I ended up going with Cloudflare R2 for its free egress, and wrote a Cloudflare worker in front to provide an interface to fetch assets in 1MB chunks thus avoiding the use of a Range header. This provides the ability to load assets on-demand with full caching.
Safari was also a huge pain here. The game does some blocking I/O for things like save data. I originally implemented this by performing the IndexedDB operations n a worker thread, with a short spin lock on the main thread (since Atomics.wait() can't be used on the main thread). This works in Chrome and Firefox but causes a deadlock in Safari - I assume because it proxies the actual work to the main thread. So I had to rework all of the places where the game touches save and config data to poll every frame for completion which was a pain.
3. Graphics
The game is built around a DirectX 8-era fixed-function rendering pipeline, so emulating it with 'modern' WebGL 2 wasn't too difficult. I built a single uber shader that takes all the fixed-function inputs like bone weights, a fixed light array, flat shading toggle, etc. Modern GPUs handle branching pretty well when all shader units take the same path, so this kept the rendering simple without needing to manage dozens of shader permutations.
The main performance issue I ran into was CPU overhead from the number of WebGL calls I was making per frame. This was mostly solved by keeping track of the last set WebGL state to avoid making redundant calls (e.g. rendering particle effects might call gl.disable(GL_DEPTH_TEST) several times) and writing all the shader uniforms with a uniform buffer instead of thousands of gl.uniform*() calls per frame.
Lens flares were interesting to port from the Xbox version as they use occlusion queries which allow you to check if any pixels from a mesh are visible on the screen. The game assumed occlusion queries would be available to read on the next frame, but it can actually take longer, so I had to rework that. The refraction effect for the hover car was also fun to wire up, since it's the only thing in the game which requires access to the framebuffer as a texture.
Oh and for FMVs, I just converted them to H264 MP4s and play them with a HTML <video> overlay. Nice and simple.
Have fun! It should run well on most hardware. Runs great on my Pixel 10 as an example (but a physical keyboard is needed). Firefox on macOS is quite stuttery - if there's a Mozilla engineer here I'd love for you to tell me why!
The File Explorer in Windows has so much tech debt behind it.
It's quite obvious to see which parts are still Win32 and which are XAML. The two different context menus are a well-known example, but one that really annoys me is the Home view vs. the This PC view.
If you make Explorer open with the This PC view by default, you get a blinding flash of white every time you create a new tab in dark mode. That doesn't happen with the Home view which has been updated to XAML.
It's one of the many things you experience day to day that really makes me disappointed in the level of quality in modern Windows.
Have you seen those movies where a small town in the US holds a festival or carnival with heavy floats on top of a car? That is the UI they've implemented in Win11, one interface mounted on top of another, therefore overwhelming slowness, a botched job that only shows disinterest, perhaps with the aim of forcing users to upgrade by investing as few resources as possible in it.
Linux is the antithesis of this, with a long history of slow file explorers/managers that finally stand out today in terms of speed and features, fortunately. (this is to support the other user's comment about Dolphin (my choice when Linux) and Nautilus.
Genuine question - under the hood is this more of an emulator like PCSX2 or a compatibility layer like Wine?
Since the PS4 is more or less an x86 computer, I imagine most of the hard work would be implementing the system/graphics APIs of the PS4. Or are there major hardware differences between an x86 PC and the PS4 that also need to be handled?
they must have a shader recompiler infra, because all the shaders are shipped precompiled directly for the platform on consoles. so it's a good bit more than what wine does, at the very least in that regard.
For PC games and applications, Direct3D shaders are supplied in a high-level shader language (not-so-coincidentally called High-Level Shader Language), given that there is no standard GPU architecture on Windows PCs. Wine does still need to translate that to the target graphics library, as well as all the drawing calls themselves, though.
There are also some considerations regarding texture compression, I believe, which is a function usually performed in dedicated GPU hardware, and not all GPUs support all formats.
Not a developer in the field, but I believe generally the HLSL isn’t packaged in the game. Instead an intermediate format called DXIL is produced at build time from the HLSL, and that’s what is packaged.
Ah, sorry, then I carried over an assumption from OpenGL (where GLSL is actually what's packaged, or at least was a couple of years ago when I last looked at it).
In any case, that intermediate representation is probably still easier to compile to hardware-specific code, especially if the hardware has a Direct3D implementation. That's what it's designed for, after all!
Technically true but if you are going to use SPIR-V you might as well jump over to Vulkan. Do you know of any OpenGL games that actually ship SPIR-V? I can imagine it getting used in CAD applications with huge legacy OpenGL code bases but for Games OpenGL+SPIR-V doesn't really have a good use case.
When one tries to really nail down the exact, precise, 100% accurate definition of "what an emulator is", one finds it is like nailing jello to the wall.
I've seen several people online discover what the idea of an emulator is, and then they'll say in amazement "so we could do this and that and the other?", and the answer, no matter what it is they propose, is "yes, someone's done that". Recompile the code entirely into another assembler? Partially do so? JIT it? Ship specific patches for specific content? Emulate gates? Rewrite on the fly? Shim things slightly to change what functions are loaded? All that and more has been done. And even if you draw a sharp line through those things, all the combinations you can think of have also been done, and how will you draw the line through that?
I think one of the best ways of thinking about it is that there really isn't any such thing as an emulator. There's just numbers, and they need an interpreter and the ability to reach out to some set of externally-defined functionality, and there is a profound sense in which you have to have some particular hardware manifestation of an interpreter and some functionality to get anywhere, but that particular manifestation is a lot less important than people think. This has only become more true in a world where your CPUs are already not actually executing assembler opcodes anymore, and your OS is already shimmed away from the hardware in another level, and the OS is wrapping your program in yet more abstraction before it even runs a single instruction, which may well include providing a choice of which sets of "externally-defined functionality" the numbers can ask for (different Windows subsystems, etc.). Even the "base system" has a lot of "emulators" in it nowadays. It's emulators almost all the way down! Which suggests that rather than being special, they're actually quite fundamental, and sure, sometimes you need a greater translation layer between this program written with these numbers and this particular chunk of hardware and sometimes you need less, but it's a lot less a distinction of "kind" than you might think.
This is not the only way to think about it; there are certainly valid perspectives from which "emulators" exist, e.g. as a distinct category in a software catalog they're sensible. We all know what that means. But for your own understanding of how the world works, the previous paragraph has a lot to recommend it.
Indeed, it was a backronym. I'm glad they finally got rid of it, because it was untrue, and because it continues to be the source of unpleasant exchanges online.
Wine doesn't emulate hardware, but it absolutely does emulate the Windows runtime environment. (In fact, it wouldn't work very well if it merely implemented APIs based on a spec instead of emulating observed behavior, since some of the bits required for compatibility are undocumented.)
Unfortunately, that phrase was in fashion at a time when a lot of people first discovered Wine, so there is now a generation of enthusiasts incorrectly chiding people who refer to Wine as emulation. And, of course, others who see this happen and don't know any better sometimes go on to perpetuate it themselves. Makes me sad every time it crosses my path.
So glad I saw this on November 10 before the deadline. I quickly set up a Play Console account, verified my ID and set up a draft of my app to ensure I'd be in the clear.
Been working on an indie game for the last couple of years - would have been a huge pain trying to find 20 people with Android devices to meet this arbitrary threshold.
At first we thought it was just bad luck, but after it kept happening after for a week we investigated. After managing to debug Chrome itself we narrowed it down to the 'abort' event on an AbortSignal. It seems that attaching an 'abort' handler in a certain way, and then aborting the signal, causes a hard crash of the content process.
I'm an engineer on Atlassian's new whiteboard feature for Confluence, which has real-time collaboration like Figma. We've been highly successful using Cloudflare Durable Objects to act as a simple relay for WebSocket messages.
One of the best things is that the Durable Object will automatically run in the closest Cloudflare data center to the first user who connects, which helps keep latency very low.
The alarms feature they added last year has also been great at allowing us to asynchronously snapshot the state of a board certain intervals, rather than us needing to schedule the job from an external system.
One of the benefits of our new storage engine[0] is that it'll be much easier for us to host it in any datacenter, rather than just the biggest, best-connected ones. We still have a lot of work to do to make this available to all durable objects and actually start utilizing smaller datacenters this way, but we're working on it.
I did a full port of PC version of the game to WASM and WebGL. It runs at native resolution, fetches game data on-demand over the network, and comes with extra features from the Xbox version like lens flares, widescreen support, and the refraction effect on Frink's hover car.
Haven't done a full write-up on the process yet, but I'd say the hardest parts in order were:
1. Audio
The game models sound as many individual tracks with properties like gain and pan, and either a static or streaming buffer containing the raw audio samples. It expects a synchronous-style audio API from the host, e.g. if it tells a sound to play, then it expects to be able to immediately query the state of the track to see that it is playing and how many audio samples have elapsed.
In order to accurately match the mixing logic of the game, we need full control over the audio samples being played and for this to be done with low-latency. The Web Audio API gives you AudioWorklets to achieve this. They are called very frequently (a few hundred times per second) to deliver the next batch of samples. This means they need to return very quickly to avoid stalling the audio stream. They are also run on a separate thread, so it's up to you to figure out how to provide them with the data they need.
So I had to build a small set of lock-free shared memory structures (locks would be able to stall the audio) to transfer the constantly updating track descriptors (e.g. gain, pan) and their PCM data to the worklet. For example, for the track descriptors I used a double buffer in shared memory with an atomic flag to indicate which buffer is 'live'. When the main thread needs to write, it writes to the non-live side and flips the flag. When the worklet reads, it reads the flag and the data, then reads the flag again to make sure it didn't change in the middle of reading.
This was coupled with a bunch of state management needed so the game would see the current state of each track even if the worklet hadn't picked the changes up yet. Overall, audio was quite fiddly and hard to debug!
2. File I/O
The game has a lot of small assets read as whole files (e.g. 3D models, scripts), but also larger archives which it reads small slices from (e.g. sound). The former is easy to do with a simple fetch, but the latter would require either loading the whole ~500 MB file or using a Range header which doesn't cache very well. I also needed to serve all the assets somewhere where they'll load fast and not cost me a fortune in bandwidth.
I ended up going with Cloudflare R2 for its free egress, and wrote a Cloudflare worker in front to provide an interface to fetch assets in 1MB chunks thus avoiding the use of a Range header. This provides the ability to load assets on-demand with full caching.
Safari was also a huge pain here. The game does some blocking I/O for things like save data. I originally implemented this by performing the IndexedDB operations n a worker thread, with a short spin lock on the main thread (since Atomics.wait() can't be used on the main thread). This works in Chrome and Firefox but causes a deadlock in Safari - I assume because it proxies the actual work to the main thread. So I had to rework all of the places where the game touches save and config data to poll every frame for completion which was a pain.
3. Graphics
The game is built around a DirectX 8-era fixed-function rendering pipeline, so emulating it with 'modern' WebGL 2 wasn't too difficult. I built a single uber shader that takes all the fixed-function inputs like bone weights, a fixed light array, flat shading toggle, etc. Modern GPUs handle branching pretty well when all shader units take the same path, so this kept the rendering simple without needing to manage dozens of shader permutations.
The main performance issue I ran into was CPU overhead from the number of WebGL calls I was making per frame. This was mostly solved by keeping track of the last set WebGL state to avoid making redundant calls (e.g. rendering particle effects might call gl.disable(GL_DEPTH_TEST) several times) and writing all the shader uniforms with a uniform buffer instead of thousands of gl.uniform*() calls per frame.
Lens flares were interesting to port from the Xbox version as they use occlusion queries which allow you to check if any pixels from a mesh are visible on the screen. The game assumed occlusion queries would be available to read on the next frame, but it can actually take longer, so I had to rework that. The refraction effect for the hover car was also fun to wire up, since it's the only thing in the game which requires access to the framebuffer as a texture.
Oh and for FMVs, I just converted them to H264 MP4s and play them with a HTML <video> overlay. Nice and simple.
Have fun! It should run well on most hardware. Runs great on my Pixel 10 as an example (but a physical keyboard is needed). Firefox on macOS is quite stuttery - if there's a Mozilla engineer here I'd love for you to tell me why!
reply