Яндекс

Tuesday, November 25, 2014

As I explained in the previous article, low level emulation (LLE) is not magic wand which makes the emulation perfect. But it the only way to run games, which are not supported by HLE. And if you already have HLE plugin, you are one step from having LLE support as well. LLE plugin does emulation of RDP. HLE plugin does emulation of RDP plus high level emulation of RSP commands. That is, HLE plugin is LLE plugin + HLE RSP. Of course, practical implementation of LLE mode in HLE plugin has nuances, but in general the situation is like that.

Now to the news: since that week GLideN64 supports low level emulation. Of course, graphics glitches caused by difference between N64 graphics hardware and PC graphics cards are not gone. LLE by itself cannot ensure pixel-accurate emulation. But if you want to see for example Star Wars - Rogue Squadron in high-resolution with advanced texture filtering, GLideN64 will help you.

Few screen shots from previously unsupported games:

The secret way to get a beta build right now is here. The project needs your help!

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.

Sunday, November 9, 2014

The project is moving forward according to the “Plan for Project Completion”. Today we set the new project’s milestone: the first monthly beta. This topic is a kind of press-release. According to the Plan, the following two tasks ware planned to accomplish in October:

1 . The
first task planned on October was “Fix stability issues”. My experiments added
a lot of mess into original code. I made massive code rafactoring to make the
code clean again. I fixed many issues with program initialization and
de-initialization, and now it is possible to run several games without closing
the emulator after each of them. Switch between fullscreen and windowed modes,
savestates loads also could crash the plugin. It is fixed. The task can be
considered as completed.

2. As you know, GLideN64 is based on sources of Orkin’s glN64 graphics plugin. glN64 compatibility was “fair” on its release time, and today it can be considered as “mediocre”. It was good enough for my experimental works, but not for a public release of the new plugin. During my experiments I made no special steps to increase original plugin’s compatibility. No new ucodes were implemented. Many bugs in legacy code were not fixed. Thus, plugin’s code on start of crowd-funding campaign consisted of:

To the end of October almost all emulation-related functionality of Glide64 was ported or reproduced in GLideN64. Users, who have access to weekly beta releases, may confirm that the plugin evolved greatly for this month. However, the chasm was too wide. Oliver found more than fifty serious issues. Thus, we decided to take one week for debugging. This week I worked hard to fix found issues, Oliver from his side opened the new ones. Most of found and fixed bugs resided very deeply in legacy code and I spent many hours to locate them. Currently the score of open and closed issues is equal.

What does it means? The goal of the first phase is not reached. Functionality of the plugin is close to the target, but existing bugs spoil the impression. Thus, the further plan needs correction. Next goal is high-res textures support. Since existing bugs must be fixed, this work also will be continued and will be done in parallel with the main task. The second phase is planned to accomplish in November and new monthly build with high-res textures support has to be released in the beginning of December. I already lost one week on debugging, so most likely the second monthly release will be delayed, probably to the end of December. If I will finish with bug fixes before high-res textures will be ready, I’ll release an update. Also, I want to remind you that you still may support the project.

I’m planning to make new videos which show the work in progress. So far, I can only show you the WIP screen shots (click to see full size image):