damon

@damon

ヾ(・ω・*)

  • they/them

┐(︶▽︶)┌

 

Better things are possible

 

thank you for everything, cohost!

 

ffxiv

log inask
damon
@damon
johnnemann
@johnnemann
QuestForTori
@QuestForTori
Sorry! This post has been deleted by its original author.
QuestForTori
@QuestForTori
Sorry! This post has been deleted by its original author.
xkeeper
@xkeeper

I'm going to be that person

I think it's silly to not think of Windows as the default "easier to support" option, because that's what it is.

"But X, —"

  • iPhone/iOS's disabling of 32-bit app support
  • MacOS/iOS's upkeep fees for "developer accounts"/app store access
  • Android updates frequently break old apps or they get removed from the store (and more upkeep fees)
  • Many Linux distributions, all with their own packaging/support nonsense
    • Flatpak/Snap/Docker/whatever the "distribution is hard man I just want shit to run" solution du jour is helps this but you can kind of see the problem already with there being more and more variations
  • Windows, by nature of its already immense install base, also has pretty good tools on other systems to run things; VMs, dual booting, etc. If you have a Windows game, there's a pretty good chance you can figure out how to get it running on MacOS or Linux. You have a MacOS game and want to play it on Windows? Good luck, pal.

You can still, right now, download the original cave story, for windows, a program with a last modified date of 18 fucking years ago, and it runs fine on modern Windows, with zero effort. I literally dragged it out of a zip archive and clicked it and boom, game. Hell, most older games seem to work pretty great. There's a few that don't, of course, but those are exceptions to the rules.

Windows, for all its flaws and faults, explicitly went out of their way to make compatibility a thing.

Microsoft, as shitty and garbage of a company as they are, did not decide x years ago "You know what? We're going to disable every single 32-bit program released for our device, just because we can, and there's nothing you can do about it."

johnnemann
@johnnemann

Yes

I dropped support for Mac with my games not just because of audience size and bug report numbers, but because I needed to pay Apple every year for the privilege, as well as own and maintain Mac hardware for testing and building. I support Linux because at least it's free, I can dual boot to test, and also Linux users are generally pretty understanding of needing to do a little tinkering to have a good experience.

But I'm just not going to give Apple any more money to be one of their developers and get treated like shit.

johnnemann
@johnnemann

*bursts back in* And another thing!

Every once in a while Apple "gets serious" about games and for approximately the length of one WWDC there's a big push to convince people that games on Mac could be a thing. This never pans out and Mac is never actually a big games platform.

However,

We have seen what it looks like when Apple does control a platform for games, and the kinds of decisions they make as stewards of a gaming ecosystem and marketplace. And friends, it is DIRE. iPhone games are pretty much the only meaningful kind of mobile games and because of Apple's particular choices in promotion and so on they've created a world in which everything is "free-to-play" using casino mechanics to keep people hooked and cultivate "whales". And even though the games are cheaply made and free to users there's enormous barriers to entry that are only surmounted by the top studios by spending ridiculous amounts of cash to essentially buy users to keep their place at the top of Apple's big list. And Apple is fine with this as long as they get their cut of every dollar coming through. So I'm very glad that Mac is a tiny sliver of the gaming market, because any sort of dominance would likely kill the kinds of games I want to make and play. I don't trust Apple to make any good decisions about how to grow and nurture games, or any art form, as a medium.

You must log in to comment.

in reply to @QuestForTori's post:

dog
@dog

There was also a fun thing from one dev who discovered that indeed most of their bugs were reported on Linux… but that those bugs weren’t Linux-specific. Instead, they just found that Linux users were more likely to submit bug reports.

login to reply
plumpan
@plumpan

So I don't mean this to come off as pointed, I feel like it can potentially but that's not the intent.

Are there still big reasons to try and develop native linux ports with how Proton is nowadays? Or at the very least, targeting proton compatibility rather than native linux use?

login to reply
lapisnev
@lapisnev

Proton is not a perfect copy of Windows and needs to be tested separately for compatibility. Not every dev does this. A handful actually do support Proton as the intended way to play on Linux but most completely ignore Wine/Proton issues.

Valve's own compatibility information gets out of date sometimes. Either a game marked working really doesn't or a game never officially tested has always worked perfectly.

DRM.

login to reply
plumpan
@plumpan

The days of buds are long gone now :eggbug-pensive:

I'm also curious what's involved in making mac ports on arm now, I'm assuming it's more than "change some flags" but that's also well out of my realm of knowledge.

login to reply
plumpan
@plumpan

Oh nice!

I'm kinda surprised apple is doing stuff like that outside of some apple arcade specific/restricted use, given how they're pushing that lately. Because of all the things you've mentioned I just assume, from the outside, that it's extremely rare to see a game with macos compatibility if it's not coming from apple's marketplaces.

login to reply
MisutaaAsriel
@MisutaaAsriel

Pretty much. Apple tried a handful of times to partner with Valve for things like VR or extended support, only for Valve to drop the ball the minute the money dried up (and put in the bare minimum when they did support things).

Now they're partnering with the likes of Kojima, CAPCOM, SEGA, etc. to directly bring games to Mac themselves, and Game Porting Toolkit is essentially Apple's answer to Proton, except you can't ship software with/for it (so it's only for testing). Though they do also provide tools to convert DirectX shaders to Metal shaders, which is in part what GPT is meant to test (since it runs this atop WINE).

login to reply
plumpan
@plumpan

I'm curious what the workload is for "hey let's make sure it runs in proton" vs "let's do a native linux port". I imagine a lot of that depends on how the game was built.

As a user and from a wider picture view, a native linux port is for sure better. I think for anyone big enough to be looking at a game in terms of a business, it starts to become a harder sell. In that scenario I think proton is also a lot more attractive since I feel like that's basically the intended steam deck platform at this point rather than native. Might be wrong on that but those are the vibes I get. Almost just the steam deck as a platform rather than linux (despite the fact that it IS linux)

login to reply
SArpnt
@SArpnt

as a linux user, i don't ever want to touch windows. i don't think i'll even support properly windows for any programs i develop.

if windows users want to run my programs they can compile it themselves (or see if the untested binaries work), they can run it in wsl, or they can run linux in a liveboot.

login to reply

in reply to @xkeeper's post:

MisutaaAsriel
@MisutaaAsriel

Apple brought 64-bit application support to Mac as far back as 2007, and was telling everyone approximately around 2010 to make all software 64-bit if at all possible. 32-bit PCs were being sold well into the life of Windows 8, whilst Apple completed the transition in 2010, phasing 32-bit Mac hardware out entirely with macOS 10.7.

They didn't arbitrarily drop 32-bit support, as there is performance benefits + it eased the jump to ARM, and, they warned developers years in advance that they should be building their applications as 64-bit.

Microsoft continued support for 32-bit due to legacy enterprise software (the world of business software is rife with rot), and whiny OEMs who couldn't be bothered to ship machines with 4GB of RAM as standard or a functional CPU. And they just did the same transition in 2021 Apple did with Mac 11 years prior in 2010 — Windows 11 is the first major release of Windows to drop support for 32-bit hardware (though I believe there was a service pack/feature update for 10 that also dropped support).

Legacy support is no excuse for developer complacency or laziness.

login to reply
xkeeper
@xkeeper

Legacy support is no excuse for developer complacency or laziness.

It's a good thing everyone has the capability for endless support, troubleshooting, and development; otherwise you're just lazy.

Your argument sucks.

login to reply
MisutaaAsriel
@MisutaaAsriel

I think you misunderstand.

For years now gaming hardware has been primarily 64-bit. Arguably, the last time the majority of gamers used 32-bit Windows for gaming was Windows 7, and even then that is arguably a stretch, as 32-bit Windows cannot exceed 4GB of RAM. Likewise, professionals oft opt for machines with higher RAM, and therefore 64-bit, to meet their demanding workflows.

So WHY was there 32-bit software, games, and front ends being released well into the mid-to-late 2010s targeting these users?

Why is Steam itself STILL 32-bit?

Why should a game store be warning Mac users of 32-bit incompatibility for games released as late as 2016, 6 years after there are no machines for that platform that necessitated 32-bit support?

That's complacency. Developers were used to compiling for 32-bit, used to 32-bit being "the standard", even after no machines, whether Mac or PC, that required 32-bit code could any longer support their titles.

Developers didn't move on because they didn't feel the need to move on. It was and is wholly unnecessary to compile many of these programs for 32-bit platforms, yet everyone from indie developers to Valve themselves have, over the years, done so anyways, because that's what they're used to.

It's literal complacency. Technology ages. Technology grows. As does everything. Developers need to learn to move with the flow, not fall back on dying practices just because it's easiest to them. That's literally the root of technical debt. Being complacent with the way things are because they "work". Until they don't.

login to reply
SArpnt
@SArpnt

you don't need to package linux programs. you can just make a single executable or extract a zip or tar.gz or whatever you prefer, exactly the same way any windows program without an installer works. i've seen many programs do exactly that, and so far they've always worked.

the packaging situation is confusing if you aren't familiar with it, but i'm not sure windows really does that any better. on windows i have genuinely seen every single one of these things:

  • exe file by itself
  • exe file and other files in zip that needs to be extracted and ran
  • zip with multiple exes and bat files and you need to figure out which one is correct
  • exe/bat that needs to be run in a terminal to see it do anything
  • exe/bat that needs to be run in a terminal with command line arguments
  • exe that installs the program
  • msi that installs the program
  • program installer where the install location can't be chosen
  • program installer that doesn't create desktop/start menu shortcuts
  • program installer that doesn't add to the "installed program" list in windows
  • program installer that is in the "installed program" list but can't be uninstalled or in any way removed from the list
  • thing where i have to manually edit $PATH
  • hours finding every single thing a program a program complains it doesn't have but also doesn't come with. i never finished this it's impossible

linux packaging sounds complicated, i'm sure there's a variety of reasons for that but i think it's mainly just the way it gets explained online and people assuming that the parts of it that get talked about less either work like windows or are too confusing to learn.

login to reply
ShiningWing
@ShiningWing

Random .tar.gz/whatever packages downloaded from websites working out of the box every time is pretty much the opposite from what I've always seen, and it's why the universal packaging formats were developed in the first place

Because while simple terminal apps will usually work, complex GUI apps with a lot of dependencies become more and more likely to break spectacularly the farther you get from the specific configuration of the person who built the package, which is especially really common if you're not running Ubuntu since that's what everyone seems to build for

A good example I've seen recently is that my girlfriend tried to run melonDS on SteamOS, but being used to Windows, she downloaded the .tar.gz package from the app's website at first (instead of the Flatpak as is typical on SteamOS) and it didn't work at all

This is why I tend to be fond of Flatpak honestly, especially since it isn't all that hard to build for from what I've seen, I think it's a pretty good solution

login to reply
SArpnt
@SArpnt

if you don't bundle the libraries with the program or give instructions to install them then yes, it won't work, but this exact same issue happens on windows too, and it's not even that rare.

the only real difference is that devs seem to expect people on linux to do more to get a program to work, so they might leave out libraries it needs and might not even give proper instructions to set it up. i think a program is missing a library, it'll output an error in the terminal, and it's usually easy to fix it. problem is that you already need to know to try and run a program in a terminal to figure this out.

maybe i'm wrong and unpackaged linux executables have other issues but if they do then i don't think i've ever personally seen it.

login to reply
ShiningWing
@ShiningWing

You're right, that is the main issue, but I think it's a more important one than you're implying, particularly for non-technical/beginner users who won't know to look in the terminal for a specific error (if they're even running it from the terminal in the first place, when it comes to GUI apps), especially if they're not on a distro that makes it easy to install said missing dependencies (like SteamOS), or if the dependencies aren't the right versions

While it can be a problem on Windows too, it's less common because Windows is a single OS with far less variety in configurations and libraries, and its backwards compatibility systems go a long way for making those random 20-year-old EXEs continue working

I just think that if a developer is making a GUI app and putting a .tar.gz on their site because they don't want to deal with packaging for individual distros, they should at least consider packaging for Flatpak since it guarantees that the app will run on every distro that supports Flatpak (which really is all but the most niche ones), and doesn't seem too difficult to build for compared to a lot of distro packages I've seen

login to reply
dog
@dog

I think if you find yourself saying "I'm going to be that person", it's probably a good time to reconsider if you want to reply. Like, I get where you're coming from, but you're opening really aggressively.

login to reply
xkeeper
@xkeeper

"i'm going to be that person" in the sense of i'm going to be the person that disagrees, since everything i saw otherwise has been heaping agreement on it. it certainly has not had much in the way of people saying otherwise, from when i've seen this topic come up on mastodon and here.

and if me pointing out that, no, windows actually has had a lot of actual, real work done on it to keep shit working, and the other platforms have actually straight up done the opposite, idk, then.

login to reply
ShiningWing
@ShiningWing

I think the Linux situation is in a pretty good spot right now though to be honest, Flatpak (for desktop GUI apps) and Docker (for server apps) are both pretty mature and are effectively the closest that exist to universal standards in their spaces

Snap is also a thing, but hardly anyone gives much of a shit because it's not really a "universal" solution, it's made for Ubuntu and its specific quirks (such as requiring AppArmor if you want any sandboxing) and is hardcoded to use Canonical's proprietary repo, so for the purpose of desktop GUI apps there isn't much of a reason to use it over Flatpak (it's not horrible for servers, but again, Docker)

AppImage is also a thing I guess? But despite some people being really insistent on it being good, it's not really a "universal" solution either because its apps have no obligation to actually be portable, and you're going back to the Windows method of "scattered EXEs with no built-in update method" which a lot of us use Linux to get away from in the first place

So yeah, I feel like if someone wants to make an app and have it run on as many distros as possible, the solutions are better than ever now

Edit: Linux has always been a lot worse about backwards compatibility than Windows, but I think that's kinda to be expected when it isn't just one "OS" and is instead a large collection of very different distros, some of which died years or decades ago, as opposed to Windows which is a single OS from a single corporation, I think the current solutions like Flatpak and Docker will go a long way to help with that though in the future

login to reply
xkeeper
@xkeeper

appimage was the other one i couldn't remember, bluh.

flatpak and stuff seems to be usable, but i have a lot of issues with how those kinds of apps do their sandboxing and it's frustrating. my example was in trying to get an openrct2 server going -- the flatpak install came with no instructions on basic things like "how to get the game to read a configuration file" and resulted in nonsensical errors to the end user (because it's all in a sandbox and can't see literally anything). also the "discovery" app on the steam deck crashed every time i tried to update applications unless i only did a small amount at a time and there was no obvious cli version i could find, for whatever that's worth

these flatpak types of distributions also mean that applications are all just huge bundles of immutable Stuff now, which is better for the application but (imo) a lot worse for people who like tinkering. it's w/e though

login to reply
ShiningWing
@ShiningWing

(Sorry if all the advice isn't really wanted, I just think this stuff's neat and wanna be helpful if I can)

If you don't already have it, then Flatseal is a great app to have for dealing with the Flatpak sandbox, the main utility being that you can add any path you want to allow a given Flatpak to see (there's terminal commands that can do all this stuff of course, but having a GUI that shows everything for each app is nice)

But yeah, trying to run a server with it probably isn't the intended use case for the Flatpak, though it should probably still be possible with enough effort and with stuff like Flatseal like I mentioned

I just noticed that on Docker Hub there's an openrct2-cli image that seems intended specifically for multiplayer hosting, so that could be an option if you're still interested (and if the distro you're on has Docker/Podman available)

Weird that Discover keeps crashing for you 😩 I've had issues with it before but never really that specific one, I wonder if it's fixed in newer versions of KDE (the one on the Deck is pretty old by now)

You can update your Flatpaks through the terminal though (Discover is just KDE Plasma's own GUI for your distro's package manager, like how GNOME has GNOME Software), it's "sudo flatpak update", with "sudo flatpak repair" being available if things still aren't working (that's basically always fixed things when I've had issues with Flatpak)

login to reply
xkeeper
@xkeeper

I wasn't having any luck in Google trying to find the cli command for that on the deck, good to know it's just flatpak update. The installs work, I just can only run a few at a time (update all will freeze Discover)

I didn't want to have to go through the mess of installing/configuring docker (I have not used it very much at all, you may have noticed I've had a lot of "problems" with sandbox filesystems) and the github page recommended that, in the end it was actually easier to just build it from source (though of course the build instructions weren't correct, some package or other was missing)

login to reply
ShiningWing
@ShiningWing

Yeah that's fair, to be honest I'm not even sure how to install Docker on SteamOS specifically, because of the immutable environment

I have rootless Podman installed (because of Distrobox, which admittedly I'm not even really currently using on my Deck), but that seems like it comes with its own drawbacks, though I'm not sure how much those would apply to something like a game server that doesn't need, for example, ports below 1024

I only really use Docker/Podman on my VPS for my website really, and literally just for php-nginx (and an ioquake3 server I never play on lol), though I find it pretty convenient on there, I mainly started using them so I could make use of the immutable Fedora CoreOS and its automatic system updates (since Docker/Podman is how they recommend running software on there)

login to reply

in reply to @johnnemann's post:

eniko
@eniko

Yeah there are loads of reasons why we're not supporting Mac going forward but the primary one is that I don't believe in rewarding bad behavior. Apple constantly screws over devs and milks them for extra pennies and it's just not fucking acceptable and I refuse to encourage them

login to reply
dropbear
@dropbear

One of the big reasons Counter-Strike 2 doesn't support Mac after 9 years of CS:GO being on it is because Apple silicon does not support Vulkan and doesn't support external GPUs. I suspect other Valve Source 2 GaaS like Dota 2 will remove it soon and anything made in future won't support Mac.

Steam is the PREMIER MAC GAME STORE and Valve themselves are unable to continue supporting MacOS with their own games.

login to reply
Pinned Tags