Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Ah, no wonder Turok's explosions looked like they were full of pollution!
  • 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?

  • 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?

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

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

    by rasz
  • > 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.

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

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

  • 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.
  • RMS interjection reference was chef's kiss.
  • 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.
  • This is of course why we have audio compressors that lower everything while it’s loud and bring it back up when it’s quiet and try to do it quickly but without anyone noticing too much. It’s theoretically possible the same trick could work on the N64, except it would require & cost extra math ops that weren’t there.
  • 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.

  •   > 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 ^^
  • Discussed a bit more here in 2017-2018: https://forums.nesdev.org/viewtopic.php?t=16414