Ok, but it Czechia by and large you have Czech people paying for the welfare of other Czech people. On the other hand in the US, you would have mostly white and asian people paying for the welfare of mostly blacks and latinos. No wonder they don't want such a system. Like it or not, solidarity needs kinship, especially when it's your money on the line.
More like third-party software (Slack, Figma, VSCode, anything web-based) is getting even more bloated as their engineers' machines get upgraded to M1 Pros.
RCS is inferior to iMessage simply because it doesn't work on tablets and desktop computers. Since RCS is tied to mobile carriers, who don't want to give up control over those juicy messages, the problem will persist forever.
iMessage is device centered - your messages are just relayed to desktop by the mobile messaging app. Android messages can do this too [1], So can Samsung [2]
120 years ago we knew that some things can fly, because we saw birds. We just had to figure out how to do the same with humans.
On the other hand, we have never encountered anything in nature that goes faster than the speed of light. That's a pretty good hint that it's impossible to do so.
This is effectively what the vertex shader modification would do -- the same trick that ANGLE does: gl_Position.z = (gl_Position.z + gl_Position.w) * 0.5;
This is the same as modifying a projection matrix -- you're doing the same post-multiply to the same column. But note that there's no guarantee there's ever a projection matrix. Clip space coordinates could be generated directly in the vertex shader.
Remember that this translation needs to happen at the graphics driver level. For fixed-function OpenGL where the application actually passes the graphics driver a projection matrix this would be doable. But if your application is using a version of OpenGL newer than 2004, the projection matrix is a part of your vertex shader. The graphics driver can't tell what part of your shader deals with projection, and definitely can't tell what uniforms it would need to tweak to modify the projection matrix -- many shaders might not even have a projection matrix.
I know. But the second sentence of the article starts with:
"Neverball uses legacy “fixed function” OpenGL."
But also you could simply remap the Z coordinate of gl_Position at the end of the vertex stage, do the clipping in [0,1] range, then map it back to [-1,1] for gl_FragCoord at the start of the fragment stage.
Sure, it'd work for Neverball, but the article is clear that they're looking for a general solution: something that'd work not just for Neverball, but for all OpenGL applications, and would ideally let them give applications control over the clip-control bit through OpenGL/Vulkan extensions.
> But also you could simply remap the Z coordinate of gl_Position at the end of the vertex stage, do the clipping in [0,1] range, then map it back to [-1,1] for gl_FragCoord at the start of the fragment stage.
Yes, that was the current state-of-the-art before this article was written:
> As Metal uses the 0/1 clip space, implementing OpenGL on Metal requires emulating the -1/1 clip space by inserting extra instructions into the vertex shader to transform the Z coordinate. Although this emulation adds overhead, it works for ANGLE’s open source implementation of OpenGL ES on Metal.
> Like ANGLE, Apple’s OpenGL driver internally translates to Metal. Because Metal uses the 0 to 1 clip space, it should require this emulation code. Curiously, when we disassemble shaders compiled with their OpenGL implementation, we don’t see any such emulation. That means Apple’s GPU must support -1/1 clip spaces in addition to Metal’s preferred 0/1. The problem is figuring out how to use this other clip space.
