There are loads of .BAK files as well, and diffing them with the actual file gives you some insight on what they were working on. (Like pre and post Counterstrike addon).
> 5.0 came out late during development of the chip, which turned out to be mostly compliant, with the exception of some blending modes such as additive blending which Jensen Huang later claimed was due to Microsoft not giving them the specification in time.
Not sure if this is the same thing I had, but on my Riva128 the alpha blending wasn't properly implemented. I distinctly recall playing Unreal Tournament and when I fired the rocket launcher there were big black squared with a smoke texture on them slowly rotating :D couldn't see where I was shooting :D
Yes, that would be an artifact of missing additive blending.
It simply means that each newly rendered polygon’s RGB values are added together with the pixel values already in the frame buffer. It’s good for lighting effects (although not a very realistic simulation of light’s behavior unless your frame buffer is linear light rather than gamma corrected, but that effectively requires floating point RGB which wasn’t available on gaming cards until 2003).
Iirc, Riva 128 only supports 8 of the 32 D3D5 blend modes, or something. Usually in the case of GPUs that don't support all blending modes the Direct3D HAL will attempt to compensate by using a different blending mode, or just give up and render opaque pixels. The results are usually pretty ugly. Riva 128 is one of the better ones for the era in this regard.
I doubt it required floating point rgb and, iirc, it came (for real) much later. GPUs used fixed point math behind the scenes for a long time. The only thing you need to get proper additive blending is saturation, so that you don't overflow, like on the N64.
You don't need floating point RGB for additive blending, but to get correct behavior when using additive blending for your light sources, you must use linear buffers and if you do that, the dynamic range of the scene won't fit in eight bits.
The blend operation happens on linearized values, so the frame buffer being gamma corrected is not a problem.
8-bit sRGB is a very good gamma corrected format.
I’m pretty sure this wasn’t available on early GPUs. Additive blending with glBlendFunc(GL_ONE, GL_ONE) or its D3D equivalent just summed the new fragment with the frame buffer value.
Accumulating into an 8-bpc buffer will quickly artifact, so whether it’s acceptable to only do the blend operation in linear light (accumulating into a gamma-corrected frame buffer) depends on how many passes you’re rendering.
COLORTERM is also a very weird thing. Most of the time I don't need it to be defined, but when using a screen session it suddenly looks very crappy when COLORTERM is set to truecolor. Removing the env var makes it look all normal again.
Tmux supports 24-bit color. I bit the bullet and switched a few years ago, and my muscle memory remains exactly the same. I'm incredibly happy with the power, flexibility, configurability, and reliability of Tmux.
If unsetting COLORTERM fixes the display problem then it is a program issuing 24bit colors but the terminal (in your case screen) not understanding the escape sequences.
Yep, just wanted to write that exact same reply. It was one or two weeks ago and asked for permission to unlink YouTube, GMail, etc... from each other (as I understood it, when "opting out", login with the same Google account will still work, but they're not allowed to share data for ad profiling, recommendations etc...)
> Your data from all Google services, regardless of whether they are linked, may still be shared across all services for certain purposes, like preventing fraud, protecting against spam and abuse, and complying with the law.
Tooltips are the worst kind of information providers in a website. First of all you don't know they're there, you actively need to search with your mouse cursor and wait to see something lights up. And then you can only read it, no way to copy/paste information out of it. Often they also cover up other information when they do popup, and most of the time the extra information they do provide is useless.
Tooltips should be removed entirely instead of fixing 22 year old bugs.
Yeah, I guess this is the answer. When I posted the question I had this[1] in mind, and was thinking of something like that with simplified labels maybe. But I guess the file structure is so organized it would explain itself to anyone interested in this kind of thing.
I'm not so sure about this. In the article he states:
> Once it became clear the intended law would likely pass parliament
and in the dutch version it sounds even worse to me:
> Na het verschijnen van het advies van de Raad van State is mij duidelijk geworden dat de verruiming van de bevoegdheden en de verschuiving van het toezicht niet meer ongedaan zullen worden gemaakt.
I can't really tell for sure if he thinks this law is here to stay, but me being a pessimist when it comes down to government, I think there is nothing temporary about this.
That doesn't mean the sentiment change behind the law isn't permanent, and it might (but I don't believe so) be a temporary law that is extended indefinitely.
But the law, as written and intended is temporary. I think that should factor into the discussion (as should the fact that sometimes people call a thing temporary whilst intending for it to be permanent).
It's not the system that is not supporting udev, it's the choice of the game developers how they compiled SDL .. without dependencies, and so without udev.
That's standard for game devs in the Linux world. The less dependencies you have to rely on the distribution for, the better - Windows stuff is either already present or shared OS-wide with binary backwards compatibility (=DirectX), so you can get away with shipping stuff that has a chance to run even 25 years in the future without major modification.
