Godot: A Collaboration with Google and the Forge(godotengine.org) |
Godot: A Collaboration with Google and the Forge(godotengine.org) |
Very nice of Google to support Godot this way. Looking forward to a new wave of Android games with great performance and minimal battery drain.
For the Vulkan implementation? Probably not. IIUC Android uses a different driver stack than GNU/Linux. Only the very core layers are shared.
But indirectly more game engines supporting Vulkan will raise interest in progressing and optimizing Vulkan, so there will probably be indirect effects.
The problem with the desktop/laptop linux (I am excluding the deck), is msft monopoly on desktop/laptop default installation.
It is a circular dependency to break: windows gets the games because it is mass installed by default, and windows is mass installed by default because it gets the games.
Breaking that circular dependency means a saner alternative to windows to invoke the ultra-hardcore regulation which would be required. Problem, massive and mainstream elf/linux distros out there are no less-worse than windows, and are mostly hostile to binary distributions which are games (ABI stability is stellar better on windows than on elf/linux).
You need to dicipline glibc/gcc devs first (easy out-of-the-box backward ABI support in the toolchain and not that symbol per symbol version handling pain with the binutils gas .symver directive), and make more "common" software package statically link friendly or "app internal packaging friendly" (collisions of app internal shared lib symbols with system symbols).
That has been the case for 10+years and it is still so much accute with so much nothing pertinent being done, I start to think about conspiracies: I am questioning for who those glibc/gcc devs are actually rolling for...
Until I read what it was actually about, with the headline alone, I felt a bit of dread, worrying that google would get involved and destroy yet another good thing. Even surprised myself at how quickly my gut reacted like that.
A bummer for me. Maybe they can also work with Google and Microsoft to improve .NET support?
Honestly one of my current fears is that they focus on c# integration in place of improving gdscript support (the integrated ide is not specially comfy, and static typing support still lack some feature, collection wise in particular. but nothing really awfull).
And I am not working as a game developer anymore, so I prefer a lighter game engine when doing small projects.
I would argue that someone who starts programming on gdscript today would be able to transition into Python with little to no overhead.
Steam/Epic/et all. could just host own package registry for games, and there is no conflict with major Linux distributions about binary distribution.
On that case developers can bundle their games as they want, and end-users just use the package manager.
If you look how Steam works under the hood in Linux, it also manages dependencies for each game separately instead of using system libraries in the most cases.
Collabora "pressure-vessel" (used by valve) is limited as it does not follow the ELF ABI for all ELF binaries, and does take of lot of shortcuts for provider software packages it must import (datafile locations, critical environment variables, etc), and if you don't have "ubuntu", you are done for: I have often arguments with one "pressure-vessel" devs because it is breaking my distro even though it is very vanilla and simple, but not "ubuntu" breaking many of their "shortcuts".
And games would like to run en elf/linux distros without "pressure-vessel" (as far as I know, is not open source), as a set of clean ELF binaries.
But there is light at the end of the tunnel: engines, like godot, unity, UE5 (I think) seems very carefull about ABI issues on elf/linux and the game devs don't need to worry about cherry picking backward symbol version, avoid symbol collision with system ones as it is done for them by engine devs.
But you have engines which expect too much from the user system, that beyond video game core libs/interface: like electron (google blink), which expects a specific version of GTK+ on the user system... so the end of the tunnel is still far away for them.
Steam provided libs seems to be from Ubuntu, but the host does not need to be? Or what did you mean.
I used to make OCI containers from games and run them in Docker/Podman, since there were a lot of GPU specific driver issues, so I could easily swap between different drivers. But I did not notice any issues when running games with Arch or other distros.
Edit: Pressure vessel seems to be open-source
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/t...
Additionally thanks to Proton, Valve is doing nothing less than supporting Windows/XBox game studios to not bother at all, as Valve does the required work anyway.
Shabby and extremely expensive mitigation to compensate for many, not all, game devs.
The rest of Proton is open source and is at its core a distribution of wine + dxvk.
You'll see DLLs with names like Windows DLLs, but they come from Wine, not Windows, and are reimplementations.
If wrong, why valve is not using directly wine/vkd3d and/or not backporting anything?
So to work around ABI instability from the glibc/gcc, you were building a container for each game you wanted to play, this is obviously past the point of being reasonable.
Weird, I did already clone this repo. I could not find pressure vessel code, I guess I missed it??? (BTW, this is a gigantic project, bad omens).
That was my initial reasoning about functional/declarative package managers. They can reach the same but without making full blown containers.
It is inappropriate to consider those containers compared to actually doing something about this backward ABI handling in the toolchain for inexperienced devs on elf/linux (those coming from windows). This is technically more reasonable, with a abysmal difference.
As you would not need proton but only wine/vkd3d. And I have a recent build of wine/vkd3d, hardly anything works.
Does it mean valve is not backporting in wine/vkd3d?
It might take some huge effort (and time) to convince the devs. Especially, since development is going towards LLVM ecosystem. Linus prefers compailing Linux with clang these days.
When the ABI handling works well, you could still use the same principles for package managment.
- educate the devs on the matter. Those not using an engine already taking of that (this reduce by A LOT the amount of devs to teach).
- work on a toolchain switch to link with version symbol names from a backward ABI, easily (not having to manually enumerate all version symbol names and use the binutils gas .symver directive, or install a 10 years old distro). And a toolchain which does default to -static-libgcc, -static-libstdc++ (when c++ is used) and -ftls-model=global-dynamic while we are at it (in order to spare those expensive static TLS slots).
I do consider that gcc and clang(llvm) are lost for sane open source. Their absurd and grotesque size and complexity make them more toxic than anything else. Look at tinycc, cproc/qbe, simple-cc/qbe.
Here's what Lutris does for cyberpunk for example: https://lutris.net/games/install/30805/view
Creating a few directories, installing a specific version of MFC and running galaxy with some flags to skip incompatable launcher updates.
I guess the win64 gog galaxy client does update the game to its latest patch.
Come on, nobody has to be proud of that.