How to port from a custom engine to multiple platforms three times faster 

The demand for porting is growing. We now live in a cross-platform world. To meet the demands of the modern market, publishers must release games everywhere. The market itself has shifted — launching entirely new franchises is expensive and risky, while continuing established IPs is a safer bet. Even better (and safer) still is re-releasing existing titles as remasters with support for new platforms. That’s why this segment of services is thriving — not despite the current slowdown in the industry, but perhaps because of it. 

Some widely used engines, like Unreal Engine 5, make porting simple. They already support different platforms by default. But if you use a custom engine, you have no such luck. At Room 8 Group, we know the pain of porting a game to every platform individually. It’s hard, painstaking work.  

So our industry-leading R&D engineers built a solution: REI. 

REI—pronounced “Ray”—stands for Rendering Engine Infrastructure. A unified graphics API, it’s a solution to the problem of porting a custom engine game to multiple platforms. You port your game to REI once, and most of the hard work is done: it’s almost ready for every major platform. As you can imagine, it fulfills an urgent need for our partners—and, we believe, for the industry as a whole.  

To explore REI’s technical details further, we sat down with Maksym Mytkevych, Game Engine Technical Director at Room 8 Group. Read on to discover his insights into this literally game-changing technology.                  

If you want to leverage Room 8 Group’s cutting-edge porting tools and industry-leading expertise, get in touch here. 

Room 8 Group (R8G): What does “uniform rendering code, single implementation—multiple platforms” mean? 

Maksym Mytkevych (MM): Each platform has its own rendering API. There are rendering libraries responsible for interaction with dedicated graphics hardware (video card) and drawing graphics on the screen, for rendering visuals.

These rendering APIs all exist for the same purpose—to render graphics by utilizing the computer’s graphics hardware (GPU) and video subsystem to generate and display visual content on screen.

But they work a bit differently, and we also need to use them a bit differently. That is, they have different commands. On PlayStation, for example—on PlayStation 4 it was one thing, and on PlayStation 5 something else appeared. On Xbox it’s DirectX 12, on Windows operating systems we can face DirectX 11 – DirectX 12; there was also DirectX 10, 9 was earlier.

On Linux there is OpenGL, on Macs there is Metal, Vulkan is also used—basically, there’s a whole zoo of different libraries with different names, which differ from each other. 

So, when the task is to port a game that was originally written for one platform—for example, for Windows—and was created using DirectX 9 or 10, then for every other platform you want to port it to, you need to stop using the original rendering library and use the one appropriate for that platform instead. And that’s quite a time-consuming task. On average, porting a game from one rendering library to another requires considerable developer effort. Of course, it depends on the game and the engine it’s built on — sometimes it takes less time, sometimes more. But either way, it requires a fair amount of effort. 

R8G: So what does REI do? 

MM: REI introduces the concept that, for the programmer using these libraries, it looks just like another rendering API. You still need to integrate it. Say you have a game written using some specific API, like DirectX 9 or 10. First, you migrate the game to REI. But once that’s done, REI already knows how to work with a wide range of rendering APIs under the hood.  

It can use OpenGL, Vulkan, DirectX 12, or other, console-specific APIs. You port the game to REI once, and for all other platforms afterward, there’s no need to re-port. You simply switch REI into the mode for the desired rendering API (use the required render backend implementation) and build the game for that target. 

This means that no matter how long porting usually takes in your case, with REI, the time investment is significantly reduced—especially if your game needs to be ported to more than two platforms. Once the initial integration is complete, adapting to additional platforms becomes a matter of configuration rather than redevelopment, saving considerable time and effort. 

R8G: Do we have a sense of how much time REI actually saves on porting? 

MM: It depends on the number of platforms. The more platforms you’re targeting, the more benefit you get from using REI. Once the initial integration is done, REI can significantly reduce the time required for adapting the rendering layer to additional platforms. 

If you’re porting to just one platform—say, from Windows to PlayStation—the time savings are still handy, but not dramatic, since there’s still a fair amount of platform-specific work to do. But when you’re targeting three or more platforms, REI helps streamline the rendering part of the porting process by at least 2x—and potentially more, depending on the specifics of the project. 

And it works great in cases where you need to port a custom engine game to multiple platforms. 

Because games built on Unreal Engine or similar tech already support multiple platforms out of the box. The developers working on those engines have already added support for different rendering APIs. They can use different rendering libraries, and they work across platforms right out of the box. 

That’s why with Unreal Engine games, porting is more like optimization—making sure graphics work well across devices with different performance levels, tweaking frame rates, adjusting assets—but not hardcore porting. 

But where REI helps the most is in the case of custom engines, which are sometimes less mature and built for internal use only, not to be sold on the market.  

These engines were created by companies for their own needs, and usually don’t include broad functionality. They only have the features needed for the specific game they were made for. So if the original plan didn’t include releasing the game on other platforms, then there’s no built-in support for those platforms at all. That’s exactly where REI brings the most value. 

R8G: Tell us about the flexible base for potential remastering and visual enhancements. 

MM: The key point is that we control the development of REI. While it’s not built entirely from scratch, it’s also not just a copy—and is far more comprehensive than other solutions currently available. 

REI is built on a rendering library, Forge, to which we’ve added our own version of the SDL—a whole additional library that’s not only about graphics. It includes a lot of helpers that simplify working with things like input (joysticks, keyboards, mice), sound (various audio devices), and file systems for storing, loading, saving, etc. It also contains a code base of utilities that streamlines the use of all these components and speeds up the integration process for games built on different engine architectures. So in short, REI is a comprehensive solution that comes in a single, super handy bundle.

REI is always integrated with our own SDL version. So, when we talk about our porting solution, it includes not just REI, but also our extended version of SDL, which we always integrate into the project along the side with REI. That’s our approach. 

Another thing is that Forge is designed not just for games. As a low-level API, it’s also used in apps and other tools. With it, you wouldn’t typically write the higher-level code that’s needed in game integration. Each project that uses Forge can implement things in its own way, with different architectures, different code. 

But we often deal with recurring tasks. For example, when working on ports of older games—say, from the 2000s or around 2010—they’re quite similar. Many are written in DirectX 9, or even 8 in some cases.

We’ve realized that to port these games to a new rendering API, we often need more than just a low-level render abstraction interface. We also need a bunch of extra functionality. So we’ve split that functionality into a separate library, where we’ve added things like a 3D context layer. We’re currently working on a variety of smaller features, like ‘dry utilities,’ that help us integrate such typical projects into REI even faster. 

As for visual enhancements — we can go even further. We’ve only just begun exploring this potential, but because we control the rendering API and its integration, we can modify different parts of it. 

We’ve even had ideas to add more modern tech—for example, to integrate features from other engines, or add ray tracing support directly into REI, since it’s such a hot topic right now. 

There’s a tech called RTX Remix. You take an old game, run it through RTX Remix, and it allows you to capture all the resources the game uses and then run them through AI to improve their quality. 

So when you launch the game next time, it loads those enhanced resources, and the game looks significantly better. 

RTX Remix can even enable ray tracing in older games. In just five or six hours, you can swap out the assets and get visuals that make the game look like it was released five years later than it actually was. It’s a great example of how quickly graphical upgrades can be prototyped. 

However, RTX Remix is more suited for modding and demo builds—it’s not designed for full production pipelines.

Due to third-party software dependencies, potential licensing restrictions, and performance limitations, we can’t use RTX Remix directly in our ports. 

That said, the idea behind it is inspiring. We’re currently exploring ways to integrate similar capabilities directly into REI or REI-based tools—such as built-in support for ray tracing, post-processing effects, or a modular post-effects library. This would allow not only fast cross-platform porting but also rapid graphical improvements—especially for older games, and potentially for newer ones as well. 

Some of these features are still in development, but since REI is our own modular solution, we can continuously expand it based on what’s most useful for production-ready remastering and porting workflows. 

R8G: Tell us about the framework that includes a wide amount of generic non-rendering reusable code and tools, simplifying and speeding up porting to all modern platforms. 

MM: That’s what I was referring to earlier. Our porting solution, this framework, includes not just REI, but also SDL. SDL is also a library available on the market. It basically does for input, sound, file systems, etc.; what a rendering REI API does for graphics. It provides a unified interface for working with different underlying systems. 

So just like you can implement your code once using a rendering abstraction, you can also use SDL to write code for input devices, sound, and file operations—and run it across multiple platforms. 

You can reuse that code across systems, but only on platforms that SDL officially supports. Unfortunately, we found that SDL doesn’t cover everything. For instance, more closed platforms like PlayStation aren’t supported out of the box. 

That’s why we didn’t just use SDL as-is—we extended it. We made significant additions to the library, including our own custom SDL implementation for PlayStation. As a result, most of the modules SDL provides now work seamlessly on that platform too. 

We also made improvements to existing modules. For example, we wanted file system access to work more like it does in Unreal Engine—because many of the developers are familiar with UE’s approach. So we adjusted the behavior of these modules to be more intuitive and consistent with what our teams expect. 

Basically, we streamlined everything to fit our internal workflows. Our version of SDL turned into a kind of Swiss army knife—a versatile set of tools we can reuse across projects when porting games. 

Looking to save time and budget? 

Our cutting-edge porting tools and industry-leading expertise can help your teams deliver projects faster and more efficiently. 

Want to know more? Let’s talk.