Hey all, I'm a kernel/vmm/embedded developer who is making a hobby game on the side with some highly competent friends. I have been using MSYS2/mingw64 to build my homemade CMake-based C++17 “game engine” on Windows for a while, but quite frankly I don't like it. It builds static binaries just fine, and they are not performing as well as on Linux. Don't worry about that, though - it's a 2D game. The problem is the terminals I'm using are slow and unresponsive, the editor I'm using (Atom) feels worse on Windows, and I feel like the filesystem is holding me back. Why is there no ~ for the home folder? ?

I feel like Windows is a pain to use and I don't want to spend any time programming there. So, what to do?

Well,

1. I could pay someone to create a best-practices windows build of my existing game engine. How would that look? What editor would I have to use to not feel like I'm working inside a VM?
2. I could pay someone to rip the guts out of the game engine and replace it with another. This is going to be expensive because my game is written using OpenGL 3.2+ mainly. Game engines should abstract that away, and obviously this will be time-consuming and maybe not worth the time.
3. I could implement the game on Linux, then create a Windows build semi-regularly as I always do, just to check things are still alright. This is what I do now, but I would like a Windows docker container to automatically build for me. Unfortunately, that's not a thing because.. Wintendo. Or did I miss anything?
4. Use VMware workstation to build Windows binaries with. The OpenGL emulation is not the best there, but I think it's just enough to get a context going. Maybe it was only OpenGL 2.x. I've done this and then I stopped doing it, but I don't remember why. Maybe it was a poor substitution for real Windows?

Did I miss anything? I'm obviously not against working on Windows, but I have a terminal-centric build system that has no IDE support (and I have no experience with that anyway), so did I lay out my options accurately?

Some technical details:
I'm using fopen and friends, using C++ over C to be more compatible with Windows. I'm not using anything Linux-specific that I'm aware of. My dependencies are GLFW, fmod, nanovg, backward-cpp and rapidjson. backward-cpp is for universal backtraces.

-Gonzo

Don't build on Windows. Cross-compile for Windows.

On Windows I definitely prefer Visual Studio (community). Using Cmake is an option. Also consider may need to debug things and optimisations can vary between platforms (so profile them all), so really want more than just CI build vm (but having that is certainly a good start). VS community includes the CPU and D3D profile/debug told. NVIDIA Nsight plugin gives tools for OpenGl, I am not sure for AMD cards or Intel iGPU.

I gave up trying to use VMs for testing/developing anything graphical. It might work if you have a GPU you can run in pass through mode, but the emulated one is terrible (for at least VMware and Virtual Box) and you can't get any useful profiling for optimization out of it.

OpenGL should be fine on Windows, but I recall performance characteristics can be different to Linux, and it seems a lot of the driver effort is really on D3D.

Kaptein said:
but I have a terminal-centric build system that has no IDE support

What's the point about that? You can either trigger a build manually from outside an IDE or go the Unreal Engine way, which also use their own build-tool written in C#, which works well from inside Visual Studio for example (along other IDEs they support). We have also wrote our own build-tools using C# which work well too.

Kaptein said:
Game engines should abstract that away, and obviously this will be time-consuming

That's true and the reason why they in the end exist. If it doesn't work well on Windows, you either have to spend more time getting into that platform or you have to limit your game to Linux only. A good engine developer knows the platforms the engine is supposed to support (a reason I would never ever deploy for Apple products). If you don't have or even want to get that knowledge, you are free to look for someone who is specialized on Windows and can do that for you.

Anyways, cross-compilation is the usual way to go. It is how Unreal deploys for Linux and Android from a Windows OS. Another way would be to have a Player application which just runs your game instead of native executables. This is how Unity does it and they reuse the same piece of executable code over and over again for all games published with it. It is just the content that changes but the Unity Player is still the same for all games.

TL;DR working platform independent is always double or tripple the work you have to do in opposite for just releasing on a single platform and you have no other choice than do it or leave it