Fly through Wipeout tracks in your browser

Reverse Engineering WipEout

With all the work that went into this project, handling the WebGL drawing with three.js turned out to be one of the simplest parts.

The finished WipEout Model Viewer loads all the original data files and does all the binary file reading, unpacking and scene creation in JavaScript.

All in all, I wrote about 800 lines of JavaScript to load and draw 3D scenes for a 20 year old game. I wonder how big the original WipEout sorurce is. It's quite sad that probably nobody will ever see it again, considering that it now belongs to Sony.

Having a hard time accepting what I see my web browser doing right now!

Previously, previously, previously.

Tags: , ,

14 Responses:

  1. k3ninho says:

    Is this coming to xscreensaver?

  2. really nice
    makes me wonder why we don't see more webgl-games :-)

    btw: your comment-form is broken. if i try to comment without openid it gives me a xrds-file as download and on second try it forwards me to openid-auth.

  3. It clips just a little (and slightly differently in different browsers), but that's so minor in the face of HOLY CRAP THIS IS SO GODDAMNED AMAZING. The moment it loaded and I was running Altima VII in Safari, my brain just broke.

    …And on mobile Safari (iOS 8.3 on a 5s), it's gorgeously smooth.

    • This is one of the neat things about WebGL--you can offload most of the work to the GPU. I was actually just fixing WebGL support in Gecko on a mobile device the other day, and I ran some demos in a debug build with optimizations disabled and they still ran at 60fps because they were just all GPU.

  4. David Konerding says:

    Reading the reverse engineering document is sort of like watching a middle-ages monk transliterating an arabic work of science into a gilded manuscript.

    Seeing it run on a browser is sort of like reading about Starfish Prime. There were things humans were Not Meant To Do.

  5. Dan says:

    As one of the early authors of Netscape, did you ever foresee that browsers would become so ubiquitous, or so capable?

    • jwz says:

      Sure.

      There was a VRML plugin from day one. It was slow, kind of useless and non-ubiquitous, but you could zoom around 3D scenes in-browser back in 1994. If anybody had really cared about it, it would have advanced farther and sooner, but it was inevitable.

      I was surprised by how quickly Javascript, a client-side interpreted language, became fast enough to do full CPU-level emulation of video games well enough to actually play them, but again, that's just attention, timing and Moore's Law. Quantitative differences, not qualitative.

      • db48x says:

        And a dose of the Church-Turing thesis.

      • Nate says:

        In a way, the Java plug-in sent us down a rat hole and delayed true browser applications by about 8 years (1996 -> 2004 XHR and Google Maps, not to mention ActiveX). Java itself was a dog until the HotSpot VM, and then the concepts were brought to JS with TraceMonkey and V8 in 2008.

        What's really sad is to see new languages like Clojure hamstringing themselves by targeting the JVM, simply because they don't have a low-level hacker to build them their own performant VM.

  6. mattyj says:

    Impressive. I'd like to see this for SSX Tricky or any Tony Hawk game.