The case design Nintendo used wouldn't have worked for example (no room to fit a bigger RAM module.)īah. It was a rather large PQFP as it was, and RAM expansion would have been more complicated as well of course. They probably couldn't have squeezed in the required pins on the RCP package though.
SGI had four RDRAM channels in parallel for the graphics subsystem of one of their smaller graphics workstations, maybe if N64 had used twin channels at least things would have been a bit better. I wonder where that poor performance comes from, some crazy quirk with the RDRAM standard to reach 500MT data rates in the mid-1990s, bad memory controller implementation in the RCP, or combination of both perhaps. I believe ERP said they did some measurements of RAM latency on the N64 and concluded it was around 250ns or something ludicrous like that, I can't quite recall the exact numbers stated so I may be off. Relatively fast CPU (R4300i), relatively advanced rasterizer (RCP), UMA (single-channel 9-bit RDRAM), on what I think was an advanced process at the time (0.35um?)Ĭlick to expand.Not really a case most of the time probably, due to the horrifically low efficiency of said RDRAM interface. It's very interesting to ponder the N64 design choices, given the Wii, and Wii U. I recently played through Donkey Kong 64 again, and there are some nice environment mapping effects and decent levels of geometry, though the two Banjos and Conker are better looking for the most part (to me). I always very much liked the N64 as a system, though by the accounts given on this forum, it was very difficult to program. When down scaling below a certain threshold, such as more than twice for all bi-sampling algorithms, the algorithms will sample non-adjacent pixels, which results in both losing data, and causes rough results. I have not noticed 'nearest' filtering in other titles, be they from Rare, Factor 5/Lucasarts, or Nintendo. One weakness of bilinear, bicubic and related algorithms is that they sample a specific number of pixels. I'm not sure if this was available in the API or whether it required microcode adjustment. It certainly seems that it could be turned off, giving nearest-neighbour on specified textures (the lights on the distant buildings in the first or second level of Perfect Dark appear to be 'nearest' rather than bilinear).
MODUL8 BILINEAR FILTER VS LOSSLESS QUALITY PRELOAD FULL
4?) could be adjusted for with pre-processing of the texture, making it close enough to a full bilinear of the era. From what I understood of previous threads (from many years ago), the edge AA could be disabled, and the bilinear filtering was not quite conventional bilinear, but a slightly more economical approximation.
0 kommentar(er)
