7 ms·

As someone who has just released[1] a first access game across Windows, macOS and Linux: 10 years ago developing on linux as a game developer was way worse tha

As someone who has just released[1] a first access game across Windows, macOS and Linux: 10 years ago developing on linux as a game developer was way worse than windows and MacOS, now there is no real difference at all. I speak as a long time UNIX user, Linux was terrible for C++ devleopment, debugging and asset creation/viewing (compared to the others) making gamedev tougher than it needed to be. 10 years ago linux's OpenGL drivers were behind even MacOS and way behind Windows OpenGL which was behind DirectX by quite some way. Now Linux's drivers are fairly good although it's still a nightmare upgrading radeon drivers and NVidia's drivers seem to be fickle. This leads to a lot of bugs from users and supporting various distro/hw/driver combinations. Libraries like libSDL(2) were less mature 10 year ago, multi monitor, input and sound support were patchy because the Linux landscape was fragmented and buggy. Now libSDL2 is pretty much spot on. Mutli-monitor is doable (not as good as macOS but as good as windows), input is pretty good and sound is OK (but most people use FMOD which is superb). Where Linux falls behind is deployment. No I am not going to ship my source for you to compile. itch.io and Steam go a long way to make it easy to deploy and crucially update the game. It's still a PITA to deploy a compiled app on Linux with unclear glibc versions and amazingly it's worse than MS DLL hell of MSVC redistributable shambles. It's not impossible to overcome but it's a PITA for a small market. Not a good position to be in. I support macOS and Linux as well as Windows because I believe in plurality but I can see why many chose not to. Don't think that using Unity or Unreal make anything easier either. In many ways they are worse than a well written custom engine. [1] https://executionunit.itch.io/smith-and-winston https://executionunit.itch.io/smith-and-winston

moocowtruck 8y ago
even with snaps or whatever that thing ubuntu has?
- dazzawazza 8y ago
  Not everyone is on Ubuntu. I currently have eight VMs each with different distros. Mostly it's for testing library compatability on install and input weirdness. That's a lot of testing.
  - alexeiz 8y ago
    Snaps work on other Linux distros, not just Ubuntu. There is also Flatpak which may work even better. You should do your research.
    - AnIdiotOnTheNet 8y ago
      He still has a deployment problem. Flatpak needs to be installed and requires users to set up repos, including flathub itself, so he has to have them jump through extra hoops even if he puts his product in the largest most default repo available. From what I understand about Snap, the only difference is that that the One True Repo is installed by default. AppImage is another option he could consider, which requires no repos or additional installs, just flipping the execute bit on the AppImage file. Unfortunately even that is spotty because there is no standard set of libraries to rely on like there is on other platforms, so he'd pretty much have to include everything from glibc up to be safe.
  - popey 8y ago
    Snaps work on at least 40 different distros last time I looked. They remove a significant chunk of that 'library compatibility' because they ship the necessary dependencies in the package. While Ubuntu dominates the Linux desktop market, by a couple of orders of magnitude, we made snaps with the express intention of them working on all the major leading distros. The goal being to ensure you don't need to test on all those different distros. One snap to rule them all ;)
  - moocowtruck 8y ago
    i think people mentioned snaps work on non-ubuntu systems. can't you build everything statically that you need, and deploy as snap? is it a ton more difficult than that? not saying thats easy, but seems less of a burden and you can hit at least a large amount of users
deleted 8y ago
[deleted]
barrkel 8y ago
Containers could be a way out for deployment, if the mixing of licenses can be constructed in a tractable way.
- spacenick88 8y ago
  or snaps
plq 8y ago
> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?
- AnIdiotOnTheNet 8y ago
  It's not hard, it's just stupid that the platform has such a remarkable lack of consistency that you can't rely on anything but the kernel ABI.
  - plq 8y ago
    I honestly don't see the problem. It's a different platform so it's got different quirks, that's just life. Having said that, I strongly prefer Linux's explicit shared object search paths and very user-friendly dynamic linker to Window's implicit search scheme (aka the DLL hell). If that means I need to add my dynamic linker along with a couple lines of wrapper script so my binaries work, so be it. And, you can even avoid the wrapper script if you can make sure your stuff is always installed to a standard location (eg. /opt/yourcompany) and you pass -Wl,rpath to your linker (at compile time) but I really don't see the point.
    - AnIdiotOnTheNet 8y ago
      > I honestly don't see the problem. It's a different platform so it's got different quirks, that's just life. If Linux Desktop were one singe different platform there wouldn't be a problem. Instead it is effectively some ridiculously large number of platforms.
      - HeadsUpHigh 8y ago
        The differences between them are getting smaller and smaller with time. With the notable exceptions of some really cool distros like nixOS or Solus most others have almost the same libraries at this point at varying versions.
sysrpl 8y ago
If you want an automated tool to generate a deb file for distribution, you might want to try this program I created for that purpose: https://www.getlazarus.org/apps/makedeb/ https://www.getlazarus.org/apps/makedeb/
wtetzner 8y ago
> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions and amazingly it's worse than MS DLL hell of MSVC redistributable shambles. One option is to statically link against musl libc [1]. The kernel ABI is about the only stable thing you can rely on (which is something you _can't_ rely on for macOS or Windows). [1] https://www.musl-libc.org/ https://www.musl-libc.org/
- dazzawazza 8y ago
  Thank you. musl looks very interesting. It's something I didn't consider, I'll add it to my research list :)
- scns 8y ago
  Is it not possible to link glibc staticalliy? IIRC musl has readability and code size in mind while glibc optimizes for performance at the cost of readability and codesize.
  - nineteen999 8y ago
    The problem that I know of is that glibc supports loading DSO modules, eg. for NSS, so it's not going to support pluggable NSS sources like LDAP etc when statically linked. There are workarounds, however: https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead https://stackoverflow.com/questions/3430400/linux-static-lin... Can't imagine many Linux gamers are going to need NSS support in their game binaries. It's a bit of a stretch to say glibc doesn't support static linking, perhaps "officially" it doesn't, its just not all the extended features are going to work. Static linking is generally going to be frowned upon these days however since you're effectively linking security issues into the binary forever.
  - rurban 8y ago
    Not really. musl optimizes for performance and codesize, whilst glibc optimizes for the random user who needs to read error message in farsi and logs on via an external LDAP service, and needs LD and MALLOC hooks to debug weird edge cases. glibc unicode tables are huge, musl are tiny. glibc uses assembler optimizations for everything, whilst musl uses compiler auto-vectorization, which mostly beats handwritten assembly, esp. with constant arguments.
dhimes 8y ago
What do you use as a compiler? gcc?
bryars 8y ago
"Mutli-monitor is doable (not as good as macOS but as good as windows), " What's the gap between Linux/Windows and Mac OS ?
- pzone 8y ago
  MacOS has had perfect crisp multi-monitor support including fractional scaling and mixed DPI with per-windiow/per-monitor application DPI awareness for years. Windows is finally introducing a diagnostic in the task manager to show which applications have high DPI support. The modern option, per-monitor awareness, isn't even possible on Linux with the X display server - it requires Wayland.
  - Lio 8y ago
    This is the issue in a nutshell for me. I wish I’d bought a FHD 1080 screen instead of 4K on my XPS 13 for this very issue. Wayland isn’t an option for me yet because I need screensharing under Hangouts, etc. You can’t mix the HiDPI internal screen with, say, a 1440 external monitor with Gnome on X11. Scaling is applied equally across both. Also if you drop back to plain text e.g. during boot up the internal screen will show text at 100% scaling and the text is tiny. I guess that might be something BIOS could take care of but it’s currently a problem. Sorry, can’t offer comparisons to Windows, I just work with macOS and Linux.
zzo38computer 8y ago
Well, you should release the source code, or else a DOS executable file that can run on DOSBOX, or a .NES ROM image file, or whatever, the end user can then provide their own emulator to run it on. Only the end user shall have full control over what runs on their computer, not you. I currently use Linux and it is much better than Windows (although I didn't like the desktop environment so I uninstalled it, but customizing the system is what I do regardless of what operating system).

moocowtruck 8y ago

even with snaps or whatever that thing ubuntu has?

dazzawazza 8y ago
Not everyone is on Ubuntu. I currently have eight VMs each with different distros. Mostly it's for testing library compatability on install and input weirdness. That's a lot of testing.
- alexeiz 8y ago
  Snaps work on other Linux distros, not just Ubuntu. There is also Flatpak which may work even better. You should do your research.
  - AnIdiotOnTheNet 8y ago
    He still has a deployment problem. Flatpak needs to be installed and requires users to set up repos, including flathub itself, so he has to have them jump through extra hoops even if he puts his product in the largest most default repo available. From what I understand about Snap, the only difference is that that the One True Repo is installed by default. AppImage is another option he could consider, which requires no repos or additional installs, just flipping the execute bit on the AppImage file. Unfortunately even that is spotty because there is no standard set of libraries to rely on like there is on other platforms, so he'd pretty much have to include everything from glibc up to be safe.
- popey 8y ago
  Snaps work on at least 40 different distros last time I looked. They remove a significant chunk of that 'library compatibility' because they ship the necessary dependencies in the package. While Ubuntu dominates the Linux desktop market, by a couple of orders of magnitude, we made snaps with the express intention of them working on all the major leading distros. The goal being to ensure you don't need to test on all those different distros. One snap to rule them all ;)
- moocowtruck 8y ago
  i think people mentioned snaps work on non-ubuntu systems. can't you build everything statically that you need, and deploy as snap? is it a ton more difficult than that? not saying thats easy, but seems less of a burden and you can hit at least a large amount of users

deleted 8y ago

[deleted]

barrkel 8y ago

Containers could be a way out for deployment, if the mixing of licenses can be constructed in a tractable way.

spacenick88 8y ago
or snaps

plq 8y ago

> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?

AnIdiotOnTheNet 8y ago
It's not hard, it's just stupid that the platform has such a remarkable lack of consistency that you can't rely on anything but the kernel ABI.
- plq 8y ago
  I honestly don't see the problem. It's a different platform so it's got different quirks, that's just life. Having said that, I strongly prefer Linux's explicit shared object search paths and very user-friendly dynamic linker to Window's implicit search scheme (aka the DLL hell). If that means I need to add my dynamic linker along with a couple lines of wrapper script so my binaries work, so be it. And, you can even avoid the wrapper script if you can make sure your stuff is always installed to a standard location (eg. /opt/yourcompany) and you pass -Wl,rpath to your linker (at compile time) but I really don't see the point.
  - AnIdiotOnTheNet 8y ago
    > I honestly don't see the problem. It's a different platform so it's got different quirks, that's just life. If Linux Desktop were one singe different platform there wouldn't be a problem. Instead it is effectively some ridiculously large number of platforms.
    - HeadsUpHigh 8y ago
      The differences between them are getting smaller and smaller with time. With the notable exceptions of some really cool distros like nixOS or Solus most others have almost the same libraries at this point at varying versions.

sysrpl 8y ago

If you want an automated tool to generate a deb file for distribution, you might want to try this program I created for that purpose: https://www.getlazarus.org/apps/makedeb/ https://www.getlazarus.org/apps/makedeb/

wtetzner 8y ago

> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions and amazingly it's worse than MS DLL hell of MSVC redistributable shambles. One option is to statically link against musl libc [1]. The kernel ABI is about the only stable thing you can rely on (which is something you _can't_ rely on for macOS or Windows). [1] https://www.musl-libc.org/ https://www.musl-libc.org/

dazzawazza 8y ago
Thank you. musl looks very interesting. It's something I didn't consider, I'll add it to my research list :)
scns 8y ago
Is it not possible to link glibc staticalliy? IIRC musl has readability and code size in mind while glibc optimizes for performance at the cost of readability and codesize.
- nineteen999 8y ago
  The problem that I know of is that glibc supports loading DSO modules, eg. for NSS, so it's not going to support pluggable NSS sources like LDAP etc when statically linked. There are workarounds, however: https://stackoverflow.com/questions/3430400/linux-static-linking-is-dead https://stackoverflow.com/questions/3430400/linux-static-lin... Can't imagine many Linux gamers are going to need NSS support in their game binaries. It's a bit of a stretch to say glibc doesn't support static linking, perhaps "officially" it doesn't, its just not all the extended features are going to work. Static linking is generally going to be frowned upon these days however since you're effectively linking security issues into the binary forever.
- rurban 8y ago
  Not really. musl optimizes for performance and codesize, whilst glibc optimizes for the random user who needs to read error message in farsi and logs on via an external LDAP service, and needs LD and MALLOC hooks to debug weird edge cases. glibc unicode tables are huge, musl are tiny. glibc uses assembler optimizations for everything, whilst musl uses compiler auto-vectorization, which mostly beats handwritten assembly, esp. with constant arguments.

dhimes 8y ago

What do you use as a compiler? gcc?

bryars 8y ago

"Mutli-monitor is doable (not as good as macOS but as good as windows), " What's the gap between Linux/Windows and Mac OS ?

pzone 8y ago
MacOS has had perfect crisp multi-monitor support including fractional scaling and mixed DPI with per-windiow/per-monitor application DPI awareness for years. Windows is finally introducing a diagnostic in the task manager to show which applications have high DPI support. The modern option, per-monitor awareness, isn't even possible on Linux with the X display server - it requires Wayland.
- Lio 8y ago
  This is the issue in a nutshell for me. I wish I’d bought a FHD 1080 screen instead of 4K on my XPS 13 for this very issue. Wayland isn’t an option for me yet because I need screensharing under Hangouts, etc. You can’t mix the HiDPI internal screen with, say, a 1440 external monitor with Gnome on X11. Scaling is applied equally across both. Also if you drop back to plain text e.g. during boot up the internal screen will show text at 100% scaling and the text is tiny. I guess that might be something BIOS could take care of but it’s currently a problem. Sorry, can’t offer comparisons to Windows, I just work with macOS and Linux.

zzo38computer 8y ago

Well, you should release the source code, or else a DOS executable file that can run on DOSBOX, or a .NES ROM image file, or whatever, the end user can then provide their own emulator to run it on. Only the end user shall have full control over what runs on their computer, not you. I currently use Linux and it is much better than Windows (although I didn't like the desktop environment so I uninstalled it, but customizing the system is what I do regardless of what operating system).