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!
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!