138
edits
Changes
Jump to navigation
Jump to search
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.
Updated information on texture filtering issues
===[[Texture filtering]]===
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.
<gallery widths="300" mode="packed">
Project64_2013-06-26_17-44-58-31.png|Conker's Bad Fur Day copyright screen, displaying issues with filtered text.
Mupen64plus_2013-08-18_20-35-50-08.png|Ocarina of Time's menu subscreen, displaying issues with filtering.</gallery>
===Timing issues===
One of the biggest remaining problems in N64 emulation is lack of accurate core timings, which in practice means games do not always run at the speed they would on real hardware. While this technically affects all games, the majority are only affected to a negligible degree, and in some instances (particularly in Rare games) this can actually result in less framerate drops and lag, which can be seen as beneficial. However, some game engines actually depend on accurate timings for proper game behavior, and not properly emulating them can result in considerable to major issues. Some notable examples include the following:
* Intros and cutscenes playing too fast and not properly syncing up with musical cues. Seen in Goldeneye's intro and Body Harvest's beginning cutscene.
* Gameplay demos running at hyper speed. Earthworm Jim 3D is most notorious for this, though the main game itself is largely unaffected.
* Game physics not working properly due to being tied to framerate. A good example is Donkey Kong 64, which is programmed to boost the character's speed and momentum proportional to in-game lag (most likely to make up for the game's frequent framerate drops), which can be exploited for certain glitches and sequence breaks on real hardware. Emulators currently run the game too well and with too little lag, making most of these tricks impossible to pull off.
* Possibly the most affected game is Knife's Edge, which runs like it's on permanent fast-forward, making it all but unplayable. Messing with timing-related settings such as CounterFactor can mitigate this somewhat, but nowhere near enough to fix the issue.
==Peripherals==
