This is especially egregious when you remember the PS4 and PS5 operating system are themselves based on FreeBSD, meaning the original game was natively targeting a Unix-like OS to begin with. So to then say it won’t run on Linux is a huge middle finger.
It tell us quite a lot actually; the native PlayStation game was running on a POSIX system, on x86(-64), and Vulkan/OpenGL. Ergo, it took extra work to port the game to Windows, when the original title ran on something very close to a Linux desktop.
I work on an open source project in my free time. Officially we support Linux, Windows, and macOS.
I had to change ~2 lines of code to port the Linux/Mac code path to FreeBSD. Windows has a completely different code path for that critical segment because it’s so different compared to the three Unix/Unix-like.
This is a very specific example from a server side code that leaves out a lot of details. One being that we wrote our project with the intent that it would be multi platform by design. Game software is wildly complicated compared to what we do. The point here is that it should be easier to port Unix to Unix-like compared to Unix to Windows.
I’ve heard that PS3 games, while the OS was too, I think, based on FreeBSD, ran in a sort of a hypervisor and used some features of the Cell architecture.
I’ve never read about PS4 and PS5 OS’s, and them being Intel-based should mean that it’s possibly less exotic.
Of course various unices are almost source-compatible.
No, because the thing that’s breaking is not graphics related (which is the major difference between Windows and Unix), it’s very likely an anti-cheating measure that’s trying to gain root access to the computer, and when it can’t it crashes the game. This is not an issue on Playstation because Sony controls the OS so they’re okay with giving root access to the game or (more likely) are okay with that part of the code not running while on a PlayStation.
This is especially egregious when you remember the PS4 and PS5 operating system are themselves based on FreeBSD, meaning the original game was natively targeting a Unix-like OS to begin with. So to then say it won’t run on Linux is a huge middle finger.
No, “based on” doesn’t tell us anything. Just that to avoid repeating work they took FreeBSD.
It tell us quite a lot actually; the native PlayStation game was running on a POSIX system, on x86(-64), and Vulkan/OpenGL. Ergo, it took extra work to port the game to Windows, when the original title ran on something very close to a Linux desktop.
As far as I know PS4/PS5 don’t support OpenGL or Vulkan, they have their own APIs.
I work on an open source project in my free time. Officially we support Linux, Windows, and macOS.
I had to change ~2 lines of code to port the Linux/Mac code path to FreeBSD. Windows has a completely different code path for that critical segment because it’s so different compared to the three Unix/Unix-like.
This is a very specific example from a server side code that leaves out a lot of details. One being that we wrote our project with the intent that it would be multi platform by design. Game software is wildly complicated compared to what we do. The point here is that it should be easier to port Unix to Unix-like compared to Unix to Windows.
I’ve heard that PS3 games, while the OS was too, I think, based on FreeBSD, ran in a sort of a hypervisor and used some features of the Cell architecture.
I’ve never read about PS4 and PS5 OS’s, and them being Intel-based should mean that it’s possibly less exotic.
Of course various unices are almost source-compatible.
No, because the thing that’s breaking is not graphics related (which is the major difference between Windows and Unix), it’s very likely an anti-cheating measure that’s trying to gain root access to the computer, and when it can’t it crashes the game. This is not an issue on Playstation because Sony controls the OS so they’re okay with giving root access to the game or (more likely) are okay with that part of the code not running while on a PlayStation.