I thing the endgame is lossless PNG with 16bit color components with basic compression like gzip or at best bzip2. Or a format without the weirdness of PNG 'line based loading' which is obsolete nowdays. The "expensive part", apart from the compression algorithm, being the meta data storage without kludge.
>without the weirdness of PNG 'line based loading' which is obsolete nowdays
How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.
With lossless compression and the "modern" internet, it is a matter to indeed allocate more to image bandwidth, from an internet point of view, that would be the price of 'end game' image format quality (lossless and 16bits per component).
You are missing critical metrics: the absolute values which are now very important in our super high speed internet and beyond powerfull consumer hardware.
It is a bit like linux on steam: 6%... but millions, ratio is little, but the absolute is so huge that it you cannot ignore anymore their market value (like macOS though).
These days I favour lossless WEBP instead of PNG. I often save around 30%~40% of file size compared to PNG, especially when the PNG is encoded with lots of bits per pixel (i.e 48 bits or 24 bits).
From a panel point of view, this is "end game": for a color component, you can get one discret color component value per line/column. Color banding is gone with a good panel in sRGB on large chunk of the panel with very gradient oriented image data.
GTA 6 will probably be software as a service to some extend, namely the code will change all the time at somewhat high frequency for any port. If I am not too mistaken a big chunk of the GTA community does play online.
"AI porting" able to follow? (If that AI thing is actually true)
Unless GTA 6 is not hardwired to AMDGPU hardware at release, if they have a cross-platform engine, for PC, it is to click the right export button... and do the QA and debug to please the various 3D drivers out there.
If we manage to keep the dev tantrums/planned obsolescence at bay, all you will need, if the game devs or game engine devs are competent, is a lean elf(glibc)/linux distro: a set of glibc libs (interwined with the system ELF loader), the vulkan loader, libasound, a wayland compositor, and related linux userland interfaces.
In the future, we can expect a much simpler file format to replace ELF for CPU executables and dynamic libraries (ELF is beyond obsolete and overkill on modern hardware achitectures and its complexity is source of many issues), and maybe pure and standard GPU hardware command instanciable ring buffers, but that's much further away in the future, as we "don't know yet" (but we do for CPUs), and we still could get GPU vendor specific hardware command instanciable ring buffers (it seems this how the PS5 works).
If the API is c++ based you have to statically link it to the engine since the chosen c++ runtime is statically linked to the engine binaries.
You cannot ship as a shared c++ runtime since it would conflict with a possible version installed on the user distro (version of the gcc libstdc++, version of the clang runtime, intel?, or none see below).
To avoid c++ ABI issues, distros may statically link their c++ runtimes (clang[c++ and compiler versions]/gcc[c++ and compiler and versions]/intel[c++ and compiler versions]/etc)... if they need any (and the new c++ to C transpiler may have some significant impact in the near future).
(BTW, is the c++ intel compiler still shipping??)
If the API is "C" based (aka core platform ABI), no issue, just statically load only the common glibc libs (ELF DT_NEED entries) and dynamically load (libdl/dlopen/dlsym/dlclose) everything else (private libs, or system interface shared libs), and you are good to ship. A word though: wayland code with its libxkbcommon are statically linked, do not reproduce the same mistakes than with x11).
This is required for broad distro support [and long term support].
Basically, game binaries should be "-static-libgcc -static-libstdc++ --enable-new-dtags" everywhere, statically load _ONLY_ common glibc libs (and with "old" symbol versions, see binutils ld documentation, the 2nd part of the VERSION documentation page), and dynamically load everything else.
I have been inspecting many recent godot4 games on steam: all had "correct" binaries to maximize broad distro loading support on the long run.
The current issues: some games are written in microsoft rust which toolchain is still unable to statically link libgcc (see tinyglade game). Or some unity versions which "forgot" the '-static-libgcc' compiling/linking options, and even forgot to statically link their libz Oo.
If valve could do just that with the binaries of their client and their games... They can keep their 'runtimes' for old broken games but should have 'correct' binaries for everything else on their side (and valve still has to port the final 32bits reaper command to 64bits for clean 64bits support, hopefully I did not miss other 32bits binaries). Forcing distros to compile that user namespace in their linux kernel is quite "inappropriate", better keep that optional for those broken games only.
If your API is c++ based, you ship a static lib. If the game engine is "closed" source, you also a have static lib (or a set of) for the game engine too, and "exporting" is actually linking (basically a binutils ld invokation). Ofc, you better use the same c++ compiler _VERSION_ than the game engine devs did use, or you are good for c++ hell.
If your API is C based (or core platform ABI), and you should design such API for interop with any framework anyway, you can ship a shared lib (but it has to statically load only the common glibc libs, and that with "old" symbol versions, and the other things too, see my previous post).
The gogol agenda of blocking and excluding all web engines not part of their whatwg cartel is moving forward, at a slow pace, steathly.
gogol search was blocked to all noscript/basic HTML browsers last year. I recall people that a few years before, they removed their gmail basic HTML interface not long after that their account creation (then login) would require one the abominations of the whatwg cartel.
I have been working around the gogol search engine since then and my email is now self hosted without DNS (IPv6 literals, see RFC). Yeah, most DNS registrars are now gated by the whatwg cartel web engines in some way, this is the net effect of big corpos toxic behavior.
Hopefully for RAM and RISC-V ultra-performant µarchitectures.
Yeah, I am advocating for I would like to happen (hopefully INTEL and AMD will put a RISC-V decodecs on their µarchitecture out of good will... yeah since they hold the x86 and x86_64 IP then excluding all alternatives de-facto... the incentive is.. negative.
If I am not mistaken, EU is currently pouring money in defence. For defence needs, one state-of-art chip build line is enough... the EU armies could even share it.
reply