Wizball Remake — Legacy C++ Revival

Getting an Anbernic RG40XX-H prompted the project. I wanted to play Graham Goring’s Retrospec remake of Wizball on it, rather than an emulated version of the original Commodore 64 game.

The remake was developed in 2006–2007, but by 2026 its source appeared to have been lost. After I contacted Graham, he reached out to Peter Hull, who had worked on the Mac conversion. Peter still had a surviving copy, including the Mac project material.

The archive contained Visual Studio and early Xcode projects, bundled libraries and generated game data. Its runtime depended on Allegro 4, AllegroGL, desktop OpenGL and older FMOD APIs. The initial work established how the engine and data fitted together and brought up a working Linux baseline.

The original game logic, scripting system and creative content provided the foundation for the revival. Modernisation concentrated on the platform dependencies and runtime assumptions that prevented the remake from working reliably on current hardware.

SDL2 was chosen as a cross-platform foundation with support for desktop systems and a possible Android version. Window management, input, timing and rendering moved behind a platform boundary, with SDL_image handling image loading and SDL_mixer replacing the legacy audio path.

The initial SDL rendering path worked well on the desktop but was too slow on the handheld. Reviewing the alternatives led to a direct OpenGL ES 2.0 renderer, supported by PortMaster. Draw batching, texture handling, scaling and viewport behaviour were adapted for the device, while the conventional SDL renderer remained available for desktop use.

Testing on the RG40XX-H guided that work. A functioning renderer was an intermediate result; acceptable performance had to be established through actual gameplay on the handheld.

The platform boundary also supported the later Android version, which builds the native engine through Gradle and the NDK, uses the GLES2 renderer and adds a touch-control overlay.

A game of Wizball can occupy a long session, while handheld play is often interrupted. Save-and-continue was added so a run could be stopped and resumed later without losing progress.

Restoring a run required corrections to entity state and bonus-stage behaviour. Saving also needed to be quick enough to use comfortably on the handheld. Removing unnecessary work from the save and load path made the feature practical for short sessions.

Gameplay testing exposed assumptions elsewhere in the recovered engine: asset-name case differences, incomplete resource loads, unchecked references and input or simulation behaviour coupled to display refresh. A portal failure was traced to its frame-zero state being indistinguishable from an uninitialised value.

Diagnostic logging, defensive loading, explicit validation and a sanitizer-enabled build configuration supported investigation. Repeated desktop and handheld play provided the evidence that changes worked in the game, alongside source review and build checks.

A release needed both the executable and a dependable route from source assets to packaged game data. CMake defines the native builds, while the game’s existing data-generation modes run headlessly to rebuild scripts, tile sets and tile maps.

PhysFS provides access to a shared data.zip package across desktop, PortMaster and Android builds. Writable configuration, scores and saves remain outside the packaged assets.

GitHub Actions builds the game data once, then produces Linux and Windows packages and PortMaster binaries for aarch64 and armhf. A separate assembly stage combines both handheld binaries with the launcher, metadata, controller mapping and game data.

The PortMaster submission was accepted and the game is available through its catalogue. Submission testing led to startup-script adjustments, with no changes required to the game itself. It runs well on my Anbernic RG40XX-H and has also been tested through gameplay on my Linux and Windows desktops.

The Android version is operational in emulator testing. Earlier memory and lifecycle problems have been resolved, with work continuing on the touch-control overlay before release.