3 ms·

Additive Blending on the Nintendo 64

181 points by ibobev 6mo ago

andrekandre 6mo ago
> Did you ever wonder why explosions and other effects looked so much cooler on the original PlayStation than they did on the Nintendo 64? yes! fantastic article and now i finally know why ^^
1024bits 6mo ago
Discussed a bit more here in 2017-2018: https://forums.nesdev.org/viewtopic.php?t=16414 https://forums.nesdev.org/viewtopic.php?t=16414
keyle 6mo ago
Interesting so the N64 had a more flexible color blending process, and in doing that no clamping. So the 'good explosions' were possible on N64 if you did the blending+clamp by hand?
- boricj 6mo ago
  What I'm getting from the article is that to work around the lack of clamping in the RDP, it is set up for additive rendering with low intensity onto a 32-bit framebuffer to make use of its higher dynamic range. But that's way too dark for display, so the RSP is used to scale and clamp this down to a 16-bit framebuffer that is then displayed. Using the RSP makes this possible at a reasonable framerate, but it requires writing custom microcode for it and Nintendo didn't provide the necessary tools or documentation back in the day. My read is that this makes pseudo-HDR rendering techniques possible on the N64.
  - Wowfunhappy 6mo ago
    For what it's worth, Wikipedia says that some official N64 games did use custom microcode: https://en.wikipedia.org/wiki/Nintendo_64#Graphics https://en.wikipedia.org/wiki/Nintendo_64#Graphics > Nintendo 64 games running on custom microcode benefit from much higher polygon counts and more advanced lighting, animation, physics, and AI routines than its competition. Conker's Bad Fur Day is arguably the pinnacle of its generation combining multicolored real-time lighting that illuminates each area to real-time shadowing, and detailed texturing replete with a full in-game facial animation system.
    - xgkickt 6mo ago
      Probably more accurate to say the custom microcode tools were not given to third party developers. From what I remember, you had to list the microcode used on your submission form, and Nintendo checked for it in your ROM. Did some third parties make custom microcode? Highly probable, but I do not know how many were able to ship with it.
      - Wowfunhappy 6mo ago
        Huh. Well, Conker's Bad Fur Day wasn't first party, but I guess Rare probably got special treatment?
        xgkickt 6mo ago
        Yes, 2nd party privileges.
        486sx33 6mo ago
        Rare got all kinds of privileges, heck they developed their own unofficial dev kit. https://www.behindthecode.ca/rareware-n64dev/ https://www.behindthecode.ca/rareware-n64dev/
        deleted 6mo ago
        [deleted]
      - tadfisher 6mo ago
        Factor 5 famously customized microcode in essentially all of their N64 games. According to some emulator devs, the F3DEX source was available in the SDK and intended to be customized [1], so it's interesting to hear a different account . 1: https://github.com/gonetz/GLideN64/wiki/The-masterpiece-graphic-microcode-behind--the-Nintendo-64-version-of--Indiana-Jones-and-the-Infernal-Machine-and-Star-Wars-Episode-I:-Battle-for-Naboo https://github.com/gonetz/GLideN64/wiki/The-masterpiece-grap...
        xgkickt 5mo ago
  - amlib 6mo ago
    >My read is that this makes pseudo-HDR rendering techniques possible on the N64. It is already possible, modern n64 techniques and microcode are scarily good: https://www.youtube.com/watch?v=XP8g2ngHftY https://www.youtube.com/watch?v=XP8g2ngHftY (Tiny3D - HDR & Bloom / Post-Processing [N64 Homebrew])
applfanboysbgon 6mo ago
> Did you ever wonder why explosions and other effects looked so much cooler on the original PlayStation than they did on the Nintendo 64? Begging the question, aren't we?! Of the examples displayed, I much prefer Star Fox's fx to Silent Bomber's. They fit the game's style well, and the explosions when killing an enemy are just the right amount of rewarding, while not being so ostentatious as to be distracting. SF64 nailed the game feel of destroying enemies, those small little intangibles that make the game satisfying on a visceral level, as Nintendo is so good at doing.
- ricardobeat 6mo ago
  You missed the point, it is not about art direction. The effects in Star Fox have normal alpha blending and look "solid", you can see them as a floating poster board, while the PS ones actually look like light effects.
- deleted 6mo ago
  [deleted]
- Chazprime 6mo ago
  The Starfox explosions lack a realistic brightness level. They don’t appear to be emitting light the way the Playstation’s explosions do. Even the afterburner effect on Starfox’s ship looks muted.
- Wowfunhappy 6mo ago
  > Of the examples displayed, I much prefer Star Fox's fx to Silent Bomber's. They fit the game's style well ...I feel like the "style" you're reacting to is the "N64 style", which is to say that you've become habituated to seeing games built to the N64's specific limitations. If the N64 had launched with better alpha blending, then "N64 style" would include PS1-esque explosions, but it didn't, so you don't. It's like how people prefer 24 fps, because movies have long been recorded at 24 fps. Obviously, this is just my intuition and we'll never the know the alternate history. But objectively, I don't see why explosions which resemble physical spheres better fits the aesthetics of Star Fox. But, those sorts of explosions absolutely do evoke the N64. If I was creating an N64-esque indie game, I would want to avoid alpha blending.
omoikane 6mo ago
See also: https://en.wikipedia.org/wiki/Saturation_arithmetic https://en.wikipedia.org/wiki/Saturation_arithmetic
- flopsamjetsam 6mo ago
  From the Wikipedia article: > However, it is possible to implement saturating addition and subtraction in software without branches, using only modular arithmetic and bitwise logical operations that are available on all modern CPUs and their predecessors, including all x86 CPUs (back to the original Intel 8086) and some popular 8-bit CPUs (some of which implement the Z80 instruction set) are still in production. Does anyone know what the implementation of this is, without conditional moves?
  - windenntw 5mo ago
    Here is one in plain 68000 assembler. move.b #200,d0 move.b #100,d1 add.b d0,d1 ; 8th bit goes to X flag subx.b d0,d0 ; d0 = $00 or $ff depending on X flag or.b d0,d1 ; d1 = 255 if there was saturation You can do the same with all others that somehow store the 8th bit carry somewhere then allow using it for substraction.
deleted 6mo ago
[deleted]
atan2 6mo ago
Posted earlier this week: https://news.ycombinator.com/item?id=48067111 https://news.ycombinator.com/item?id=48067111
gblargg 6mo ago
It's the same issue you encounter with audio mixing. You have to clamp out-of-range values, even though they don't occur a lot. If you don't you get awful artifacts, and have to lower everything so that it can never overflow your range.
- atoav 6mo ago
  Gladly this isn't that much of an issue anymore since most audio mixing nowadays is done using floating point numbers (either 32 or 64 bits). Last week I made a test in Bitwig where I boosted a 0dBFS sine wave by 64dB into "clipping", exported it to 32 bit float wav, imported it again, reduced gain by 64dB and there the old sine was in all it's glory. Theoretically now with rounding errors and a loss of precision, but nothing audible. Of course as soon as you go into 24 or 16 bit fixed point representations (and you will have to eventually) that clipping becomes a problem.
  - Sharlin 6mo ago
    There should be little loss of precision exactly because floating point is by definition precision-invariant over most of its domain – ie. 1.23456*10^-30 and 1.23456*10^30 are essentially the "same" number. Precision loss normally only occurs when combining numbers of different magnitudes.
    - dahart 6mo ago
      To be pedantic (apologies), I’m certain you know this, but not everyone thinks about floats - precision loss is almost always occurring in practice with every floating point operation you do, and happens often even when combining numbers of exactly the same magnitude (exponent). They’re just very small losses on the order of 0.5 ULP on average, and it would take many many of those to add up to audible artifacts. It is sometimes possible, but quite rare to do any float math and have no precision loss, that only works if you can change the exponent without touching the mantissa, or in the narrow range of add & subtract operations where the exponents of the operands and the result are all the same. Multiplication is always rounding even when all input & output exponents are identical.
deleted 6mo ago
[deleted]
rasz 6mo ago
You know what else didnt support additive blending? S3 ViRGE decelerator, Matrox Mystique mistake, nor NEC PowerVR PCX 1/2, afaik not even Permedia 1/2. Another pain point was multiplicative blending missing in even more early 3d accelerators. Then came 3dfx Voodoo doing all the blending modes for free.
- Narishma 6mo ago
  > Then came 3dfx Voodoo doing all the blending modes for free. I'm pretty sure the voodoo came out before all the others you mentioned.
  - rasz 6mo ago
    Wasnt December 1995 Comdex premiere still a closed door dont look behind the curtain $80K SGI box showcasing what the chip will do? with actual boards shipping a year later starting October 1996. Flood began after 1997 ram price collapse dropping initial Voodoo1 $299 price down to $199. Virge announced same 1995 Comdex, shipping announced at May 1996 E3 $199 2MB cards https://web.archive.org/web/19961220000918/http://www.diamondmm.com:80/whats-new/press-releases/files/stlth3d-ships.html https://web.archive.org/web/19961220000918/http://www.diamon... Mistake shipped May-August 1996. Both failures were being benchmarked in the press in August 1996 https://groups.google.com/g/comp.sys.ibm.pc.hardware.video/c/68xBvwPsQ6U https://groups.google.com/g/comp.sys.ibm.pc.hardware.video/c...
rlopezcc 6mo ago
RMS interjection reference was chef's kiss.
aggakake 6mo ago
Ah, no wonder Turok's explosions looked like they were full of pollution!

181 points by ibobev 6mo ago

> Did you ever wonder why explosions and other effects looked so much cooler on the original PlayStation than they did on the Nintendo 64? yes! fantastic article and now i finally know why ^^

1024bits 6mo ago

Discussed a bit more here in 2017-2018: https://forums.nesdev.org/viewtopic.php?t=16414 https://forums.nesdev.org/viewtopic.php?t=16414

keyle 6mo ago

Interesting so the N64 had a more flexible color blending process, and in doing that no clamping. So the 'good explosions' were possible on N64 if you did the blending+clamp by hand?

boricj 6mo ago
What I'm getting from the article is that to work around the lack of clamping in the RDP, it is set up for additive rendering with low intensity onto a 32-bit framebuffer to make use of its higher dynamic range. But that's way too dark for display, so the RSP is used to scale and clamp this down to a 16-bit framebuffer that is then displayed. Using the RSP makes this possible at a reasonable framerate, but it requires writing custom microcode for it and Nintendo didn't provide the necessary tools or documentation back in the day. My read is that this makes pseudo-HDR rendering techniques possible on the N64.
- Wowfunhappy 6mo ago
  For what it's worth, Wikipedia says that some official N64 games did use custom microcode: https://en.wikipedia.org/wiki/Nintendo_64#Graphics https://en.wikipedia.org/wiki/Nintendo_64#Graphics > Nintendo 64 games running on custom microcode benefit from much higher polygon counts and more advanced lighting, animation, physics, and AI routines than its competition. Conker's Bad Fur Day is arguably the pinnacle of its generation combining multicolored real-time lighting that illuminates each area to real-time shadowing, and detailed texturing replete with a full in-game facial animation system.
  - xgkickt 6mo ago
    Probably more accurate to say the custom microcode tools were not given to third party developers. From what I remember, you had to list the microcode used on your submission form, and Nintendo checked for it in your ROM. Did some third parties make custom microcode? Highly probable, but I do not know how many were able to ship with it.
    - Wowfunhappy 6mo ago
      Huh. Well, Conker's Bad Fur Day wasn't first party, but I guess Rare probably got special treatment?
      - xgkickt 6mo ago
        Yes, 2nd party privileges.
        486sx33 6mo ago
        Rare got all kinds of privileges, heck they developed their own unofficial dev kit. https://www.behindthecode.ca/rareware-n64dev/ https://www.behindthecode.ca/rareware-n64dev/
      - deleted 6mo ago
        [deleted]
    - tadfisher 6mo ago
      Factor 5 famously customized microcode in essentially all of their N64 games. According to some emulator devs, the F3DEX source was available in the SDK and intended to be customized [1], so it's interesting to hear a different account . 1: https://github.com/gonetz/GLideN64/wiki/The-masterpiece-graphic-microcode-behind--the-Nintendo-64-version-of--Indiana-Jones-and-the-Infernal-Machine-and-Star-Wars-Episode-I:-Battle-for-Naboo https://github.com/gonetz/GLideN64/wiki/The-masterpiece-grap...
      - xgkickt 5mo ago
- amlib 6mo ago
  >My read is that this makes pseudo-HDR rendering techniques possible on the N64. It is already possible, modern n64 techniques and microcode are scarily good: https://www.youtube.com/watch?v=XP8g2ngHftY https://www.youtube.com/watch?v=XP8g2ngHftY (Tiny3D - HDR & Bloom / Post-Processing [N64 Homebrew])

applfanboysbgon 6mo ago

> Did you ever wonder why explosions and other effects looked so much cooler on the original PlayStation than they did on the Nintendo 64? Begging the question, aren't we?! Of the examples displayed, I much prefer Star Fox's fx to Silent Bomber's. They fit the game's style well, and the explosions when killing an enemy are just the right amount of rewarding, while not being so ostentatious as to be distracting. SF64 nailed the game feel of destroying enemies, those small little intangibles that make the game satisfying on a visceral level, as Nintendo is so good at doing.

ricardobeat 6mo ago
You missed the point, it is not about art direction. The effects in Star Fox have normal alpha blending and look "solid", you can see them as a floating poster board, while the PS ones actually look like light effects.
deleted 6mo ago
[deleted]
Chazprime 6mo ago
The Starfox explosions lack a realistic brightness level. They don’t appear to be emitting light the way the Playstation’s explosions do. Even the afterburner effect on Starfox’s ship looks muted.
Wowfunhappy 6mo ago
> Of the examples displayed, I much prefer Star Fox's fx to Silent Bomber's. They fit the game's style well ...I feel like the "style" you're reacting to is the "N64 style", which is to say that you've become habituated to seeing games built to the N64's specific limitations. If the N64 had launched with better alpha blending, then "N64 style" would include PS1-esque explosions, but it didn't, so you don't. It's like how people prefer 24 fps, because movies have long been recorded at 24 fps. Obviously, this is just my intuition and we'll never the know the alternate history. But objectively, I don't see why explosions which resemble physical spheres better fits the aesthetics of Star Fox. But, those sorts of explosions absolutely do evoke the N64. If I was creating an N64-esque indie game, I would want to avoid alpha blending.

omoikane 6mo ago

See also: https://en.wikipedia.org/wiki/Saturation_arithmetic https://en.wikipedia.org/wiki/Saturation_arithmetic

flopsamjetsam 6mo ago
From the Wikipedia article: > However, it is possible to implement saturating addition and subtraction in software without branches, using only modular arithmetic and bitwise logical operations that are available on all modern CPUs and their predecessors, including all x86 CPUs (back to the original Intel 8086) and some popular 8-bit CPUs (some of which implement the Z80 instruction set) are still in production. Does anyone know what the implementation of this is, without conditional moves?
- windenntw 5mo ago
  Here is one in plain 68000 assembler. move.b #200,d0 move.b #100,d1 add.b d0,d1 ; 8th bit goes to X flag subx.b d0,d0 ; d0 = $00 or $ff depending on X flag or.b d0,d1 ; d1 = 255 if there was saturation You can do the same with all others that somehow store the 8th bit carry somewhere then allow using it for substraction.

deleted 6mo ago

[deleted]

atan2 6mo ago

Posted earlier this week: https://news.ycombinator.com/item?id=48067111 https://news.ycombinator.com/item?id=48067111

gblargg 6mo ago

It's the same issue you encounter with audio mixing. You have to clamp out-of-range values, even though they don't occur a lot. If you don't you get awful artifacts, and have to lower everything so that it can never overflow your range.

atoav 6mo ago
Gladly this isn't that much of an issue anymore since most audio mixing nowadays is done using floating point numbers (either 32 or 64 bits). Last week I made a test in Bitwig where I boosted a 0dBFS sine wave by 64dB into "clipping", exported it to 32 bit float wav, imported it again, reduced gain by 64dB and there the old sine was in all it's glory. Theoretically now with rounding errors and a loss of precision, but nothing audible. Of course as soon as you go into 24 or 16 bit fixed point representations (and you will have to eventually) that clipping becomes a problem.
- Sharlin 6mo ago
  There should be little loss of precision exactly because floating point is by definition precision-invariant over most of its domain – ie. 1.23456*10^-30 and 1.23456*10^30 are essentially the "same" number. Precision loss normally only occurs when combining numbers of different magnitudes.
  - dahart 6mo ago
    To be pedantic (apologies), I’m certain you know this, but not everyone thinks about floats - precision loss is almost always occurring in practice with every floating point operation you do, and happens often even when combining numbers of exactly the same magnitude (exponent). They’re just very small losses on the order of 0.5 ULP on average, and it would take many many of those to add up to audible artifacts. It is sometimes possible, but quite rare to do any float math and have no precision loss, that only works if you can change the exponent without touching the mantissa, or in the narrow range of add & subtract operations where the exponents of the operands and the result are all the same. Multiplication is always rounding even when all input & output exponents are identical.

deleted 6mo ago

[deleted]

rasz 6mo ago

You know what else didnt support additive blending? S3 ViRGE decelerator, Matrox Mystique mistake, nor NEC PowerVR PCX 1/2, afaik not even Permedia 1/2. Another pain point was multiplicative blending missing in even more early 3d accelerators. Then came 3dfx Voodoo doing all the blending modes for free.

Narishma 6mo ago
> Then came 3dfx Voodoo doing all the blending modes for free. I'm pretty sure the voodoo came out before all the others you mentioned.
- rasz 6mo ago
  Wasnt December 1995 Comdex premiere still a closed door dont look behind the curtain $80K SGI box showcasing what the chip will do? with actual boards shipping a year later starting October 1996. Flood began after 1997 ram price collapse dropping initial Voodoo1 $299 price down to $199. Virge announced same 1995 Comdex, shipping announced at May 1996 E3 $199 2MB cards https://web.archive.org/web/19961220000918/http://www.diamondmm.com:80/whats-new/press-releases/files/stlth3d-ships.html https://web.archive.org/web/19961220000918/http://www.diamon... Mistake shipped May-August 1996. Both failures were being benchmarked in the press in August 1996 https://groups.google.com/g/comp.sys.ibm.pc.hardware.video/c/68xBvwPsQ6U https://groups.google.com/g/comp.sys.ibm.pc.hardware.video/c...

rlopezcc 6mo ago

RMS interjection reference was chef's kiss.

aggakake 6mo ago

Ah, no wonder Turok's explosions looked like they were full of pollution!