Every long-lived game engine accumulates legacy projects — games built against older API versions, compiled with outdated toolchains, and designed for hardware that barely resembles what’s in use today. HGE is no exception. Games built with HGE during its peak years still exist, some still have active players, and many need updates to run correctly on modern Windows.

At Relish Games, we’ve gone through the modernisation process ourselves. This case study covers the practical steps, common pitfalls, and realistic expectations for bringing a legacy HGE game into 2026.

The Starting Point

A typical legacy HGE project from the mid-2000s to early 2010s looks something like this:

  • Compiler: Visual Studio 2005–2010
  • DirectX: DirectX 8 or 9, using fixed-function pipeline
  • Windows APIs: Win32, some deprecated functions
  • Build system: Visual Studio project files, no CMake
  • Resolution: Fixed at 800×600 or 1024×768
  • Audio: DirectSound or BASS library
  • Code style: C with classes, minimal use of STL, raw pointers everywhere

The game works on its era’s hardware. But on a modern Windows 11 machine with a discrete GPU and a 4K display, problems emerge.

Common Issues

1. Compilation Failures

Modern Visual Studio is stricter about deprecated functions, type conversions, and header dependencies. Common issues:

  • sprintf → sprintf_s or suppressed warnings
  • Missing Windows SDK headers that were previously implicitly included
  • Linker errors from changed library names or removed legacy libs
  • C++ standard compliance issues (things that old MSVC allowed but standards don’t)

Approach: Fix one compilation error at a time, working from the top. Most are straightforward substitutions.

2. Display and Resolution

Legacy HGE games often assume specific resolutions and don’t handle:

  • High-DPI displays (everything renders tiny)
  • Widescreen aspect ratios (stretched or cropped)
  • Multi-monitor configurations
  • Exclusive fullscreen deprecation

Approach: Add resolution detection at startup. Render to a virtual framebuffer at the game’s native aspect ratio, then scale to the display. The HGE system state settings for screen dimensions handle the basics, but you may need to add letterboxing logic.

3. Rendering on Modern GPUs

Modern GPUs handle DirectX 8/9 through compatibility layers, but edge cases exist:

  • Some fixed-function blend modes behave differently
  • Texture format support has changed
  • Vertex processing defaults differ
  • Some drivers handle legacy DirectX less carefully than others

Approach: Test on multiple GPU vendors (NVIDIA, AMD, Intel integrated). The blend mode documentation is your reference for expected rendering behaviour. If rendering looks wrong, start with blend modes and texture format handling.

4. Audio Compatibility

DirectSound is deprecated. Some audio libraries used in legacy HGE projects have been abandoned.

Approach: If the game uses HGE’s built-in audio (which wraps BASS), updating the BASS library to its current version usually resolves compatibility issues. If the game uses custom audio code, consider migrating to SDL_mixer or miniaudio.

5. Input on Modern Configurations

USB controllers, high-polling-rate mice, and different keyboard layouts can cause issues:

  • XInput gamepads weren’t common when some HGE games were written
  • Raw input handling may conflict with high-polling-rate gaming mice
  • International keyboard layouts might not map correctly

Approach: Add input configuration options. The HGE input system is straightforward enough to wrap with a remapping layer.

The Modernisation Process

Phase 1: Get It Building

Priority: compile and link with modern Visual Studio.

  1. Create a new Visual Studio 2022 solution — don’t try to upgrade the old project files
  2. Add source files and configure include/library paths for HGE
  3. Fix compilation errors methodically — most are mechanical substitutions
  4. Fix linker errors — update library references to current HGE builds
  5. Run the game — it probably works, possibly with visual glitches

This phase is typically 1–3 days depending on code complexity.

Phase 2: Fix Rendering

Priority: the game looks correct on modern displays.

  1. Test at multiple resolutions including high-DPI
  2. Add resolution-independent rendering — render to a virtual framebuffer, scale to display
  3. Fix blend mode issues — compare rendering against known-good screenshots
  4. Add widescreen support if the game can benefit (letterbox if it can’t)

Phase 3: Update Audio

Priority: sound works on modern Windows.

  1. Update BASS library to current version
  2. Test all audio paths — music, sound effects, volume control
  3. Handle audio device changes — modern systems may switch devices mid-game (Bluetooth headphones connecting, etc.)

Phase 4: Quality-of-Life Improvements

Priority: the game feels contemporary.

  1. Add resolution selection — either a launcher or in-game menu
  2. Add controller support — modern players expect gamepad input
  3. Improve save game handling — move saves from the game directory to AppData
  4. Add windowed/borderless fullscreen options
  5. Implement proper quit handling — save state on Alt+F4 and window close

Phase 5: Build System Modernisation

Priority: anyone can build the project.

  1. Create CMakeLists.txt for the project
  2. Document dependencies — exact HGE version, additional libraries
  3. Add a build script that pulls dependencies and configures the build
  4. Set up continuous integration — even a simple build-on-push catches regressions

What Not to Change

One of the hardest parts of modernisation is knowing when to stop:

  • Don’t rewrite the game logic — if it works, preserve it. Refactoring working code risks introducing new bugs.
  • Don’t change the art — the original art is part of the game’s identity. Scale it well; don’t replace it.
  • Don’t add features — modernisation is about making the existing game work, not designing a sequel.
  • Don’t “clean up” code style — resist the urge to refactor everything to modern C++. Consistency with the existing codebase matters more.

Lessons Learned

Lesson 1: Working Backwards from the Player

Every modernisation decision should answer: “Does this make the game better for a player in 2026?” Resolution support: yes. Refactoring an internal data structure: no.

Lesson 2: Test Early, Test Often

The most expensive bugs are the ones you find after making 50 other changes. Build and test after every significant change. As we’ve discussed in posts about C++ performance and engine architecture, working incrementally prevents compounding problems.

Lesson 3: Document What You Changed

Future maintainers (including yourself in six months) need to understand what was modified and why. A CHANGELOG that notes each compatibility fix is invaluable.

Lesson 4: The 80/20 Rule Applies

Getting the game running (80% of the value) takes 20% of the total effort. Getting it running perfectly in every edge case (the remaining 20% of value) takes 80% of the effort. Decide where on that curve to stop based on your audience size and expectations.

Timeline Expectations

For a typical legacy HGE game (20,000–50,000 lines of C++):

  • Getting it to compile: 1–3 days
  • Fixing core rendering: 2–5 days
  • Audio and input: 1–2 days
  • QoL improvements: 3–7 days
  • Testing across configurations: 2–5 days

Total: roughly 2–4 weeks for a solid modernisation pass. This is real engineering work, not a weekend project — but it’s dramatically less effort than rewriting or porting to a different engine.

Explore the HGE documentation for API references that help with modernisation, browse the downloads page for current HGE builds, or discuss legacy game modernisation in our community forum.