This was a significant piece of work, because the original renderer had quite a lot of static state, particularly in the way that shader constants were managed, which was really problematic when going wide. Simon Brown, technical director at d3t spent a lot of time refactoring the engine to support multithreaded command buffer generation. When moving to DX12, we knew that multithreading the rendering was going to be essential to minimize CPU bottlenecks.
#Alan wake pc Pc
The original game on PC shipped with a single "main" thread, which was responsible for simulating the game logic, and building and issuing all the rendering commands. This way, any tweaks to terrain tessellation would not force the trees to regenerate position and size. The most robust solution was to simply bake out the original tree positions and sizes using the 32-bit version of the game editor, and then load those. It turns out that these positions had very subtly changed as a result of various floating-point calculations (the positions themselves were "randomly" generated based on geometry tessellation and various texture maps), and so the resulting tree sizes were completely wrong. Jon Arden, principal programmer at d3t spent some time investigating and found that the size was randomly generated based on the least-significant bits of the floating-point position. This is important as it impacts player sightlines and shot framing. After moving to a modern version of Visual Studio and going 64-bit, we noticed that tree sizes no longer matched the original positions. The game has pseudo-random generation of tree positions and sizes to generate the rolling forests. Thankfully we could run the 32-bit version of the original game, so the easiest way to debug these issues was to dump trace all the commands that the virtual-CPU was executing and then spotting where they diverge.
The internals of the system made a lot of assumptions about word-size, and it took a lot of debugging to flush out all the issues. The 64-bit port had some difficulties - most of them were typical 64-bit issues, but one of the trickier parts was porting the scripting language and accompanying virtual machine. That being said, a few interesting technical challenges do come to mind. It turns out that the original codebase was incredibly well put together - it was written very cleanly and for the most part it was very easy to modernize, modify and extend. There were certainly a lot of challenges, but thankfully the vast majority were not unexpected.
Game Developer: What were some unexpected technical challenges and how did you overcome them?
In an email interview with Game Developer, d3t studio technical director Andy Booth, with the help of his team, provided in-depth answers to explain how his studio addressed various tech challenges when developing Alan Wake Remastered. Following the story starring the titular author, the original Alan Wake is a game that-although generally well-received-is often considered under-appreciated in its time. With Remastered, Remedy and UK-based d3t are hoping to find new audiences on new-gen consoles.