Skip to content

Instantly share code, notes, and snippets.

@JayFoxRox
Last active April 3, 2017 22:34
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save JayFoxRox/ec190b96686b72c187b181830ce1fca1 to your computer and use it in GitHub Desktop.
Save JayFoxRox/ec190b96686b72c187b181830ce1fca1 to your computer and use it in GitHub Desktop.
LLE / HLE / UHLE

There are two different approaches to emulation, one's working on a game-by-game basis, which is much less accurate, but faster and depends on a lot of game specific hacks. CEMU is pretty much a hackfest.

The other approach is a more accurate one that aims to achieve universal game compatibility. It focuses on emulating the system properly, not just running games. Therefore it's slower. That's Citra.

tl;dr CEMU is like ZSNES for WiiU and Citra is kinda like Higan for 3DS.

I feel this is getting a bit offtopic. But this is not the complete picture. Disclaimer: This post won't give you a complete picture either - this is very simplified.

Citra is HLE, just like CEMU probably is. Also Citra has LLE parts, just like CEMU probably does.

Concepts

LLE: Low Level Emulator (Most accurate)

  • Does not focus on running games but emulating the hardware only.
  • The original systems software like a bios is then run on the virtual hardware.
  • This means you will reach 100% compatibility once all hardware is emulated.
  • This also means you can emulate exploits which worked on the original system.
  • It also means slow development progress at first: It's like trying to turn on your PC without RAM installed for example.

HLE: High Level emulation (Moderately accurate)

  • Can still reach a very high compatibility on some platforms (~100% of all commercial games)

UHLE: Ultra High Level emulation (Least accurate)

  • This approach is sometimes called UHLE (named after the N64 emulator of the same name) or also just HLE.
  • HLE applied to platforms which are not easily HLE'able (Example: N64, Xbox, ..)
  • Even with unlimited work you still wouldn't get high compatibility (say.. ~10% of all commercial games).
  • Without a deeper technical understanding of the platform it's hard to tell if HLE will be able to reach 100% compatibility with released games.
  • Depends on how games work to function correctly. Early Xbox games can be UHLE'd to a degree (but not even 100%), for later games it's pretty much impossible to UHLE at all. So even during the consoles lifetime how an emulator should approach the emulation was changed (as a side effect of decisions made my Microsoft to make the developer tools better).

A good current example would be cxbx-reloaded which is unable to run a lot of games by design (even in completed state).

Focusing on games

Regardless of LLE / HLE / UHLE you can focus on specific games during development. However, it's usually smart to care about all kind of games, not only the popular ones. That way you can get the best understanding of the system you are emulating.

Also, regardless of LLE / HLE / UHLE you can still add hacks to make specific games work (which CEMU probably does, but we can't check for certain). An example for such a hack can be found here for example: A hack in cxbx-reloaded to make certain things work in Halo; without that line Halo probably would work even less, other games might be affected by the same hack where it will cause additional errors. This cxbx-reloaded commit also removes a lot of hacks from the legacy cxbx. This is necessary to get more accurate emulation in the long run.

Overall it's very typical to focus on specific games for HLE and especially UHLE still because you have to understand how the software works to write the emulator for it (any game will do). For LLE you can start writing the emulator without ever touching a game.

Mixing of approaches

CEMU seems to take a HLE / LLE approach BUT it still focuses on certain games. Without the source code a lot of the niche games won't be tested so they probably won't work too good either. For Citra this is different: As it's open source you have a ton of people interested even in niche games, and some of those will be developers who also work on compatibility for these.

Citra is HLE for the most Operating System functions but LLE for the GPU.

From what I can tell, both, Citra and CEMU will at some point reach ~100%. For Citra this is actively being worked on by the community. For CEMU nobody is working on it - focus is clearly on games which earn the most money (Breath of the Wild for example). As games are still produced for both systems and firmware updates are still being released it could still happen that games will be released that can not be emulated (due to giving developers more freedoms in using the hardware). I've expected this for Pokemon Sun / Moon and Breath of the Wild. It looks like Nintendo doesn't care about this (anymore).

cxbx-reloaded is currently all UHLE but it's slowly aiming to become UHLE for the Operating System and LLE for the GPU. Later it will be LLE for the GPU and HLE for the Kernel. There are other things which cause cxbx-reloaded only to work on Windows though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment