Writing Doom For The Raspberry Pi

Doom on Raspberry Pi

We’ve all seen Doom played on the Raspberry Pi before… but this isn’t a port of the game. No, this was a school project at the Imperial College of London — writing the game in bare assembly. They wrote it from scratch.

bare metal doom thumbnail
Complete with a custom home made controller connected directly to the GPIO pins!

Yep. There’s not even an operating system on the Pi. It’s 9800 lines of bare metal ARM assembly. If that doesn’t hurt your brain we dunno what does!

They are using the official textures from the game, and it’s not quite a perfect replica — but it’s pretty darn close.

Part of the project was to build an emulator to make it easier to test the game, but it didn’t work out the greatest — so most of the actual game development was performed on the actual hardware. Yikes!

Stick around after the break to see Doom in all its former glory. Top notch work guys!

Reminds us of running Doom on the Intel Edison…

35 thoughts on “Writing Doom For The Raspberry Pi

    1. well it must have been A LOT of work, but not that hard imho, the doom engine is very well documented and all the trigonometry math is fixed point. I think you could probably pull this off without even understanding large parts of the original code, and just reimplementing it in any other language.

  1. 0x5f3759df anyone ?

    Carmack’s “Fast Inverse Square Root” function for normalizing vectors was legendary, and still is.
    I used it in embedded applications on several occasions since the C standard library doesn’t have it.

      1. Anything made by Carmack reminds me of that function.

        Even though it has been attributed to John Carmack for as long as I can remember, the Wiki article now says “Adjustments and alterations passed through both Silicon Graphics and 3dfx Interactive”, so it seems he was not the only contributor after all.

        It is still not known how the constant was originally derived.

        1. “evil floating point bit level hacking” nice.
          This hack, though… man, only 9800 lines of assembly? I had no idea something this sophisticated could be accomplished with so “little” (still… that’s a LOT of work), nicely-done.

    1. The polluting effect of the C pre-processor. 5f3759df is not the same as 5F3759DF in many languages. And it shouldn’t be. (and 0x is not part of a number unless it is at least radix 36). You damn kids get off my lawn!

      Other than that, this is pretty cool, aside form using a Pi that is. ARM assembly code is really nice and efficient. If they didn’t use Thumb, then they got to use real ARM and conditional execution on any instruction which gets rid of tons of “if branches”. Love it.

    2. “Fast Inverse Square Root” predated Carmack, as did a number of other awesome “magic number” hacks.

      “Fast inverse square root (sometimes referred to as Fast InvSqrt() or by the hexadecimal constant 0x5f3759df) is a method of calculating x−½, the reciprocal (or multiplicative inverse) of a square root for a 32-bit floating point number in IEEE 754 floating point format. The algorithm was probably developed at Silicon Graphics in the early 1990s … The algorithm was originally attributed to John Carmack, but an investigation showed that the code had deeper roots in both the hardware and software side of computer graphics.”

      https://en.wikipedia.org/wiki/Fast_inverse_square_root

    1. That was my first thought too. But after closer examination – Wolfenstein only had perpendicular walls, didn’t have stairs, didn’t have floor/ceiling level changes. So it’s kind of closer to Doom in that regard.
      However, given they didn’t use Doom’s original map I’m suspecting this is not the true Doom engine, but a one that kind of looks like it.
      And as others said – 10K of assembly is mind blowing. Nice work.

    1. Yeah, I was just going to say the same…
      I still remember some of the code I was maintaining for an ex-employer where 150k lines of assembler was rather common. I think our biggest block (as every “program” was called) was around 300k lines but I’m sure there were bigger ones somewhere. This was all for real-time systems on custom processors. The biggest 68k stuff I’ve worked on was about 80k-ish lines of code if my memory still serves me correct.

      However – kids learning assembler today is great and I hope more do :)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.