This isn't particularly linux-y of an issue. I've had the same sort of behavior in numerous games on Windows, up to and including crashing the graphics driver when alt-tabing out of a full screen game. Seems to be something gamedevs are not commonly testing, and perhaps difficult to defend against when a game is directly interacting with the GPU.
I can guarantee you any gamedev worth his salt will have used alt-tab at some point in the game's development on windows. It's an incredibly common hotkey to use, and the devs very likely have multiple ides, notepads, image editing software running concurrently. You seem to be trying really hard.
> when a game is directly interacting with the GPU.
Most devs are using cross platform graphics APIs. OpenGL/DirectX/Vulkan. Alt-tab breaking is likely an OS issue.
Not exactly a repeatable testing framework, that.
> You seem to be trying really hard.
I almost strained a typing finger! /s lol
> Most devs are using cross platform graphics APIs. OpenGL/DirectX/Vulkan. Alt-tab breaking is likely an OS issue.
All the OSes seem to suffer from it similarly. More likely an issue that even the cross-platform graphics APIs rely heavily on shared memory buffers and most games depend on code written in languages which aren't strictly memory safe. Sharing a memory buffer between CPU and GPU (or even just multiple CPU cores) is quite difficult to do safely under all possible circumstances without proper language support.
In fairness to game devs, alt-tab'ing out of a running game would be a challenge for many testing frameworks as it's not something you can do at compile time, requires running the game for a period of time (CI servers don't typically have GPUs), requires some sort of keyboard/mouse automation, and interaction with the underlying OS in addition to the game.
Issues which aren't added to some sort of test suite/CI tend to creep back in to codebases. Especially rapidly developed codebases like games. And threading issues are notoriously challenging to reproduce. Hopefully that helps you understand the difference.
Your assumption of what you've been taught in compsci circles with many resources at their disposal does not hold up in places in which fast iterations are required, and with little time to set up testing frameworks because as you said they're hard to test.
I would say most game devs. That doesn't change a thing I've said.
> plus the stability of drivers there
Driver code for Nvidia, AMD, and Intel are all shared across Windows and Linux these days. Have been for years. AMD's even made a point of pulling improvements from the Linux drivers back into the Windows drivers.
> Your assumption of what you've been taught in compsci circles with many resources at their disposal does not hold up in places in which fast iterations are required
I have developed games. I write libraries useful for gamedev. Every game developer I know uses version control and most use CI. Contrary to your opinion, version control and CI help to iterate faster with greater confidence, and don't require lots of resources, just a GitHub account and 5 minutes.
What an odd thing to argue.
Funny because I know game developers who don't use CI. And I've developed games too. It's not as universal as you claim it to be. It was never about arguing the effectiveness of CI.
I'm sure they're out there. A bit like publicly declaring you drive without wearing a seatbelt.
> It was never about arguing the effectiveness of CI.
The original point was that alt-tab'ing out of a game can result in unexpected behavior on any OS. Shared memory buffers in graphics APIs are the most likely culprit. And all graphics APIs on all OSes use them. I'm still not sure what exactly you're trying to argue about that.