Quoting: iWeaker4You

Quoting: SpykerUnfortunately this is a trend that will go on in the future.
Making native Linux games is hard especially when you have to deal with third party engine which may not handle Linux as well as Windows.

or Linux libraries... it change very frequently and break many applications, it's hard to maintain a software if you can't maintain a stable system, or avoid manipulating the userspace

Do note that many of those are not "Linux" libraries and that the games uses them on Windows as well (SDL, OpenAL and so forth). The difference is that these are supplied by the distribution on Linux and by the game devs on Windows and Windows devs does not know how to properly bundle libs on Linux so they depend instead on that the distro provided libs maintain ABI compatibility.

Unfortunately not many lib deverlopers think about keeping ABI compatibility, one major culprit here is SDL, thankfully there are external devs trying to fix this like https://github.com/libsdl-org/sdl12-compat [External Link] that is a lib that is ABI compatible with v1.2 of SDL but that uses the newer 2.x distro supplied lib for the actual implementation, aka a shim.

And what we need is more such projects (or for lib devs to follow how glibc handles backwards compatibility).

View this comment - View article - View full comments

One problem is that the posted fixes is for the Windows version of the games but Bioshock Infinite have a perfectly fine native version, anyone know if there exists a fix for this as well or is Protom the only way to fix it?

View this comment - View article - View full comments

A real quality of life for me would be if they all (Uplay, Origin, WTF) would just remove their completely unnecessary launchers.

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.UltraIf they don't provide a service, why do you think that dev houses uses them for publishing of their games?

Why do people all around the world choose to get exploited every day working under unfair conditions? Because they can't really choose! Your childlike vision of the gaming industry, and to an extent of the whole society we live in, is so sad...

So who forbids you from self publishing in Steam, The Epic store, GOG and foremost itch.io? True that there are people all over the world being exploited by ruthless employers, but does this really mean that all wage jobs are equal to slavery (mine sure as hell aren't) and that employers at base are evil parasites on society?

You seem to have a very black and white world of the world, reality is always complex, and much more diverse than so.

I also just noticed that you included Tencent in your list, they are not a publishing house, they are just investors (in this case) holding 40% of the share votes of Epic. And the others on your list are not pure game publishers, they all started out as game developers but then started to self publish when they got big enough and once that worked they started to publish other companies games and then when they got really big they started to straight out purchase dev houses.

So to be honest I don't think that your grief really is with publishers but with something else and you are just confusing that "else" with game publishers.

You also for some reason have a tendency to leave small personal attacks/snarks in every single comment, does that make you feel stronger somehow?

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.UltraNow that is of course the ideal naive version

More than naive I'd say delusional: Tencent, Activision Blizzard, Electronic Arts, Ubisoft... do I really need to go on?

Yes all those provide services for developer houses, they also sometimes do shitty things, the two is not mutually exclusive. If they don't provide a service, why do you think that dev houses uses them for publishing of their games?

View this comment - View article - View full comments

Quoting: GuestI know nothing about "games publishing" but in my mind, a games developer is someone who wants to make games, while a games publisher is someone who wants to make money... off someone else creativity, talent, and hard work.

Yes and no, if you are a games publisher then you really want to make money of your own creativity, talent and hard work when it comes to publishing which is a whole different talent than developing. Now that is of course the ideal naive version and I'm not saying that this is how every single publisher works (which this very article shows) but lets not pretend that publishing is "not work" or "not worth anything" or every single dev out there would be self published.

Now happen to get your game showcased on some big YT channel and sales will handle itself without a publisher, but that is the exception, not the rule.

View this comment - View article - View full comments

Quoting: StalePopcorn

Quoting: Eike

Quoting: StalePopcornToo bad the countries wherein these monolithic, soulless viruses exist also dictate the minds of their respective governments—as most successful parasites do.

The countries dictate the minds of their governments?
Strangely put, but it doesn't actually sound like something bad.

I see the misunderstanding based on my confusing/incorrect grammar.

"These monolithic, soulless viruses also dictate the minds of their respective governments in the countries wherein they exist—as most successful parasites do."

That better?

Embracer is from and have it's HQ in Sweden, so please explain what you mean how your quote matches them?

View this comment - View article - View full comments

Quoting: Comandante ÑoñardoIs Embracer Group on stock market or is a 100% private?

They are a publicly traded company, the three main owners (Lars Wingefors [Embracer, former THQ Nordic], Matthew Karch [Saber Interactive] and Andrey Iones[Saber Interactice]) together owns aprox 60% of the votes so they do not have to bend to the will of the other share holders.

View this comment - View article - View full comments

Quoting: Eike

Quoting: F.Ultra

Quoting: JordanPlayz158

Quoting: minidouI fail to see how glibc devs could be blamed for removing a function deprecated for 17 years (though I can agree a major version bump should have been called for). Do videogame devs need that much nursing ? EAC linux lib is a recent piece of software, how many deprecated dependencies do they use ?

Quoting: TermyI tend to agree with the criticism about unstable APIs for many cases - but in this case, i really blame Epic for using a function deprecated for almost two decades in a recent piece of software.

From everything I've read from other people, it wasn't obvious that the function was depreciated. You shouldn't need to search up, "is x function depreciated glibc" for every function you use, it should be immediately obvious (like most languages I know have comments or a depreciation tag), some say that all distros somehow knew about this but you shouldn't need to be familiar with linux development or need to be in the right communities to know about a depreciated function.

Small nitpick here, but DT_HASH is not a libc function, it's a linker section in the ELF header of a shared object. The function that utilizes this section is dlopen() and that function have not changed and it works, it's only applications that tries to read the ELF data manually that have to handle DT_HASH and DT_GNU_HASH, and by all means it looks like the glibc devs "incorrectly" thought that dlopen was their ABI/API and not the actual linker section in the ELF headers.

I find this neither nitpcking nor small! So it isn't an actual API change, but considered an internal data invisible to almost every user program.

Well it's complicated :). The glibc devs obviously didn't consider this a part of their API/ABI (they might do so going forward however) of their library. On the other hand ELF itself can from a point of view be considered to be the ABI of a shared object.

99.99999% of all applications does not care one cent about any of the ELF headers, all the work of parsing out the data to be used is handled by the libc functions such as dlopen() but some special applications, and EAC does match this criteria, wants to read/write and parse the ELF data directly and not use any of the provided libc functions. For EAC they do this in case dlopen() have been patched under their nose to hide the fact that this .so loads a cheating mod.

The problem here then is that the official ELF spec only contains DH_HASH and then have some mumble mumble about possible extensions while glibc back in 2005/2006 introduced DH_GNU_HASH as the better alternative. The official ELF specs does not carry "vendor extensions" AFAIK, of which this is one, and the glibc devs didn't really care either since they made sure that gcc and ld could handle both (and later clang, musl etc implemented the very same since they saw that gcc and ld handled this extension).

So we can't really blame the EAC devs either more to the point that they should perhaps have not just read the specs but also taken a look at how the actual implementation (gcc+ld) works since ELF can have extensions and as I wrote earlier I wonder if this could open a potential hole in the current implementation of EAC where a maleficent .so creates a nice looking DH_HASH while hiding their real stuff in DH_GNU_HASH since EAC only looks at the first while ld loads the second (but I'm not intimate enough with the exact details here to know for sure, perhaps ld loads only used DH_GNU_HASH if DH_HASH isn't there or EAC loads the .so for the game so that ld isn't involved at all).

What I do think that we can blame is all the people that scream bloody murder, I mean yes it was a problem, but it was fixed and it was fixed quickly. That last part is IMHO the important part and what makes Linux really shine, so to me this should be seen more as a positive thing and not as the horrible negative thing that it have became.

View this comment - View article - View full comments

Quoting: JordanPlayz158

Quoting: F.Ultra

Quoting: JordanPlayz158

Quoting: F.Ultra

Quoting: JordanPlayz158

Quoting: ShabbyXIt's made exactly so that libraries *can* break ABI if they have to, without the world imploding. glibc made a breaking change, and no matter how small, they should have made an incompatible version change. Yes that would still be inconvenient, but at least it's detectable and fixable. Imagine if python3 did all its backward incompatible things but still called itself python2.

Yes, that's exactly the point we were making, they didn't treat it as a breaking change as they just incremented the patch number by 1 rather than the major. Not to mention a lot of people have said it wasn't very clear and I could buy that as documentation doesn't seem to be a strong point in either linux or c in general (or I could be wrong (or xdg-desktop-portal could be a bad example of a c library) but when I attempted to make an application using xdg-desktop-portal they had the equivalent of a javadoc but that was about it, there are no examples provided in the repo for how to use any of the objects (or it wasn't clearly labeled or findable), there were no tutorials online and I looked into other repos (that are flatpaks as they must use xdg-desktop-portal to my knowledge) and it was a mess because different applications use different languages or sometimes used a middle man library or some combination of the two which made it difficult to know how to use the interface)

glibc is very well documented, as is most C libraries on Linux (don't know where this misconception comes from), they didn't see the ELF sections as part of the glibc ABI/API though which is why this went under the radar for developers that isn't on the glibc mailing lists.

This was not a code change, it was a change in the automake configure script to no longer pass in the argument to ld to include the old hash section when building glibc.

Normally no library/application dev ever sees a change like this as a ABI/API change, but it looks like the glibc devs will do from now on.

Well I just had one example experience (with xdg-desktop-portal, apologizes if they are an exception and not the norm for the standards of C libraries), I try to stay away from languages like C just as it doesn't really seem to click with me like a lot of other languages have (not to mention there are languages like Rust that some say will replace C and while I don't like rust either, it is leagues better for clicking with me). Also yeah, that makes a lot more sense as I was very confused by DT_HASH being in a build config file and not a function in the code when I saw the commit so again, thank you for clearing that up.

no probs, xdg-desktop-portal looks to be a 3d party tool for flatpak and unfortunately many such well intended extra tools are very rarely well documented.

To experience the glibc documentation just open a terminal and type in say "man dlopen" and see just how much information they have on that single function.

Yeah, I tried that then I thought `man elf` and there is a page, is this from glibc's documentation or something else as if they have control over that man page then they should definitely change this portion
 
       d_tag  This member may have any of the following values:

              DT_NULL     Marks end of dynamic section

              DT_NEEDED   String table offset to name of a needed library

              DT_PLTRELSZ Size in bytes of PLT relocation entries

              DT_PLTGOT   Address of PLT and/or GOT

              DT_HASH     Address of symbol hash table
to
       d_tag  This member may have any of the following values:
              ...
              DT_HASH     [s]Address of symbol hash table[/s] PLEASE FOR THE LOVE OF GOD DO NOT USE THIS AND INSTEAD USE DT_GNU_HASH IN THE FUTURE, PLEASE USE ANYTHING OTHER THAN THIS
and then problem solved but it is possible this man page is not in their control but if it is, I propose to add my addition to it lol

Yes the elf man page looks to come from not glibc since it does not cover DT_GNU_HASH, it looks to be from the kernel and have a git page here: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git [External Link] and I can see that DT_GNU_HASH is still not in the elf(5) page in MAIN/HEAD.

However I guess that this could be problematic on another level as well since not only is glibc not the only libc out there for Linux but it is also not the only shared object and this man page covers the ELF format itself and not just the one supported by the glibc ld binary.

View this comment - View article - View full comments