Preserving Sands of Time

If you want to take a deep dive into the story of how Prince of Persia was created and the history of it’s development, we have a whole separate entry about it. This article is not about archival knowledge. This is a story about struggle, ingenuity and perseverance that our tech team showed to deliver on a promise. 

But for that I guess we still need to establish a tl;dr of what happened. 

articleRelated ArticleFrom Parking Lot to Palace: The Complete History of Prince of PersiaIn 1985, Jordan Mechner pointed a camera at his 15-year-old brother David and told him to run at a wall.arrow_forward

The Sands of Time launched in November 2003, developed by a young Ubisoft Montreal team under creative director Patrice Désilets. It scored a 92 on Metacritic. It sold over 14 million copies. It introduced the time-rewind mechanic – press a button and the world rolls back seven seconds, letting you recover from a missed jump without losing progress – which has been borrowed by dozens of games since. 

Jordan Mechner, the series creator who came aboard as writer, described how the rewind mechanic came first and everything else was built around it:

That was a gameplay desire: Wouldn’t it be cool to not have to die and restart so often? Is it possible to have a button on the controller that will just rewind, like rewinding a videotape? The engineers took that as a challenge, and we built the whole game around it.

Jordan Mechner, Ubisoft News, October 2024

In September 2020, Ubisoft announced a full remake. After years of delays, studio reassignments, and a near-complete restart, they cancelled it in January 2026 as part of a major corporate restructuring. The remake is not coming. And here’s where we step in.

You asked, we delivered

So before you go any further – let me add a little spoiler. We have delivered on our promise, and you can enjoy this new version now!

GOOD OLD GAME

Prince of Persia®: The Sands of Time

-80% $9.99 $1.99

View on GOG arrow_forward

So now that we got this settled, for those of you that opened the link above in a new tab and not just went away, let me tell you a story.

The problem: when everything is locked to everything else

To understand why it took so much time since January to deliver on our promise, you need to understand how games of this era were built.

In the early-to-mid 2000s, games were designed around fixed constraints. A game targeted 30 frames per second, or in some cases 60. It ran on 4:3 monitors at a handful of standard resolutions. DirectX 9 was the dominant graphics API. These weren’t limitations anyone expected to change – they were the reality of the hardware, and engines were built tight against them.

The problem is how tight. In Sands of Time and many other games from this period, the framerate wasn’t just a rendering target. It was structural. Physics simulations, collision detection, animation timing, game speed (even if not all of the game – some objects could fling at warp speeds that would make ensign Pavel Checkov impressed) – all of it was calculated on the assumption of a specific number of frames per second. One frame equalled one tick of the physics engine. The math was literally: “a frame is 1/30th of a second, so move the character this far.”

So what happens when you run the game on a modern machine at 60 FPS? The physics engine is now ticking twice per frame-interval it was designed for. But it’s worse than just speed. When the physics calculate faster than the engine was designed for, collision detection starts failing. The Prince clips through geometry. He falls through the world. Ladders stop working – the engine checks “is the character touching the ladder?” once per physics tick, and at higher tick rates the character passes through the ladder’s collision zone before the check fires. The game doesn’t just play wrong. It breaks in fundamental, unpredictable ways. Some people even reported blocks getting launched at incredible speeds when moving them close to the ledges. While amusing visually, it’s enough to render it annoying at least and unplayable at extremes.

Why you can’t just limit the framerate from outside

The obvious solution sounds simple: just cap the framerate to what the game expects. Force it back to 30 or 60 FPS and everything should work, right?

It turns out this is surprisingly difficult to do well when the game itself doesn’t support it natively. External framerate limiters – tools that sit outside the game and try to control how fast it renders can do that better or worse and they do use directx hooks, but that’s the main issue – it’s external tools. I myself am nearing 41 and keeping technologically savvy, but I have some friends that need a map to not get lost in an excel spreadsheet. Try to tell them to install yet another program. Or try to coach your grandparents through the phone.

There are workarounds that can achieve a more consistent framerate, but they come at a brutal cost: near-100% CPU usage on one core, because the tool has to constantly poll the system to stay in sync. It’s the brute-force approach – run a tight loop that checks the clock thousands of times per second, burning CPU cycles to approximate what the engine could tell you directly if you had a way to ask.

So for the longest time, this was the reality that we faced that touched many DirectX9 games. This is also the reason why many of the games from that period have issues or are very hard to update to not only work on modern systems, but also to run in modern settings without creating space-time continuum issues.

The breakthrough: knowing when a frame ends

The core insight behind our solution is deceptively simple: instead of guessing at frame timing from the outside, we built something that sits on the inside.

DirectX 9 – the graphics API that Sands of Time and most games of its era use – has a built-in concept of frames. When a game renders using DX9, it makes specific function calls to signal frame boundaries: one call when it begins rendering a frame, another when rendering is complete, and a third when the frame is ready to be pushed to the screen. These calls are part of the API. Every DX9 game makes them. They’re the engine’s own heartbeat.

What we in GOG built is a set of wrapper DLLs – files that masquerade as the real DirectX libraries. When the game starts, it loads what it thinks is the standard DirectX 9 DLL. It’s actually ours. From the game’s perspective, nothing has changed – it makes the same API calls it always made. But now those calls land in our code first, before being passed through to the real DirectX layer.

That means we know, with precision, when every frame starts and ends. Not approximately. Not by polling or guessing. The engine itself is telling us, because it’s calling our functions.

With that knowledge, everything changes. We can cap the physics tick rate at exactly the right point in the frame cycle. We can do it without polling loops burning CPU, without assembler patches that break when anything changes, and without the need for external tools that user needs to install for it all to work.

The wrapper includes several DLLs covering different parts of the DirectX stack – not just the main Direct3D rendering library, but DirectInput and others. Together they give us a complete picture of how the game communicates with the hardware, which means we can intervene wherever we need to.

The FOV problem: the Prince’s unmentionables

Framerate is only half the story. The other half is what happens when you change the screen shape.

The Sands of Time was designed for 4:3 monitors. That was the display standard in 2003. The game supported only a handful of resolutions, all hardcoded, all in 4:3 aspect ratio. The field of view – how wide the camera’s perspective is – was hardcoded to match: calculated to show a specific amount of the environment horizontally, tuned to feel natural on the screens players actually owned.

Here’s where it gets strange. The FOV wasn’t just tied to a specific resolution – it was tied to the aspect ratio. Specifically, the engine was hardcoded to always show the same amount of content horizontally, regardless of the display configuration. On a 4:3 screen, that worked fine. The horizontal width was correct, and the vertical height was calculated to match.

But force the game onto a 16:9 screen – the standard for every modern monitor – and the engine keeps that horizontal width fixed. To fill the wider screen, it has to crop vertically. The wider the display, the more it crops. On a standard 16:9 monitor, you lose a significant chunk of the top and bottom of the frame. On a 21:9 ultrawide, you lose so much vertical space that the camera ends up locked on the Prince’s midsection. There’s no polite way to say it: you end up playing the game staring at the Prince’s crotch.

This isn’t a cosmetic issue. In a third-person platformer where you need to see platforms above and below you, losing vertical field of view makes the game genuinely harder to play. Jumps you can’t see. Traps you can’t anticipate. The spatial reasoning the entire game is built around becomes impossible.

The wrapper fixes this by intercepting the FOV calculation and replacing it with one that correctly accounts for the actual display ratio. Instead of hardcoding horizontal width and letting vertical space suffer, it recalculates the field of view to show the right amount of the environment for whatever screen you’re using. The game looks correct on 16:9 and 21:9 without stretching, without cropping, and without the Prince’s anatomy becoming the focal point of the experience.

Game-agnostic by design

Here’s the part that matters beyond Sands of Time.

The core of the wrapper – the DLL proxy architecture, the frame-boundary interception, the infrastructure for applying timing and rendering fixes – is game-agnostic. It’s not built specifically for Prince of Persia. It’s built for DirectX 9. The game-specific work – identifying exactly which physics calculations need capping, where the FOV math lives, what hardcoded values need overriding – still requires reverse engineering on a per-game basis. But the platform those fixes run on is reusable.

That matters because Sands of Time is not unique in having these problems. The mid-2000s produced an entire generation of games built on DirectX 9 with the same constraints: locked framerates baked into the physics, FOV tied to 4:3 resolutions, game speed coupled to rendering speed. Many of those games are beloved. Many of them are, right now, sitting on modern PCs refusing to behave correctly.

The locked-framerate debate goes back years. In 2014, John “TotalBiscuit” Bain – one of the most prominent voices in PC gaming criticism before his passing in 2018 – ran a campaign through his Steam Curator page specifically flagging games with locked 30 FPS caps. The broader conversation about framerate locks, physics coupling, and whether any of it was acceptable landed across Kotaku, Game Developer, and most major press outlets. The issue was well understood. The tools to solve it, game by game, were not.

One of the biggest frustrations for people like that is when a game prevents them from getting the performance their hardware is capable of due to arbitrary limitations within the software itself and one of the most obvious and jarring that has such a big impact on how a game plays, is a 30 frames per second (or lower) lock.

John “TotalBiscuit” Bain
E-mail conversation with Nathan Grayson – originally quoted in Kotaku article

This wrapper is a step toward changing that. Sands of Time is the first game to receive the treatment. It won’t be the last.

A small step for Prince, a massive step for DX9

What the wrapper proves is that the approach works. That sitting inside the DirectX pipeline, with authoritative knowledge of the engine’s frame timing, is a fundamentally easier approach for the end user, and because of that a better foundation for preservation fixes than anything that came before it. That the same architecture can be extended, game by game, to bring an entire era of PC gaming back to a state where modern hardware isn’t fighting the software. 

So let’s sum up – Sands of Time runs at modern resolutions, modern framerates, and with corrected FOV. It’s stable and it’s playable in ways it hasn’t been in years. But there is more to do – more tuning, more edge cases, more games waiting for the same treatment. Even now we’re expanding the functionalities and including DirectX8 to it, with more additions considered and evaluated for the future. But this is exactly why it’s such a big deal – we now have a tool that we can improve, expand and update, and it’s not locked to one game or one series. It might still be a small step, but the future of video game preservation is looking bright.

GOG Preservation Program

The GOG Preservation Program ensures classic games remain playable on modern systems, even after their developers stopped supporting them. By maintaining these iconic titles, GOG helps you protect and relive the memories that shaped you, DRM-free and with dedicated tech support.

Learn more