As part of the ongoing 17th anniversary celebration over on GOG.com, they've announced the release of the Tomb Raider Definitive Survivor Trilogy.
This includes Tomb Raider GOTY, Rise of the Tomb Raider: 20 Year Celebration and Shadow of the Tomb Raider: Definitive Edition. With the later two now included in the GOG Preservation Program, the GOG team said "We’re thrilled to welcome these fantastic titles to our catalog and to give them the GOG Preservation Program treatment, ensuring they remain DRM-free and in their best form now and for generations to come. One of the coolest things we’ve done is making the online features work offline, giving you a smooth, fully DRM-free experience. Check out the changelogs on the games’ pages!".
Really great to see more games come to GOG and to be preserved DRM-free.
We've got many more days left until the celebration sale ends on October 7th, so it will be interesting to see what other surprises they have coming to their store as something will be announced each day.
Head over to GOG.com for all the deals in their big sale.
They mostly seem to do mobile stuff now. While Aspyr moved to do remasters. Things sure have changed a lot in the last few years.
Isn't that what Valve does with their Steam runtime containers?Yes that is exactly what they do, one issue is however that there is only so much 3d party dependencies that Steam can manage in their runtimes plus the fact that those runtimes gets older and older and at some time one simply have to move on in order to allow new games to be allowed to use new features.
The major problem here is that Linux is made for open source development which is in stark contrast with how closed source games wants things to work in combination with (and this is not Linux specific) that close to every single library writer (with the exception of glibc) does not care for forwards compatibility.
Aka libraries can be written so that if your application is linked with glibc 3.4 but is now running on a system with glibc 4.5 and a function that you use foobar() have changed between those versions then your application would still be linked with the 3.4 version inside the 4.5 version of glibc. The reason why no one besides glibc supports this is because it is far from trivial to do (aka we would need better tools to handle this).
Another route one can do is what SDL have done as of SDL 3.x where they simply create a small 2.x shim that on the outside looks like 2.x to all applications that are linked with it but inside translates every call to the 3.x library. That way the SDL API/ABI can change from version to version but all old games/applications can not only be still supported but also actually use the new version (which improves security and can automatically add support for new things like Vulkan, pipewire and so on).
The problem ofc is that the world of dependencies are larger than glibc and SDL. So distributing your game with 100% of your dependencies bundled (aka flatpak) is another solution and actually how games are already distributed on Windows (which is the true reason why old Windows games still work today and not the myth that ABI/API:s on Windows are set in stone [remember that many games on Windows use SDL and similar open libs as well]).