[pavlov]

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).

[starfrost013]

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.

[msk-lywenn]

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.

[lightingthedark]

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.

[mungoman2]

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.

[pavlov]

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.