It is currently Tue Dec 12, 2017 9:25 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Sat Aug 26, 2017 3:50 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
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?


Top
 Profile  
 
PostPosted: Sat Aug 26, 2017 4:50 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19334
Location: NE Indiana, USA (NTSC)
As I understand it, RSP microcode is just a vertex shader and isn't intended to do things to individual pixels.


Top
 Profile  
 
PostPosted: Sat Aug 26, 2017 7:11 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
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.)


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 12:23 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
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:

Attachment:
bodyharvest1.jpg
bodyharvest1.jpg [ 7.2 KiB | Viewed 712 times ]

Or this:

Attachment:
naboo1.jpg
naboo1.jpg [ 17.78 KiB | Viewed 712 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...


Last edited by 93143 on Sun Aug 27, 2017 1:41 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 12:24 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 601
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.


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 1:37 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
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.


Top
 Profile  
 
PostPosted: Sat Sep 02, 2017 9:50 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
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...


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 8:23 am 
Offline
User avatar

Joined: Mon Oct 01, 2012 3:47 pm
Posts: 153
Location: freemland (NTSC-U)
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.


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 9:20 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
As good as Perfect Dark looks, It shouldn't make the N64 run at 12fps.


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 11:10 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 601
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: tepples and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group