2

I'm working on a project, specifically a game engine, that has support for both Windows Desktop (Win32) and Universal Windows (UWP/WinRT for Xbox One) platforms. Though I'm having trouble managing it. For Visual Studio, WinRT projects and standard C++ projects need to be compiled with different project types. So for each project I need to build I need to have two projects that build the same source code. For example, the engine needs to be compiled using two different projects. Once, for each platform I want to run on. Meaning everytime I need to run and test it on each platform I need to manually set the startup project to the project I want to launch. I hope that makes sense.

So my question is: Are there any tools, best practices or design patterns, for dealing with projects like this? Ideally I would like to just change the configuration to, say Xbox One, to launch for Xbox One, or Win32, to launch for Windows Desktop. But am open to new sugggestions.

Thanks!

GCourtney7
  • 61
  • 6
  • For Windows, Microsoft is working on these issues: https://learn.microsoft.com/en-us/windows/apps/project-reunion/ note that (not sure on Xbox) you can today use many WinRT APIs (those marked dual contract) from a standard Win32 Desktop App. You can also take a look at WinUI3 (not 2): https://learn.microsoft.com/en-us/windows/apps/winui/winui3/ – Simon Mourier Mar 07 '21 at 08:11

1 Answers1

2

I have a number of C++ libraries that build for "classic" Win32 desktop, Windows 10 desktop, UWP, and Xbox. The majority of the code is Win32 C++ or DirectX. For games, audio, and rendering, there's a pretty clear overlap of these platforms which is where I focused.

I have a blog series that captures much of the 'best practices' I used you may want to reference: Dual-use Coding Techniques for Games.

There are a few cases where I needed to interact with Windows Runtime APIs. In some contexts, I use the C++/CX extension guarded with __cplusplus_winrt. In some cases I used WRL via the low-level ABI (which is frankly pretty ugly, but I didn't need to do all that much). C++/CX is only supported by Microsoft Visual C++, so WRL or better yet C++/WinRT is a better choice for new projects.

Concrete examples would be:

All multi-platform engines isolate things like the 'window management, presentation loop, and swap chain'. For the Microsoft platforms, I've captured these in VS templates on GitHub.

Each platform also has it's own implementation of things like Cloud-based Storage, Store/licensing APIs, Multiplayer matching/connection, etc. so you'll need to isolate these as well if you implement them.

All that said, you should think about what your goals are for this project. If you want to create a game, use something that's readily available like UnrealEngine or Unity. If you want to learn more about graphics and games technology like Direct3D, audio, etc. then a small engine is a good idea but you should really scope your target platform to something simple. Writing a 'multi-platform' engine is a huge task, so just sticking to one to start is usually the better option.

Chuck Walbourn
  • 38,259
  • 2
  • 58
  • 81
  • These are fantastic resources thank you! So would you actually recommend setting up the project the way I have now? Having two different projects that will compile the source code two different times? Obviously into two different executables, but from a workflow perspective, this is kind of clunky: an App_UWP.vcxproj and an App_Win32.vcxproj as well as an Engine_UWP.vcxproj and Engine_Win32.vcxproj. – GCourtney7 Mar 09 '21 at 03:51
  • You'd probably want to make that Engine project 'shared' if possible so it just builds the code once, and then isolate all the UWP vs. Win32 things in those projects. Of course, you can always build the same 'shared' source file in each of the platform vcprojs. I've always maintained parallel projects just because doing otherwise well requires messing with custom props, but that's technically doable as well. – Chuck Walbourn Mar 09 '21 at 05:05
  • That's how I have it organized right now. The engine source code is inside a shared items project (.vcxitems) then `Engine_*` builds those files to each platform's requirements. Is that what you mean by shared? – GCourtney7 Mar 09 '21 at 05:27