N64 additive transparency
Page 1 of 1

Author:  93143 [ Sat Aug 26, 2017 3:50 pm ]
Post subject:  N64 additive transparency

Apparently the blender did have an additive mode, but it didn't clamp the output. Assuming this is true, it explains a lot. The lack of additive transparency had a profound effect on the visual character of the system; if I could change one thing about the N64, this might be it.

Is this behaviour easy to change in microcode, or would you have to go the long way (load the framebuffer as a texture, do the addition and clamping in the render units) and kill your fillrate? Or is it outright impossible?

Author:  tepples [ Sat Aug 26, 2017 4:50 pm ]
Post subject:  Re: N64 additive transparency

As I understand it, RSP microcode is just a vertex shader and isn't intended to do things to individual pixels.

Author:  Espozo [ Sat Aug 26, 2017 7:11 pm ]
Post subject:  Re: N64 additive transparency

From what I've heard, Tepples is correct. If I'm not mistaken, the RSP gives the RDP different parameters for drawing something, (does the geometry) and the RDP renders it. Getting the RSP to actually draw anything (if it's possible at all) would probably be prohibitively slow. (It would have to be done in software.)

I'm surprised the lack of additive blending is what you would first change about the N64. Most people complain about the low resolution textures (small texture cache, although I think cartridge space had just as much to do with it) or the "Vaseline covered" video. (I have no idea what this is caused by, but it seems more prevalent is some games than others.)

Author:  93143 [ Sun Aug 27, 2017 12:23 am ]
Post subject:  Re: N64 additive transparency

The texture cache was twice the size of the one in the PSX, and as Rare showed it was certainly possible to work around it. Nintendo/SGI were just stingy with their tools. The RDRAM was high-latency, sure, but it was very fast and there weren't a lot of better options available at the time. I'm sure the CPU/RAM interface could have been improved, but I'm not a hardware engineer so I don't know what you'd have to sacrifice to do that. It'd be a major change for sure. The cartridge format had advantages and disadvantages vs. CDs, and the lack of FMV never bothered me; IIRC the N64 basically pioneered the "in-engine cutscene" for this very reason. And I'm pretty sure you could turn off both antialiasing and texture filtering if you really wanted to.

But the blender not clamping its output is just a straight-up dumb move. Take a look at this:

bodyharvest1.jpg [ 7.2 KiB | Viewed 1015 times ]

Or this:

naboo1.jpg [ 17.78 KiB | Viewed 1015 times ]

Notice how despite the fact that they look like they're from different generations, they both have the same problem. Faking it with alpha just doesn't cut it. The only thing that looks decent is pure white.

From the looks of things, the color combiner clamps its output (or at least it clamps the chroma key operation, and the description of the blender - which is immediately downstream of the color combiner - asserts that all the inputs are clamped), and the formula does look flexible enough to do additive transparency. Unfortunately it doesn't operate on framebuffer pixels, meaning you would indeed have to do this the long way. Maybe the really long way, if you can't convince the RDP to combine transformed and untransformed texture data...

Author:  calima [ Sun Aug 27, 2017 12:24 am ]
Post subject:  Re: N64 additive transparency

The gpu *can* be programmed to do fullscreen effects, it's that flexible. The RE2 port used it to do colorspace conversion in the FMVs, the article even includes the code.

Author:  93143 [ Sun Aug 27, 2017 1:37 am ]
Post subject:  Re: N64 additive transparency

What I mean is that you can't use the current framebuffer pixel directly as a source for the color combiner. That's the blender's job. It seems like if you want to do additive transparency with the color combiner, you have to get the framebuffer in the front end of the pipeline somehow, and the easiest way to do that is probably through the texture cache.

Now the question is: can you combine a transformed, perspective-corrected trilinear-interpolated texture map with a linear bitmap this way? If not, you might have to draw each additive object to a blank buffer and load it in together with the relevant section of the framebuffer to do the combination properly. (Maybe I should look into how environment mapping works.)

You could also just convert the scene to 24-bit (without expanding the RGB values) to give yourself some headroom for the blender, and then just clamp it back to 15-bit after drawing all the additive objects. But that only gives you enough room for about 7 whites stacked on top of a light background before it overflows...

The point is, all of this extra maneuvering costs fillrate, which is the bottleneck on the N64. It'd probably be okay for a modest number of objects, but a busy battle scene full of lasers and explosions could be a problem. As a non-expert, I'm not sure how much of a problem exactly, but if Nintendo/SGI had just clamped the output of the blender this wouldn't be an issue.

Author:  93143 [ Sat Sep 02, 2017 9:50 pm ]
Post subject:  Re: N64 additive transparency

I'm sorry if this seemed like a bit of a rhetorical question. It wasn't. The responses actually resulted in me getting [what I think is] a better understanding of how the RCP works, once I cross-checked what people were saying with what I thought I remembered from the manual.

So I guess I got what I asked for, if not exactly what I wanted.


The N64 is a bit frustrating for me, since I'm reasonably sure I will never be able to produce a game that maxes out the hardware. It's too much work. The SNES is on the border, but this... I maintain that BotW is probably possible on N64. The idea that I might be able to prove it some day - even with a team behind me - is laughable. That's just an example, but it's illustrative.

It's fun to read about the N64's internals, but I think I'll end up sticking to SNES. Just finishing my current project is a big enough challenge...

Author:  freem [ Sun Sep 03, 2017 8:23 am ]
Post subject:  Re: N64 additive transparency

93143 wrote:
I'm reasonably sure I will never be able to produce a game that maxes out the hardware. It's too much work

Only way I know of to do this is to go back in time and work with Rare on Perfect Dark.

Author:  Espozo [ Sun Sep 03, 2017 9:20 am ]
Post subject:  Re: N64 additive transparency

As good as Perfect Dark looks, It shouldn't make the N64 run at 12fps.

Author:  calima [ Sun Sep 03, 2017 11:10 am ]
Post subject:  Re: N64 additive transparency

It's not like it's hard to go beyond the commercial era, just by writing your own microcode, which most of them never did :P

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group