A word for HLE

[Gonetz]

Hello everybody,

Let me introduce you a new topic to discuss. Well, may be this topic is not very new. I did not follow emulation progress for two years. May be everything I wrote was already discussed and long forgotten. If so, sorry for taking your time. Anyway, the topic is here:
A word for HLE

You may leave your comments here or directly in the document.

 

[death--droid]

Great article, was very interesting to read. Your points came across extremely well in my opinion.

 

[olivieryuyu]

Progress is quite slow, you didn't miss much

Very nice article, it clearly show that HLE approach brings some nice features which LLE may not have

I would add that there is only 3 main microcodes which are unknown

- Factor 5 microcode (SW Rogue Squadron, SW Battle of Naboo, Indiana Jones)
- Boss Games (WDC, Stunt Racer)
- Hudson/Yuke Media Creations microcode (Last Legion UX, Toukon Road 1&2)

Two other games have a microcode issue: Kuiki Uhabi Suigo (early N64 microcode?) and 64 de Hakken!! Tamagotchi Minna de Tamagotchi World (F3DTEX/A, a specific microcode for textures, no info available).

This makes 11 games

 

[bobby.smiles32]

Nice article indeed.
I would add another point for LLE vs HLE :
-LLE documents the hardware (each RSP/RDP instructions)
-HLE documents data format and underlying algorithms (jpeg decoding, audio synthesis, gfx rendering...)

 

[PsyMan]

Since the document is mostly about graphics is would also be a good idea to make a comparison between hardware and software rendering.
For example, you can tell how h/w rendering can improve graphics and make everything prettier, then mention how s/w rendering can work around API limitations and make things look closer to the real thing (which usually means worse looking graphics).

 

[Fanatic 64]

Well, I think HLE is currently SO used that there is no need to go out defend it. Specially so harshly.

And correct me if I'm wrong, but can't you have a cycle-accurate emulator, put it OpenGL rendering, and add all filters, texture replacements, and shaders you want?

 

[angrylion]

Gonetz, could you upload that Paper Mario savestate?

 

[Zuzma]

The way I see it emulating LLE properly would help aid in fixing problems with HLE plugins, we shouldn't be pitting them against each other. Not sure about anyone else but I think this LLE vs HLE argument is getting stale.

Edit: sorry my writing sucks

 

[Gonetz]

PsyMan, regarding comparison between hardware and software rendering: MAME explained long ago, why software rendering rulez. It's obvious, that for exact emulation you need software rendering. The point of my article is that "HLE vs. LLE" problem is orthogonal to "graphical glitches" problem. I could illustrate it with screen shots from Jabo's plugin running in LLE with hardware rendering vs. Jabo's HLE with software rendering, where HLE with software rendering produces more correct picture. After that compare it with angrylion's LLE software rendering, which will show even more correct image.

angrylion, I'll send you the save by email, ok?

And correct me if I'm wrong, but can't you have a cycle-accurate emulator, put it OpenGL rendering, and add all filters, texture replacements, and shaders you want?

Yes. As I tried to prove, rendering problems are irrelevant to emulation approach.
At least until the rendering don't need data available only with HLE
Besides lighting, LLE have no information about vertex transformation. I have no reasonable idea, how to use it without information how vertices form a model.

 

[Guru64]

Nice read, but it's almost like you're trying to imply that LLE is not worth pursuing at all (then again, the article is called 'A word for HLE') and not even mentioning software rendering once does seem a little dishonest. You attribute being able to go beyond what the original hardware was capable of to HLE (which is definitely true in the case of lighting), but aren't some of these capabilities (such as anti-aliasing) also a result of trying to map everything to modern 3D graphics cards (so they're not really exclusive to HLE)?

 

[Gonetz]

Nice read, but it's almost like you're trying to imply that LLE is not worth pursuing at all

Interesting, where you found that
I tried to show that graphical problems are (almost) irrelevant to emulation approach, and HLE is unfairly blamed for these problems.

IMO, today video plugin for desktop N64 emulators should be LLE. Today PC are fast enough for that, even for full speed software rendering.
Mobile platforms are not that fast yet, but ARM CPU power grows fast, so someday LLE will come here too.

 

[DETOMINE]

Very interesting to read, but a little short I think.
Judging by the first comments, you may consider updating it (more examples and more precisions maybe?).

We also have many examples of games that don't run well neither with LLE nor HLE (Mario Tennis 64 is the first that comes to my mind).

 

[PsyMan]

PsyMan, regarding comparison between hardware and software rendering: MAME explained long ago, why software rendering rulez. It's obvious, that for exact emulation you need software rendering. The point of my article is that "HLE vs. LLE" problem is orthogonal to "graphical glitches" problem. I could illustrate it with screen shots from Jabo's plugin running in LLE with hardware rendering vs. Jabo's HLE with software rendering, where HLE with software rendering produces more correct picture. After that compare it with angrylion's LLE software rendering, which will show even more correct image.

Yeah, I just wanted to point out that some people don't have the knowledge to know that. Thus you can add related info on the document and distinguish the differences between s/w rendering and h/w rendering the same way you did between LLE and HLE.

 

[Gonetz]

Well, it's not a bad idea. Just need to find time to make proper screen shots.