4 ms·

Porting old games to the web is fun! Many are smaller than a typical modern webpage. They load fast and run great. I just ported Quake 3 and I'm having some fu

Porting old games to the web is fun! Many are smaller than a typical modern webpage. They load fast and run great. I just ported Quake 3 and I'm having some fun with it: https://thelongestyard.link/ https://thelongestyard.link/

geuis 2y ago
That was a lot of fun and a blast from the past. Thanks for porting that.
- modeless 2y ago
  Thanks! This is loading just the demo assets, but I got the Emscripten support merged into upstream ioquake3 so you can check out the code, build it yourself, and with the right game asset files you can play the full game, Team Arena, mods, or whatever. https://github.com/ioquake/ioq3/pull/658 https://github.com/ioquake/ioq3/pull/658 The only major feature missing from the original game is networking. Obviously kind of important for Quake 3. Should be possible with WebRTC DataChannel. And while the original game didn't have it, for the modern web a touchscreen control scheme is essential since half of everyone is on their phone. Of course it won't be great compared to mouse/keyboard but some mobile support is better than none. So those are the two features I'd like to add (besides performance optimizations; it's a bit slower than it should be for some reason).
  - hauxir 2y ago
    check out https://openarena.live https://openarena.live its open arena running on humblenet which does take advantage of webrtc/p2p
Jyaif 2y ago
That input latency is why I hate browsers when making games. Great job though!
- DonHopkins 2y ago
  If you refactor and structure your code in the right way, you can get it to perform pretty well. What will kill you is stacking up layers of emulation, so you're feeding browser input into a Windows or Mac emulation layer, and even an x86 instruction set emulator, plus a useless obsolete operating system "middle ware", because the way input and animation works on old desktop guis is a lot different and much less efficient that how it works in the browser. It's certainly possible to run the original version of Mac or Windows SimCity in the browser inside a Mac or Windows emulator inside a WebAssembly module, but not only is the user interface itself terrible, klunky, and awkward, it's extremely slow and flakey because it's emulating all that obsolete operating system crap and instruction set underneath all the web browser crap between your mouse clicks and the game engine. Since the web browser is so much better and more flexible at user interface and graphics stuff, you want to totally strip all of the user interface and graphics and sound out of the game, implement an efficient API and callback mechanism (that doesn't spend a lot of time thunking and marshalling and unmarshalling parameters, and pass simple primitive data types, sending what you need all at once, instead of ping-ponging back and forth with proxy objects), and implement all of the UI in the browser (especially the animation timers and input handlers), calling back to the simulator only when necessary. One thing I did was to use shared memory between the WebAssembly module and the WebGL tile renderer, and write a custom shader that understands the native 16 bit unsigned int column major SimCity tile format, so WebGL only has to draw two triangles, and there is zero copying to draw the tiles.
  - pton_xd 2y ago
    > and implement all of the UI in the browser (especially the animation timers and input handlers) I may have misunderstood you, but in my experience using the DOM for UI is a bad idea if performance is a concern. DOM updates in the browser are incredibly slow, especially for something like a game which wants to modify UI elements every frame. Meticulously avoiding relayouts, style recalculations, and other slowdowns is a constant headache. EDIT: run a few second performance profile of your site. Now do it again while waving the mouse back and forth over the UI links. Notice all the recalculate style and hit test calls that take more time than your entire WASM update! And that's with a UI that's doing nothing!
noxa 2y ago
my favorite map too :)
langarus 2y ago
really love this. Where would one start in order to get better at this? Mainly porting old games to wasm
- modeless 2y ago
  Thanks! Emscripten is the tool that makes it relatively easy, for stuff with source code available. So I'd say pick something and try to build it with Emscripten. For stuff without source code you'll have to use emulation. DOSBox and MAME have web ports already. I haven't looked into them much. But the Internet Archive has a big collection of games that run in them already. So check that to see if the game you want is already available.

geuis 2y ago

That was a lot of fun and a blast from the past. Thanks for porting that.

modeless 2y ago
Thanks! This is loading just the demo assets, but I got the Emscripten support merged into upstream ioquake3 so you can check out the code, build it yourself, and with the right game asset files you can play the full game, Team Arena, mods, or whatever. https://github.com/ioquake/ioq3/pull/658 https://github.com/ioquake/ioq3/pull/658 The only major feature missing from the original game is networking. Obviously kind of important for Quake 3. Should be possible with WebRTC DataChannel. And while the original game didn't have it, for the modern web a touchscreen control scheme is essential since half of everyone is on their phone. Of course it won't be great compared to mouse/keyboard but some mobile support is better than none. So those are the two features I'd like to add (besides performance optimizations; it's a bit slower than it should be for some reason).
- hauxir 2y ago
  check out https://openarena.live https://openarena.live its open arena running on humblenet which does take advantage of webrtc/p2p

Jyaif 2y ago

That input latency is why I hate browsers when making games. Great job though!

DonHopkins 2y ago
If you refactor and structure your code in the right way, you can get it to perform pretty well. What will kill you is stacking up layers of emulation, so you're feeding browser input into a Windows or Mac emulation layer, and even an x86 instruction set emulator, plus a useless obsolete operating system "middle ware", because the way input and animation works on old desktop guis is a lot different and much less efficient that how it works in the browser. It's certainly possible to run the original version of Mac or Windows SimCity in the browser inside a Mac or Windows emulator inside a WebAssembly module, but not only is the user interface itself terrible, klunky, and awkward, it's extremely slow and flakey because it's emulating all that obsolete operating system crap and instruction set underneath all the web browser crap between your mouse clicks and the game engine. Since the web browser is so much better and more flexible at user interface and graphics stuff, you want to totally strip all of the user interface and graphics and sound out of the game, implement an efficient API and callback mechanism (that doesn't spend a lot of time thunking and marshalling and unmarshalling parameters, and pass simple primitive data types, sending what you need all at once, instead of ping-ponging back and forth with proxy objects), and implement all of the UI in the browser (especially the animation timers and input handlers), calling back to the simulator only when necessary. One thing I did was to use shared memory between the WebAssembly module and the WebGL tile renderer, and write a custom shader that understands the native 16 bit unsigned int column major SimCity tile format, so WebGL only has to draw two triangles, and there is zero copying to draw the tiles.
- pton_xd 2y ago
  > and implement all of the UI in the browser (especially the animation timers and input handlers) I may have misunderstood you, but in my experience using the DOM for UI is a bad idea if performance is a concern. DOM updates in the browser are incredibly slow, especially for something like a game which wants to modify UI elements every frame. Meticulously avoiding relayouts, style recalculations, and other slowdowns is a constant headache. EDIT: run a few second performance profile of your site. Now do it again while waving the mouse back and forth over the UI links. Notice all the recalculate style and hit test calls that take more time than your entire WASM update! And that's with a UI that's doing nothing!

noxa 2y ago

my favorite map too :)

langarus 2y ago

really love this. Where would one start in order to get better at this? Mainly porting old games to wasm

modeless 2y ago
Thanks! Emscripten is the tool that makes it relatively easy, for stuff with source code available. So I'd say pick something and try to build it with Emscripten. For stuff without source code you'll have to use emulation. DOSBox and MAME have web ports already. I haven't looked into them much. But the Internet Archive has a big collection of games that run in them already. So check that to see if the game you want is already available.