Bringing Half-Life to the Original PS1: Inside the Making of HL-PSX

When the first footage of Half-Life running on an original PlayStation was published, it immediately became one of the most talked-about projects in the PS1 homebrew community. Seeing Black Mesa come to life on Sony's 1994 console raised countless questions: Why Half-Life? How difficult is it to fit such an ambitious game into just 2 MB of RAM? And how close is the project to becoming playable?

To answer those questions, we spoke with izzy88izzy (Bonnie Games), the developer behind both the Half-Life port and PSoXide. 

In this interview, he discusses the technical challenges of bringing Valve's classic to the PlayStation, the design decisions behind the project, the controversy surrounding AI-assisted development, and what the future holds for one of the most ambitious PS1 homebrew projects ever attempted. 

 

 

Interview with izzy88izzy, the Developer Behind HL-PSX

- I've seen that some developers have been critical of your use of AI during development. How do you feel about those criticisms, and what role do you think AI should play in game development? 

It was genuinely disheartening to see people whose work I had admired for years criticize the project so harshly, sometimes bordering on mockery, because of my use of AI throughout the development of PSoXide. 

I have been coding professionally for about eight years, so my programming experience predates the current generation of AI tools. AI did not give me the idea, define the architecture, perform the hardware tests, or take responsibility for whether the result works. I use it extensively as an accelerator for implementation, code exploration, repetitive work, debugging, and documentation, while I remain responsible for the technical direction, review, integration, and testing. I understand the legitimate concerns surrounding AI, especially provenance, low-quality generated code, and replacing human creative work. 

My preferred boundary is to use it where it enhances my ability to build and investigate, rather than using it as a replacement for an artist's creative contribution. PSoXide is completely open about its AI assistance, licensing, and the provenance of code derived from other open-source projects. I am also seeing AI used increasingly for tasks such as decompilation and reverse-engineering assistance. That demonstrates that there is a valuable place for it when it expands what a developer can investigate and create. When the Celeste Classic Collection built with PSoXide went viral, most people understood this distinction, they saw AI as an accelerator for ideas rather than the source of the ideas themselves, that is how I have approached it from the beginning. Without these tools, my long-term dream of building a PS1 Souls-like would have been much harder for one developer to pursue at this scale.

 

- Why did you choose Half-Life as the first large 3D project to showcase PSoXide?

It was not really a deliberate marketing choice. Half-Life emerged naturally from several experiments I was building with PSoXide. Those experiments included a Minecraft-style game, a Guitar Hero clone, ports of Zelda: A Link to the Past and Ocarina of Time, and even an Excel-like spreadsheet editor, which mostly existed for the joke of running a spreadsheet on a PlayStation. Half-Life was simply the most captivating experiment, and it progressed faster than I expected. Every time another system started working, it exposed the next interesting challenge, so the project kept growing. I still intend to return to and eventually release some of the other experiments. 

 

- What has surprised you the most while bringing Half-Life to the original PlayStation?

The first surprise was how well structured and elegant the original Half-Life code and data organization are. Its systems are separated clearly enough that you can study how individual behaviours fit into the complete game, even though reproducing them on completely different hardware is still an enormous challenge. The second surprise was how every part of the game introduced a different PS1 constraint. Rendering BSP levels, fitting enemies and animations into memory, streaming audio from CD, reproducing scripted sequences, sorting translucent geometry, and maintaining AI all require different compromises.  

It is never simply a matter of reducing the texture resolution and polygon count. Half-Life was designed around assumptions that are completely different from a machine with 2 MB of main RAM and 1 MB of VRAM. Real-hardware testing has also been extremely valuable. Some problems appeared only on the console, including geometry corruption and audio state issues. Every hardware discrepancy became a new test for both HL-PSX and the PSoXide emulator. 

 

- Have you ever considered contacting Valve to show them the project? I'd love to know what they would think of it.

I  actually have contacted Valve to request written clarification before making the repository public. I explained that HL-PSX is an independently written, from-the-ground-up reimplementation of Half-Life's game systems. It does not run on GoldSrc and does not redistribute Valve's source code or compiled engine. Valve's official source release was consulted as a behavioural and compatibility reference, while the new implementation was written in Rust for PSoXide. 

I also explained that PSoXide is GPL-licensed and contains no proprietary Sony SDK, PlayStation BIOS, licensed Sony boot data, or Sony-authored code. The proposed distribution model is source-only and bring-your-own-assets. Users would need a legitimate Steam or retail copy of Half-Life, and the Rust tooling would convert their assets locally. I do not intend to distribute Valve's assets, finished disc images, or physical copies. I have asked Valve whether this model is acceptable, whether users may create personal PS1-compatible builds from their own installations, and what naming, trademark, or disclaimer requirements they would prefer. The repository will remain private while I clarify those boundaries. I would also love to know what Valve thinks of the project from a technical perspective. 

 

- The game already includes NPCs, weapons, AI and HUD. Which system are you most proud of implementing so far?

Probably the level traversal and asset-streaming system. Half-Life's campaign is much too large to remain resident in PS1 memory. The port divides the cooked game data into compressed chunks and uses an asset manager to load only the maps, textures, dialogue, enemies, models, and animations required by the current area. The build process audits all 96 maps and their level transitions before creating the disc. It checks the worst-case resident set, including the assets that must survive a transition while the next area is loading. If a combination cannot fit, the build fails rather than allowing a random crash later. Getting that to work within 2 MB of RAM, while keeping transitions bearable from the original CD drive, is probably the clearest example of what PSoXide was built to enable. 

 

- You mentioned the game currently runs at around 10–15 FPS. Where do you think most of the future performance gains will come from?

The profiling shows that game logic itself is not the largest cost. Most of the remaining frame time is spent processing actor and brush models, rendering the first-person weapon, and submitting or drawing geometry through the GPU. Large outdoor areas also become fill-rate and overdraw limited. The largest gains should come from rejecting work earlier. That means stronger use of BSP visibility, frustum and occlusion culling, avoiding transforms for hidden actors, caching static packet streams, batching model work around the GTE, and reducing unnecessary overdraw without making the fog too aggressive or causing visible geometry to disappear. 

The new compact model and animation format also groups vertices by bone so the GTE matrix changes less frequently. Viewmodels are another important target because they are always visible and surprisingly expensive relative to the rest of the frame. Some deterministic test scenes already meet the 20 FPS budget, but the goal is a reliable 20 FPS throughout the campaign, including demanding scenes and real hardware. I do not want to reach that number by simply destroying visibility or visual quality, so every optimization is checked through deterministic captures and testing on the console.  

 

-Apart from performance optimizations, what major features are still missing before you consider the project ready for a public release?

The biggest task is ensuring the campaign is genuinely playable from beginning to end, rather than having individual maps and systems that work in isolation. Enemy AI and shooting still need refinement. 

Half-Life also has a very rich animation system, and reproducing it within the available memory is difficult. I am using a compact bone-palette format that retains selected source poses and reconstructs the motion through fixed-point interpolation, rather than storing every fully baked frame. The goal is to save RAM without making NPC or weapon movement look robotic. The trigger and scripted-event system is another major area. Half-Life's interconnected triggers, conversations, doors, trains, scripted sequences, and environmental events are a huge part of what made it feel cinematic. Those systems need systematic comparison against the original game. 

There is also further work required on weapon behaviour, reload animations, audio continuity across map transitions, enemy animation coverage, water physics, and real-hardware reliability. Before release, I want deterministic campaign tests that can identify where the reimplementation diverges from the original. 

 

- Has working on Half-Life changed PSoXide itself? Have you added features or optimizations that you wouldn't have considered otherwise?

Drastically. Half-Life exposed emulator and hardware-behaviour flaws that never appeared while working on the Celeste collection or my original Souls-like project, Cortex Ignition. Every discrepancy found on real hardware led to a focused hardware test. The result would improve the emulator, which would then expose another smaller inconsistency. 

One of the challenges was reliably getting detailed diagnostic information back from an original PlayStation. There is no convenient modern debugging connection available when testing an ordinary burned disc, so I devised a QR-based hardware telemetry system. The test software collects hardware readings, timing information, checksums, and failure details, then displays the structured result as QR codes on the television. Those codes can be photographed or captured and imported back into my development environment, that gives me a reliable bridge between real silicon and the emulator.

Instead of trying to interpret a visual glitch by eye, I can retrieve exact readings from the console, compare them against PSoXide, adjust the emulation, and repeat the same test deterministically. This process has improved areas such as GPU and GTE behaviour, CD-ROM streaming, audio timing, profiling, hardware diagnostics, and the reliability of the SDK and engine. The optimizations required to fit Half-Life into 2 MB of RAM are also directly influencing Cortex Ignition. The compressed asset formats, streaming architecture, visibility systems, fixed-point animation work, and memory-auditing tools are all improvements that original PSoXide games can benefit from. Half-Life has effectively become both a game project and a very demanding validation suite for the entire PSoXide stack. 

 

- Why did you decide that users will need their own Steam copy of Half-Life instead of distributing a ready-made image?

Because the maps, models, textures, sounds, dialogue, music, and visual identity belong to Valve and the original creators. I want to respect that work and avoid redistributing licensed assets. HL-PSX provides the independently written implementation and the means to play the game on different hardware. It does not provide the game content itself. 

The goal is for someone with only Rust and a legitimate Half-Life installation to run one command. The tooling validates the installation, converts the assets locally, compiles the PS1 executable, and creates a personal disc image. Those converted assets and the resulting image remain on that user's machine. 

 

- Once the project becomes open source, what would you like other developers to build or learn from it?

I hope it demonstrates that PSoXide can be taken seriously as a complete development environment, not only for small demos but also for complex games capable of pushing the PlayStation hardware to its limits. I would love developers to study the Rust-only asset pipeline, memory auditing, BSP conversion, CD streaming, fixed-point rendering, animation compression, deterministic regression testing, and the way the game is validated against both an emulator and original hardware. 

Developers certainly do not need to make another port, although I would absolutely encourage them if that is what interests them. Ports are fantastic stress tests because they force the hardware and toolchain to confront systems designed without the PS1's limitations in mind. The most exciting outcome would still be seeing people apply those techniques to completely original PS1 projects that previously felt too difficult or too time-consuming to attempt. 

 

- How do you feel about the current state of the PS1 homebrew scene? It seems to be growing faster than ever.

It is astonishing how quickly the PS1 homebrew scene is growing. There are more accessible tools, documentation, hardware tests, and developers sharing knowledge than ever before. A big shout-out goes to PSX-Splash, which has helped democratize PS1 development through its Unity integration and significantly lower entry point. 

I see PSX-Splash and PSoXide coexisting very naturally because they serve opposite ends of the development spectrum, PSX-Splash makes it much easier for developers already familiar with Unity to begin creating something for the PlayStation. PSoXide is aimed more at developers who want deeper control, larger projects, complex ports, and the ability to push the hardware as far as possible through an integrated Rust SDK, engine, editor, emulator, debugger, profiler, and build pipeline. They are complementary rather than competing approaches. 

One makes the platform more accessible, while the other focuses on giving ambitious projects the low-level control and specialized tooling they need. Between them and the other established PS1 toolchains, I think the scene is as strong and approachable as it has ever been. 

 

- You mentioned that your projects are written in Rust. What made you choose Rust over C or C++? 

Choosing Rust was actually one of the main driving ideas behind PSoXide. I wanted to see whether a complete, modern development environment for the original PlayStation could be built around Rust instead of recreating the traditional C or C++ workflow. One major advantage is cross-compilation. The PS1 software is compiled as bare-metal, no_std Rust for the mipsel-sony-psx target, while the editor, emulator, debugger, and asset tools compile natively for my ARM64 Mac. The same host code can also target Windows, Linux, and even WebAssembly for the browser version of the emulator. 

Rust gives me one language and one ecosystem across all of those very different environments. Cargo is a huge part of that. It handles dependencies, feature flags, build profiles, tests, and target selection in a consistent way, developers do not have to manually coordinate several unrelated build systems or invoke a chain of external tools. Rust is also low-level enough for the kind of aggressive optimization the PlayStation requires. There is no garbage collector or mandatory runtime, and I can directly control memory layouts, fixed-point arithmetic, hardware registers, DMA packets, inline assembly, and volatile memory access. 

At the same time, Rust’s type system and ownership model help catch many buffer, lifetime, and state-management errors before they reach the console. That is especially valuable when working with only 2 MB of RAM, where a small memory mistake can corrupt an entirely unrelated system. One of the greatest benefits, which I think is often overlooked, is how much code can be shared across the complete stack. For example, the emulator and SDK use the same Rust crate for hardware register definitions and GPU packet layouts. The editor and PS1 runtime share the same cooked-asset format definitions, so the tool producing an asset and the code consuming it cannot quietly disagree about its layout. 

The GTE implementation, fixed-point types, and transformation mathematics can also be shared or tested on the host before being used on the console. Rust’s no_std support and conditional compilation make this possible without bringing desktop dependencies into the PS1 binary. That cohesion is what enabled PSoXide’s single-stack architecture: emulator, debugger, SDK, engine, editor, asset pipeline, and disc-building tools all belong to the same Rust ecosystem and can reuse the same crates and data contracts. The editor can cook a project, compile it for the PS1, build a disc image, boot it in the embedded emulator, and display the running game in its viewport as one connected operation. C and C++ are absolutely capable of producing excellent PS1 software, and several mature toolchains already prove that. 

For me, Rust’s biggest advantage is not simply performance or memory safety in isolation. It is that Rust and Cargo made it practical to treat the entire development environment as one integrated product instead of a collection of disconnected tools. I believe that integration is PSoXide’s most important and most frequently overlooked strength.  

---

Half-Life PSX is still a long way from completion, but the progress shown so far already demonstrates what modern homebrew development can achieve on the original PlayStation. Beyond recreating one of PC gaming's most influential titles, the project is also driving new tools, techniques, and research that could benefit future PS1 developers.

Whether Half-Life eventually reaches the finish line or not, it has already secured its place as one of the most technically ambitious projects the PlayStation homebrew scene has ever seen. And if the pace of development continues, the dream of exploring Black Mesa on an original PS1 may be closer than anyone expected.

You can follow Bonnie Studios and keep up with their latest projects through their official channels. Check out their games on itch.io, follow them on Twitter (X) and Instagram for development updates, or support their work through Buy Me a Coffee.

Make sure to support indie developers like Bonnie Studios and discover more unique projects from the homebrew community. 

Don't forget you can follow us on Twitter (X), browse our game collection on Itch.io, join our Reddit community, and watch gameplay videos on our YouTube channel!