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.
