Quoting: stretch611

QuoteOne of the programmers has been using Unity on Linux and said how it works just fine. Hearing that, fills me with hope about the future on Linux as a development platform as well as a gaming platform.

I hate to nitpick... especially on a topic that is not quite in the theme of this site... But, linux as a development environment has been strong for quite some time. I believe that I can safely say that linux is far stronger for development needs than it is for gaming needs.

I have had all my needs as a dev platform fulfilled for the last 10+ years in linux... that is what allowed me to drop windows completely. I still needed dual booting for games after I made the switch to developing full time on linux. Back then WINE was not as good as it is now, and we certainly did not have all the native titles that we do now.

Admittedly, gaming development may not have been as strong all those years, but part of that is the fact it helps a lot when the system you are coding on can execute and test the program you are writing. It can be frustrating waiting for compiles... no one wants to add the time necessary to reboot into a different OS just to test.

EDIT: All those reboots just to play a game was a huge factor to me. It weighed heavily on my personal decision not to buy all the shiny new windows titles. Especially when getting an off-hours call and having to immediately save the game I was playing (assuming I was at a point I could save) and reboot back to linux just to solve a quick problem. (Compared to now when I generally just swap out the game and leave it running in the background.)

Back then when the Humble Indie Bundle first appeared, and the games supported linux, it was a no-brainer. I was sold, and that really became the point where I never had to dual boot again.

My story to the smallest details.

View this comment - View article - View full comments

Quoting: wojtek88The problem is that Valve is the only big company that can push Linux gaming forward.

I cannot say anything due to NDAs and stuff, but rest assured that this is not true. In fact the future of AAA games on Linux is very bright.

View this comment - View article - View full comments

QuoteThere's a few things that I have to do for Linux too, which I'd rather get done right at the end of development. I hope that's okay!

Right at the end of development: Everything doesn't magically just work on Linux. Huh! I guess I'll delay the Linux version, who cares.

View this comment - View article - View full comments

Quoting: TheSHEEEPFirst of all, those duplicates were an issue many years ago when disk space was a problem. It simply isn't any more. This is a non-issue. Games nowadays can take any amount of space from 100MB to 60+GB. A few MB more in dependencies simply will not matter.

Last year I bought an SSD. It was expensive and I got a 256GB one. On windows, I consistently see about 100GB~200GB of OS+programs storage while on Linux all my OS+programs (that is everything excluding /home) takes about 20GB. So yes, that _is_ an issue still. I'm not talking just about games.

Also, duplication of .so files has more implications than just disk space. Scenario: imagine some library X is used by 20 applications. On windows, those 20 applications each have a copy of the same version of the same .dll file:

- Security: If the library fixes some bug, 20 applications (on windows with 20 different updaters) have to update that dll. We all know (on windows) that not all of them will do it, and the buggy library will end up remaining on your pc.
- File System Cache: If the library was shared between the 20 applications, then loading one application after the other would be much faster given that the same .so files are either already in RAM or likely at least in the file system cache. Each application shipping a separate copy of its .so files mean slower application start.
- Memory: Unless the OS does a byte-to-byte comparison of the whole .so files, it cannot know that the applications are using the same .so file, which means running multiple of those applications results in the same .so files loaded multiple times in RAM, resulting in higher RAM usage, as well as worse CPU cache usage.

In short, duplicate .so files is still a terrible thing now and shows no indication of getting better.

Quoting: TheSHEEEPAlso, yes that package managing stuff is nice. But only in theory, where it actually works.
In practice, games (and other software) are not constantly developed and updated with latest versions of libraries. And they shouldn't! Don't change a running system.
So at some point, version X of a dependency WILL rotate out. And then users have to find custom solutions, which is annoying as hell and will cause more people to switch to Windows for the product than it will cause them to fiddle around with their system. Fiddling around is nice for us proggers, but not for average users. This has happened SO MANY TIMES with open source libs that actually are maintained by someone - and so many times more by closed source software.
So either package maintainers have to carry ancient versions of their libs around (possibly even fixing critical bugs in them still if they appear) - and with that outlook, who still wants to maintain packages "properly"? Nobody.
Or developers are forced for a life long update-my-dependencies-game, including possible API changes and whatnot. Hooray.

No, I'm sorry. This package managing stuff may have noble goals, but in practice it is a terrible crux for developers that are actually paid for their work. And it throws more than just a few stones in the way of spreading linux.

I'm not saying let's do this today. Just that if from the beginning things were thought of differently, we may have been in a better situation now. The solution to your "dependencies get old" argument is actually quite simple. Imagine if Debian instead of phasing out old packages on new releases, it would accumulate on top of it. Simple as that.

View this comment - View article - View full comments

Quoting: TheSHEEEPYeah, the worst part about linux is that app/lib version mess.
Honestly, it should just be like on Windows - look in the executable folder first, done. Would solve all problems, at least for closed source distributions.

Having . in [LD_LIBRARY_]PATH is a terrible idea. Easiest way to spread viruses.

That aside, the real problem is in fact that they try to force a windowsish distribution on an operating system that has a proper package manager. The libraries on linux actually have pretty decent abi versioning, which means multiple libraries can co-exist and each application would choose the highest compatible version. Dependency-hell may be an issue for packagers, but the end results are damn nice for users.

Imagine for a moment if Linux games were also packaged like the rest of the system... No more 100 duplicates of .so files like on windows!

View this comment - View article - View full comments

I wonder why they wouldn't make it the default on windows either. That will make not only their vulkan renderer more stable (more people get to test it), but also damage directx considerably, which is nice.

View this comment - View article - View full comments

Quoting: GuestFor anyone not sure about what model GPU they're running, something like the following may help:

lspci | grep VGA

(that assumes you have lspci available of course)
GLX can also query information:

glxinfo | grep Device

There are other ways as well, depending on the distro used. I'm not really up to speed on all the graphical tools available, so I encourage people to suggest alternatives.

--edit: and cheers Liam!

While lspci works fine for me (not that I didn't know my own GPU), glxinfo doesn't have a "Device" line for me. In my case, this also gives my GPU:

glxinfo | grep "OpenGL renderer string"

View this comment - View article - View full comments

Could be interesting if valve released distribution of OS usage per country or continent. That could show whether such conclusions as "Asia uses windows, so there" is actually true. It's true that piracy makes eastern countries use proprietary software more "easily", but I have seen first hand (I'm from Iran) that there are also Linux advocates as much as there are here in the west (in Canada now).

View this comment - View article - View full comments

Something developers miss is that supporting other platforms (Linux included) doesn't always generate revenue proportional to the sales they make on that particular platform. There are numerous games that I bought on Linux, liked it and recommended to others who bought it (on windows), or bought it (again, on windows) so we can play together. Those people in turn encourage others to buy the game, which likely would again be on windows.

So even though the sale on Linux looks small, it helps increase the sale on windows as well.

View this comment - View article - View full comments

And where do they look to see who supports it? In case they look here, it's definitely something I would enjoy for local co-op!

View this comment - View article - View full comments