Quoting: Luke_NukemFrom Ryan's blog:

Here's what you need to know about Nightdive: instead of shipping this in DOSBox or something, they rewrote the assembly to be portable, 64-bit clean C++11. Nightdive is hardcore like you wouldn't _believe_.

Holy shit! That's crazy... Sure, assembly is bare metal fast, if you're able to produce better code than a compiler can. Which I guess in the mid 90's probably wasn't unheard of.

Yes back in 1994 it was not problem to outperform a compiler by far. Also you basically targeted the 80486 or first Pentium processors and they contained very little of the "magic" that compilers are far more better to utilize. Since then processors have increased in complexity and compilers have gained tremendous optimizations.

View this comment - View article - View full comments

Quoting: LinasAnybody brave enough to try it on AMD and post the results here, so I can make a risk-free purchase? ;)

Works flawless for me on my RX480 and Mesa 17.2.2

View this comment - View article - View full comments

Quoting: razing32

Quoting: GuestI have never played any similar horror game but it can be a fun game.

Have you tried Lone Survivor ?

EDIT : I could swear this had linux support but cannot find any trace on GOG/Steam

AFAIK Lone Survivor was only released for linux in a Humble Bundle (that's how I got hold of it anyway).

View this comment - View article - View full comments

Quoting: razing32I don't get the Steve Balmer quote tbh :huh:

Also kinda sad this game is so broken at release and so far from what GTA was .

View video on youtube.com

View this comment - View article - View full comments

Works mostly fine here on my AMD Rx480 on Mesa-17.30.0-devel (Padoka PPA), the only thing that does not work is the cutscenes, there are sound but no video for some reason. Only 6 hours in at the moment and have not made it further than Sector 3 but oboy is this one fun piece of a game!

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.UltraIf it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 [External Link] ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

That method is completely impractical - you would end up having hundreds of symver statements, and then it is no guarantee things would work properly. Similarly you would have to cook up the symvers for any library you wanted to build.

So then we are back to how we have always done things like this, keep a chroot around with those old versions of libs and compilers and build your stuff there. Now a days people perhaps use various containers for this instead, but I'm not there yet :)

View this comment - View article - View full comments

Quoting: GuestBy far one of the biggest issues with libs on Linux is glibc versioning. While they are not supposed to break the ABI, they frequently do. Making sure your game is compiled to use a sufficiently older version is a nightmare as well - you basically have to build your own GCC toolchain. I have found no other way of doing it.

IMO an rpath in the executable is a far better solution than manually dicking about with LD_LIBRARY_PATH. This way you would only have to have an rpath like "./libs.x86_64/" in your 64 bit executable, and "./libs.i386/" in your 32-bit one. A launch script using "arch" to identify whether the 32 or 64 bit executable should be launched takes care of the rest.

It is true that the Steam Runtime could use updating, however this would introduce problems as well for the same reason as using the system libraries introduces problems.

If it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 [External Link] ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.Ultra#1 have existed on Linux since day one. This is where the semantic versioning of the shared library kicks in, unfortunately not everyone who writes shared libraries follows the rules for semantic versioning and simply put their actual version there.

No it hasn't, not as I describe. Semantic versioning is basically naming symbols in a particular way, but then the programmer has to go to a lot of effort to explicitly bind to those symbols rather than the library's default ones.

Also .so has no version number embedded in it - this is only actually ever indicate by the file name, which is arbitrary and can be modified too easily to falsify or remove this information. It would be better if it was explicitly stated inside the ELF file.

Are you talking about linking with an older version of a lib than what you have installed? Because by default the linker (when compiling) will bind to the SONAME version of the library that you have installed.

The SONAME is also not only in the filename but also stored inside the ELF file:
f.ultra@ubuntu:~$ objdump -p /usr/lib/x86_64-linux-gnu/libmysqlclient.so | grep SONAME
  SONAME               libmysqlclient.so.18

When you try to run an application linked with this on a machine which only have .so.17 or .so.19 then ldd will fail since your application needs the v18 ABI interface of this library. I don't really understand what it is that your extended version from Mach-O is supposed to do more than this anyway, it cannot make your application use v17 or v19 since it cannot know what it is that have changed in between those versions.

So I might misunderstand what you are saying, so please enlighten me!

View this comment - View article - View full comments

Quoting: GuestThe problem with the "just ship all your dependencies" argument is how far do you take it ? A simple example, we need to ship libcurl. If we want https support, that typically depends on OpenSSL. Do we now have to ship OpenSSL ? What about the things OpenSSL depends on ?

Say we have a GTK3 UI somewhere. Do we ship the whole of GTK3 and all its dependencies ? That's pretty large. You're probably thinking "but everyone will have GTK3" - not so. Some people use setups which are exclusively Qt, or GTK2.

"Just statically link" is also a bad idea - that doesnt solve anything, and in fact it makes future compatibility WORSE because now you cannot replace the older versions of libraries at all. If there's a security issue in the old build, you're stuck with it. Not to mention if you are a complex game (like ARMA 3) then statically linking libs is a huge waste of VM space.

IMO, the Linux runtime linker (ld.so) needs support for two things:

1) Library versioning *at the load stage*, with embedded version numbers in the library files themselves. The method Mach-O uses of dual version numbers - library version and ABI compatibility version, should be adopted. It's easy to add to ELF.

2) Weak linking. This means that you can specify you want to link to a library IF it exists, but still run if it doesn't - you can check at run time if the library loaded or not. Currently this has to be implemented manually with dlopen/dlsym, and it's a lot of hassle.

#1 have existed on Linux since day one. This is where the semantic versioning of the shared library kicks in, unfortunately not everyone who writes shared libraries follows the rules for semantic versioning and simply put their actual version there.

View this comment - View article - View full comments

Quoting: silmeth

Quoting: F.UltraIf only writers of shared libraries would think more about backwards compatibility...

It would suffice if they followed semantic versioning with regard to their libraries’ APIs – one would know which shared versions are compatible. Some libs would have a few hundred new major versions every year – but at least it’d be obvious that every game needs its own separate copy of it in its own version.

At least until we dive into compiled C++ libraries where the version of the compiler that compiled the library and a game binary matters, as C++ has no stable ABI (so library compiled with newer gcc might, and probably will, stop working with old executable).

Following the semantic versioning would most definitely help yes, but I see many libraries that make completely unneeded changes to both API and ABI.

Once in a while I think that whenever a library writer creates a version that is no longer ABI compatible then they should be required to write a shim library for the previous version that uses the new version, that way security fixes and so on would still be applied to the users of the old version and distributions could install all the hundreds of shims when you install a library (since all the old versions are just small shims they should be very small in size so the overhead should not be that great) or perhaps as a libxxx-shim package just like we have -dev/-devel packages on most distributions.

View this comment - View article - View full comments