Portal 64: Still Alive is a Portal demake that will not ship a ROM

A demake, defined, with a legal constraint built into it

The project defines its own term in the first line of the README. A demake, it says, is a remake for an older platform. The subject is Valve's Portal, and the target is the Nintendo 64. The primary language is C, the licence is MIT, the default branch is master, and the last push was on 2026-10-20, with releases v0.16.0, v0.17.0 and v0.18.0 published in 2024, 2025 and 2026.

What makes this project different from an ordinary fan remake is the constraint it has accepted on itself. The repository contains no material owned by Nintendo, but Nintendo's tools are currently required to build the game, and no form of compiled ROM will be distributed while that dependency is in place, because the built game would contain Nintendo's intellectual property.

The asset story is equally clear. Game assets from Portal are sourced from the original game's files, which must be supplied separately at build time. The repository cannot be used to compile the game without legally owning Portal and providing its files, and legal ownership is required regardless of any tool or library changes. The README links the store page for buying it.

So the design is: a source tree, a build environment, and an instruction to bring your own game. What you get is the reconstruction, not the content. The project is also explicit that it is not affiliated with Nintendo or Valve.

The original repository was taken down at Valve's request

The history section of the README explains why this repository is a fork rather than the original, and the reason is the interesting part of the story.

The project was originally created by James Lambert. The README says the original repository was taken down by James at Valve's request, due to the build requirement on Nintendo's proprietary libultra and its consequent inclusion in ROM files. The stated reason for the takedown is the same legal concern the fork still has to deal with: the proprietary library ended up inside the built ROM.

The fork keeps the history. The original branch contains the version history of the original repository, and active development happens in the master branch. That split is a nice piece of bookkeeping, because a reader who wants to see how the project handled the takedown can diff the two branches and see exactly what the fork changed in the build system.

The fork declares two main goals, and they are listed plainly. The first is to remove the proprietary code requirement, with a pointer to the N64 library usage documentation. The second is to finish development of the game, with a pointer to the development progress document in the documentation folder.

That second goal is the honest framing of the project's maturity. The work is not a finished game with a few rough edges, it is a game in progress with a specific list of remaining work, and the repository is explicit that it welcomes game testers and contributors.

Eighteen chambers, working portals and a physics engine

The README's overview is unusually concrete about what exists, which makes it easy to judge how far along the project really is. It aims to reproduce Valve's original Portal, playable on the N64, and it says that because the demake has been in development for some time, it has made significant progress in both gameplay systems and fidelity.

The list is specific. Eighteen test chambers are completed. The portals work, and so does the gun. There is a fully functioning physics engine and a lighting system. There are main and pause menus. Sound effects and dialogue are there, along with cutscenes. Multi-language subtitles and audio dialogue are supported. There is what the README calls eye candy, with reflections as the example.

Eighteen chambers is a substantial amount of Portal. The original game's opening sequence is famously twenty chambers, and the later sets reuse and remix the earlier ones, so a demake that has completed eighteen has covered the bulk of what a player sees in a first playthrough.

The platform constraint is the real reason the fidelity list is short. A 1996 console has a fraction of the geometry, the texture memory and the polygon budget of the game being recreated, so the work is not a port but a translation of the design into limits the original never had. The lighting system and the reflections in particular are the kind of feature that on real hardware would be the first thing to be cut, and their presence in the list says the author is building to the original's design intent rather than to what the hardware makes easy.

Building it requires your own game files and a Linux toolchain

The build instructions are four steps, and the second one is the one that stops most people.

First, get the code:

git clone https://github.com/mwpenny/portal64-still-alive.git portal64

Second, provide the game files. You must supply your own legally obtained Portal game files so the assets can be extracted and used, and the instructions for that are in the vpk/README.md file in the repository.

Third, install the dependencies, and there are two supported routes. The Docker route is recommended if you do not want system wide changes or you are unfamiliar with Linux, and the native route applies if you are using a virtual machine or the Windows Subsystem for Linux. The instructions live in the documentation folder under building, with docker_setup.md and native_setup.md.

Fourth, build the game, following the instructions in the building documentation.

There is a hardware note at the end, and it is the kind of detail that only shows up when someone actually put the game on a cartridge. To run and save properly, the game expects a cartridge with 32 KB of SRAM. The Nintendo 64 cartridge format had several SRAM variants, and this one needs a specific amount for the save file, so an emulator on your desktop will not exercise that path.

The repository structure supports this workflow. There is an asm/ directory for assembly, a src/ directory, a linker/ directory, a cmake/ directory and a CMakeLists.txt, a skeletool64/ directory for the tool that fixes up an ELF into a ROM, a vpk/ directory for the asset extraction step, assets/, tools/ for the asset conversion tools, documentation/, and a version.txt.

The Dockerfile shows the real shape of the toolchain

The container image is the clearest statement of what building this involves, and it is a long list.

The base is ubuntu:24.04, and the work happens in /usr/src/app. The environment sets up three paths, one for the crash SDK binaries, one for the local user binaries, and ROOT pointing at /etc/n64, which is where the N64 toolchain expects to find itself.

The apt sources list is added as trusted, for two repositories, one hosted by the original author and one for the N64 SDK. The package list then installs the cross compiler and the SDK, gcc-mips-n64, binutils-mips-n64 and newlib-mips-n64 for the target, build-essential, cmake, ninja-build and git for the host, a long set of image and media libraries including cimg-dev, libassimp-dev, libpng-dev, libtiff-dev, libyaml-cpp-dev and liblua5.4-dev, and a set of tools specific to the asset pipeline: makemask, sfz2n64, vtf2png, imagemagick and ffmpeg. Python comes with pip and pipx, and nodejs is there too.

Then the image installs Blender 3.6.1 by downloading the release archive from download.blender.org and putting it on the path, and finally installs the vpk tool through pipx, which is the Valve Package Kit tool that handles the asset extraction step.

Two details are worth pausing on. The vpk tool is installed separately with pipx, and it is the piece that reads the game's own asset archives, which is why supplying your own Portal files is a build input rather than a convenience. And Blender being in the image is a strong hint about the art pipeline, because Blender is a general 3D tool and not a game engine: the assets in this demake are being processed through it, which is a different approach from extracting and reformatting the original models directly.

The legal design is the project's real differentiator

It is worth being clear that this project made a choice that most fan projects do not make, because the choice shapes everything else about it.

The usual approach to a demake of a commercial game is to distribute a built artefact, because the audience wants something that runs. This project instead declines to distribute any compiled ROM while the proprietary build dependency exists, on the grounds that the built game would contain Nintendo's intellectual property. It also asks the builder to own the game and to supply their own files, and it states that legal ownership will be required regardless of any tool or library changes.

The consequence is that the project cannot be consumed the way most software is. You cannot install it and run it. You clone a source tree, extract assets from your own copy of the game with a tool that reads Valve's package format, set up a cross compilation environment for MIPS, and build. The result is a ROM you keep for yourself.

That is a real cost in convenience, and the project accepts it, with the first stated goal being to remove the proprietary code requirement so that the situation can change. A build that no longer links Nintendo's library would remove the objection to distribution.

For an evaluation, the practical questions are therefore about the toolchain rather than the game. Can you install a MIPS cross toolchain and a proprietary SDK, or would you use the Docker image, which is the route the README recommends for anyone who does not want system wide changes. Are you comfortable with a build that depends on apt repositories hosted by individual people. And can you accept that a project at version 0.18.0, with a development progress document and an open call for testers, will change under you as the second goal, finishing the game, is pursued.

Editorial conclusion

Adopt portal64-still-alive if you own Portal, you want to see a physics based first person puzzler rebuilt for 1996 hardware constraints, and you are prepared to supply the SDK and a build environment. Do not adopt it expecting a finished game, since the README lists the work still ahead and the artefact is a source tree rather than a release, and do not expect a ready made ROM, because the project deliberately does not distribute one. Before you start, read the disclaimer and the N64 libraries documentation, check the development progress page for what is actually implemented, and confirm you can provide your legally obtained Portal files for the asset extraction step.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mwpenny/portal64-still-alive on GitHub
4. README
5. Releases