A word for HLE

This is my old article, which I wrote before I announced my work on GLideN64. I decided to publish it here because it will be useful for my next post.

Introduction.

As you know, there are two approaches to emulation: Low Level (or traditional) Emulation, LLE, and High Level Emulation, that is HLE. HLE approach is possible when all software running on the emulated system uses a common library. HLE emulator implements this library as much effective as possible, without care how actual hardware does that job. Thus, HLE emulator makes some kind of shortcut in emulation process, bypassing actual emulation of some piece of hardware.

HLE pros:

• Tremendous speed increase in compare with traditional emulation

HLE cons

• If there are several version of the common library, each version must be implemented separately
• If a game uses unknown version of the library, it can’t be run
• Errors and incompleteness in library implementation cause various glitches

LLE pros:

• Being implemented once it will work for all software.

LLE cons:

• Requires much more computational resources than HLE.

HLE vs. LLE in N64 emulation

For a long time HLE was key feature of N64 emulation. All N64 games use a library for render audio and graphics. The library runs on powerful multimedia Reality Co-Processor, RCP. RCP actually consist of two parts: programmable Reality Signal Processor, RSP, which executes graphics and audio tasks, and Reality Display Processor, RDP, which draws the graphics in the frame buffer. The library, known as microcode, is loaded into RSP and controls its work. That is it defines how graphics and audio tasks must be performed. HLE emulators implement the microcode and thus bypass emulation of very powerful module, which can perform many scalar and vector operations per cycle.

At the beginning of N64 emulation HLE was the only option to achieve full speed emulation, because Pentium II based PC were just few times more powerful than emulated system. Thus the first emulator capable to run commercial games was named UltraHLE. It was a great piece of software, but none of the game it run was emulated perfectly. Each game had visual glitches. Many emulators were released after UltraHLE, compatibility increased greatly, but graphics glitches are still with us. Most of people used to blame HLE for that.

A word for HLE

If in the beginning of N64 emulation LLE was not an option, 10 years after PC became powerful enough to run LLE full speed. LLE video and audio plugins were implemented, and today N64 emulators may not use HLE at all. However, graphics (and audio) glitches are still there. LLE plugins have the same (or even more) glitches as HLE ones. It proves that HLE approach itself is not responsible for the glitches.

HLE plugin screen shot:

LLE plugin screen shot:

HLE is totally responsible for “unsupported microcode” problem. If some game uses custom microcode with unknown specification, such game can’t run with HLE. How many games still have “unsupported microcode” status? Ten at the most.

HLE is partially responsible for incomplete microcode implementation. Some games use modified versions of common microcodes, and these modification not always correctly decoded and implemented. This is rare case too. Also, there is a chance that microcode implementation will be improved.

All other graphics glitches are caused by difference between N64 graphics hardware and PC graphics cards. And this problem is common for HLE and LLE. N64 hardware has capabilities, which have no direct analogues in PC hardware. And while shaders allow programmers to reproduce most of N64 special effects, N64 work with frame buffer can’t be totally emulated with PC hardware.

From the other side, PC graphics cards allow to greatly improve visual quality of emulated games. From the beginning, N64 emulators render games in resolution, which is much higher than the original one. FSAA, anisotropic filtering, texture magnification filters and finally hi-res texture packs make our favorite games look if not modern but at least descent.

Already mentioned shaders not only allow programmers to emulate N64 special effects, but also can be used for features, which N64 could not dream of. For example, most of N64 games heavily use lighting to produce realistic image. Lighting is computationally intensive feature, and N64 can do it only per vertex. Besides, lighting calculation method used in N64 is very different from the one, used on PC hardware and thus N64 emulators do vertex lighting calculation in software. With shaders it is possible not only perform lighting calculation in hardware, but also do it per pixel. Look at the screen shots.

Traditional lighting calculation:

Per-pixel lighting:

Close look:

As you see, per pixel lighting calculation produces smoother and more correct color gradient. It looks better in dynamic, when light sources are moving. It’s not astounding image quality improvement, but it is nice anyway.

Another example:

This is very primitive implementation of cell-shading. It should look better with specially made “cell-shading” textures. The point here is that cell-shading effect is based on lighting calculation: we need to know light intensity to calculate it.

Now I have bad news for HLE haters: these lighting-based effects can be done only with HLE. Because with LLE all vertex computations are done by RSP plugin and LLE video plugin is mere rasterizer.