Changes

The Nintendo 64 was the first consumer device to be able to filter textures when rendering 3D objects. However, unlike every console and PC graphics card made after the N64, its implementation of bilinear was primitive in that, in order to reduce strain on the system, it only used three samples as opposed to four, resulting in slightly jagged , asymmetrically-filtered textures. Instead of faithfully applying this "imperfect" version of bilinear filtering, HLE plugins instead apply applied conventional bilinear filtering, interpolating straight from the source texture up to the output resolution the same way a PC game would. While that method is technically superior, it can result in textures that look even blurrier than on real hardware.

Another issue lies with the appliance of texture filtering per quad on static images, text, and sprites. Because each quad is filtered separately, this can cause some visual inconsistencies. Text and UI elements often look as though their edges cut off abruptly, and static images, such as pre-rendered backgrounds or menu screens, may look as though they are separated into squares(see images below; note how OoT's Quest Status screen appears to be divided into a grid). Some plugins allow the user to turn off texture filtering to remedy this, but, unfortunately, this also applies to textures in the game world, exposing their oftentimes low resolutions.

RetroArch's Mupen64Plus core has Modern emulators and plugins have taken some steps which help remedy these problems. It is the only emulator that implements For instance, GLideN64 now supports N64-style three-point texture filtering, which results in a more faithful look. It is also capable of rendering at 320x240, which sidesteps the issues with filtered text, UI elements, and menu screens, while still retaining texture filtering. Pixel-accurate plugins such as Angrylion and ParaLLEl-RDP do not have these problems at all. Note how the Quest Status screen appears to be divided into a grid.