Label on HF32

Label on HF32

Test Chamber is a new (2025) puzzle homebrew for VB. It’s a first-person puzzler similar to games like Portal or The Talos Principle.

ROM Download

Trailer

Gallery
Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot

Features

  • 10 courses
  • 3D technology specifically built to leverage the Virtual Boy’s unique hardware
  • Rumble Pak support
  • Original score

Requirements

  • Virtual Boy with 4MByte flash cart, or:
  • A compatible emulator, such as Lemur.
    • Note that many popular emulators (such as Mednafen) have inaccuracies that will result in graphical glitches or erratic behavior when running this title. See the FAQ for more information.

FAQ

  • Is there a version for 2MB flash carts?
    • No, it was already difficult to get it to fit within 4MB.
  • Will there be a physical release?
    • There has been more interest in this than I expected for a free game, so I’m now considering it. Perhaps in the future I’ll fix all of the known bugs, add a few bonus chambers and release a delux edition as a physical cartridge.
    • Note that any physical releases being sold at this time are unauthorized.
  • What emulators have been tested?
    • Lemur (which I highly recommend for PC hosts) has no issues.
    • Red Viper (Nintendo 3DS) v1.3.0 (released 2026-05-03) fully supports Test Chamber on all 3DS variants. Older versions of Red Viper may encounter error VIP_OUTPUT_UNREADABLE and walls will appear semi-transparent as a result.
    • Mednafen throws the BAD_MPYHW error code and exhibits major graphical issues.
    • VirtualFriend (iOS) cannot boot the game, but I’ve submitted a patch to fix that issue. Still, due to the inaccurate way that interrupts are implemented, the walls constantly flicker while playing.
    • Virtual Virtual Boy (Android) seems to work aside from the audio aliasing issues that seem to persist for all games.
    • Slow VB works as expected (no issues but unplayably slow).
  • Error Codes
    • BAD_MPYHW - Your emulator (likely Mednafen or a derivative thereof) doesn’t properly implement the mpyhw instruction. This usually manifests as floors glitching out, but this instruction is used all over the place so it may just crash.
    • VIP_OUTPUT_UNREADABLE - Your emulator doesn’t make hardware-rendered framebuffer data available to the CPU.
      • If you are experiencing this on Red Viper (the 3DS-hosted emulator), this manifests as transparent walls. The developer is already looking into ways to mitigate, so make sure your emulator is updated.
  • Known bugs
    • Some players have reported that you can lock the game up by toggling full resolution on and off via the Select button.
    • On Test Chamber 4 (the “lava pit”), you can peer into one end of the quantum tunnel and clip through the wall to see the lava below. This is confusing for players since it distracts from the actual puzzle solution.
    • You can get pushed out of the world boundaries by the exterior door closing while trying to solve the airlock puzzle towards the end of the game. This was intended to kill the player but sometimes that doesn’t occur and you can just walk around without being able to re-enter the level, forcing you to restart the chamber from the menu.

Technology

Overview

This game uses a custom 3D engine that relies the Virtual Boy’s unique abilities to draw frames at playable speeds. I plan to create a blog post or perhaps a video explaining the engine in depth some day, but at a high level, the engine parallelizes drawing by having the VIP (VB’s GPU) draw textured floors and ceilings while the CPU prepares draw lists for the walls. Once the floors and ceilings are done, the engine leverages some unique CPU capabilities to quickly copy the walls onto the frame.

Level Data

Chambers are divided into sectors, and each sector is a convex 2D polygon where each edge represents a wall. Walls have a top and a bottom, and either part (but not both) can be an edge to another sector (denoting an exit). Such edges have a world transform associated with it, allowing sectors to connect to other sectors which may not actually be spatially colocated (this is how portals are implemented). Self-referential edges are also allowed. Walls are always flush with the floor and ceiling of the sector, and the height of the walls is determined by the height of the sector.

Drawing

The scene is drawn front to back, traversing through edges to other sectors when an exit is encountered by applying the inverse transform to the current view matrix. It sweeps right to left across the sector and adds wall slices to the draw list. Because walls span floor to ceiling, the rasterizer only considers vertical columns that weren’t completely filled in (due to the wall having a top or bottom that exits to another sector) as it traverses until there are no more columns that haven’t been drawn.

This is similar to how DOOM draws, and the engine has some of the same constraints that DOOM has (walls are always perpendicular to the ground, the camera can’t be tilted*, the floor can’t have hills). Rather than using a BSP, the engine simply remembers which sector that objects were in during the last frame and begins a BFS starting in that sector to find where it went if it’s no longer there.