Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit) (+1)

There is. It’s called Windows version. I made this reply multiple times but - just use some modern Wine variant, it works perfectly fine.

Why not build native version? Because:

  1. Linux has no stable ABI or API (outside of kernel syscalls and POSIX but on their own they are useless to make anything for enduser). Can’t rely on anything being there and working in a few years - most games from initial steam push for games on Linux that tried to make native build will not work today, only the ones that relied on Wine would work. Look at native apps/games from just a few years ago. The most stable ABI and API on Linux is ironically Win32.

  2. I know for a fact that at least one of the things would be broken on native Linux version and it’s not worth to fix it for 1.5 users that will use it. That’s screen manager that manages render resolution and allows resizing windows. While code should be crossplatform there are some nuances with how Unity classes work on different platform and nuance on Linux is that they return nonsense results on Linux when multiple monitors are connected. As far as I can tell when asking for screen resolution it just returns X framebuffer size which is just sum of current resolutions of all screens. Which is completely useless information.

  3. That’ll be 4th platform to build for. It’s already a pain to package for 3 platforms, adding another one to the list would only make sense if userbase is not 1.5 users.

Best part is all of these points are solved by using Wine - it has stable ABI and API because Windows doesn’t break compatibility on a whim and all the pain points I described earlier fall onto the devs of Wine instead. And because it would just run windows application point 3 is also not an issue. And because Wine is not an emulation, it just translates Windows APIs into native syscalls or calls to modern libraries and allows running windows executables and load windows libraries - it’s not really slower than native application.

Running on Wine can have issues with videos if you have older hardware but that can be fixed by reencoding and replacing one file. If there are any other issues - these can be fixed and it’d be much more productive than trying to maintain and fix issues in native build.

weird that you say there's no user base and yet you complain about making this reply multiple times. guess there's more than 1.5 users after all. 

anyway I don't want to install wine because everything else I use works just fine natively. no probs though, plenty of games on this site which work fine on linux

(1 edit) (+2)

3 users in a year. Compared to for example at least 15-20 reports in a week when there was a bug in OSX build. And one of those asked for build because videos were broken in Wine due to outdated hardware that doesn’t fully support Vulkan. It’d take weeks to implement something that no one needs only to give WORSE experience than what you would have with Wine because they keep updating their software while recompiling unity player is simply impossible - it’s closed source, so if there is a compatibility break in API or ABI that player uses it would require full engine upgrade to fix. On the other hand Wine version will never break and if something breaks there almost always be a working fix for it. Distro maintainers also usually fix all compatibility issues with software they package while 3rd party stuff - if it doesn’t work you can’t do anything which isn’t a problem with Wine.

idk how or why dude doesnt use wine lol such a great tool for linux... Anyway just wanted to say you can also run a lot of windows games on linux by using steam and hit add non steam game select the exe for the game and then once you add it right click it in steam hit properties and turn on proton compatability. Then it will run just fine.