Boxedwine as a path to running Tribes 2 in a web browser
Two months ago the Boxedwine project (https://github.com/danoon2/Boxedwine) came on my radar (after it was posted to Hacker News). It's a combination of a new emulator for 32-bit Intel x86 CPUs (of the Pentium 3 vintage), a Linux shim layer (ELF loader & partial system call implementation), and Linux builds of the Wine project (stock-ish 5.0) that can run on Windows, Mac OS, Linux, and also in the browser (via Emscripten toolchain).
It's borderline insane, but in short, it's a way to run unmodified Windows applications that supports standard web browsers. It piqued my interest, because it creates a path to being able to run Tribes 2 in the browser without installation, and creates a sustainable method of running the game as computers rapidly lose compatibility with early 2000s 3D games (modern GPU drivers on Windows isn't even a sure thing for this game anymore). With some extra work, this can even include multiplayer, as well as single-click URLs to join games.
However, I do want to temper expectations, because this won't be ready to fly any time soon. I built a version of this for my MacBook (Air Mid-2020 Intel), and have some findings.
- Installation from the stock GSI "just works"
- Launching the game (in LAN mode) also mostly "just works"
- Switching graphics resolution, window size, and such seems table
- I was able to load a training mission and get in game
- No crashes except when closing the game
- Graphical glitches, specifically vertex errors (texturing looks fine)
- Sound, garbled; I turned it off as quickly as I could
- File reading/writing is extremely and abnormally slow (loading the training mission took over 10 minutes, and installing the game itself took about 25-30 minutes from the GSI)
- (The real kicker) performance was atrocious at about 0.4-0.7 frames per second in game
My intuition is that the frame rate is somehow tied to the way the game polls the mouse input device when in game, since I'm getting between 30 and 60 frames per second in the game UIs, and not from the compute requirements of game logic or the rendering pipeline. I remember that T2 always had a tendency to spin-loop a full CPU core, rather than yielding when done for a game tick -- this might be especially bad when using this CPU emulator, and could be resolvable by additional patches to the game.
As a silver lining, though, my Mac build of Boxedwine used the slowest emulator mode (interpreter; no JIT), which I guess shouldn't be too far off from the possible WebAssembly performance (which might be only 10-20% slower).
I've attached a few screen shots from my experiment this evening.
Installing the game via the Wine-provided Explorer clone:
OpenGL and extensions as the game saw them on first launch:
Loading Training Mission 3:
In game, with graphical glitches:
Console showing how bad the frame rate is in game:
Not too terrible FPS in UIs:
Broadly, this is the list of action items that would have to be solved for this to ever get off the ground:
- Test the game in Boxedwine on a non-Mac to see if the graphical glitches are just down to Apple's garbage OpenGL driver [Easy]
- Hack the game so that it yields the CPU when it is done with its work for a tick, rather than it spinning at full speed (and any other work on perf-counter/etc. to make it work better under the Pentium 3 emulator) [Hard]
- Get Boxedwine to support legacy OpenGL 1.x (fixed-function pipeline) graphics in the browser (WebGL is based on OpenGL ES 2.0+, which is programmable pipelines only) [Hard]
- Try running the game in a browser Boxedwine build [Easy?]
- Build networking shim for the browser build (translate connections made by the game in emulation to WebSocket and/or WebRTC APIs so it can talk to game servers and TribesNext services) [Medium]
- Build a companion app to run along side T2 servers so that browser clients can connect (WebSocket and/or WebRTC proxy) [Medium]
Would be cool if we could get it working. Those two "Hard" items are quite brutal though.