Dolphin, the GameCube and Wii emulator - Forums

Shonumi already explained it to you perfectly. But you refuse to listen to anyone so I'll just repeat what he said:

Shonumi Wrote:High-level emulation involves taking shortcuts to achieve the same effect as real hardware. The DAA instruction was just one example, but it's rare to get a chance to HLE any parts of the CPU. This is due to the fact that HLE relies on mimicking the large-scale behavior of hardware. The large-scale behavior of a CPU is to run specific programs. To HLE that, you'd necessarily have to know the large-scale behavior of the program (e.g. ROM, ISO, DOL, etc) you're running. That's not very practical unless there are only a handful of games for the emulator, and you know the assembly of each game very well. This would be useful for emulating something like old Tiger Electronic handheld devices, like Raptor Run. Extensively using HLE for the CPU isn't done with most emulators (if any?) emulators today. You can't reliably predict the behavior of every game at every point of gameplay.

Most CPUs are emulated using LLE as a result. This is also true due to the type of instructions being emulated; some simply have no shortcuts because they can't be reduced, nor can they be stripped of any other step. If an instruction tells you to add two numbers, what's there to skip? What's there to shorten? If an instruction tells you to read a value from memory, how would you HLE that? If you say emulators for 2D systems HLE the CPU (partly or completely) please provide specific examples.

(07-04-2013, 03:52 PM)Shonumi Wrote: [ -> ]Most CPUs are emulated using LLE as a result. This is also true due to the type of instructions being emulated; some simply have no shortcuts because they can't be reduced, nor can they be stripped of any other step. If an instruction tells you to add two numbers, what's there to skip? What's there to shorten? If an instruction tells you to read a value from memory, how would you HLE that? If you say emulators for 2D systems HLE the CPU (partly or completely) please provide specific examples.

Well apparently, there were a lot of SNES emulators that used HLE for the CPU, which caused the shadow from the plane to be missing in "Air Strike Patrol". Which would explain what was skipped and shortened in HLE CPU emulation. This is why byuu made a LLE emulator in the first place, to accurately emulate the CPU. It seems that all other SNES emulators behave in the same way, except higan, which uses LLE for almost everything. Meaning, most SNES emulators did indeed use HLE for the CPU, or else they would have the shadow there in "Air Strike Patrol" like higan does. See what happens when you use HLE? You loose accuracy for the sake of speed.

(07-04-2013, 08:55 AM)pauldacheez Wrote: [ -> ]I mean, look at that Z64 plugin, it's LLE and it can have its stuff rendered at high-res.

That's because it uses HLE for the CPU. If there wasn't some form of HLE, it wouldn't allow you to increase the internal resolution at all. A true, pure LLE emulator (like Xebra), will not allow you to increase internal resolution because it aims for accuracy, not eye candy.

shoober420 Wrote:See what happens when you use HLE? You loose accuracy for the sake of speed.

You're still completely missing the point. Read the first paragraph in the quote.

You need to understand what LLE and HLE mean if you ever hope to understand this. Shonumi has explained that too you as well, multiple times. But I'm sure he'll come in here and do it again just for the hell of it.

And so it goes... Fortunately, I have patience.

shoober420 Wrote:LLE is about accuracy. LLE emulates the hardware as closely as possible, while HLE goes for speed and enhancements. You will not get the same results with HLE emulation, which is one of the reasons byuu uses LLE instead of HLE for his emulator. He wants accuracy.

I just pointed out in my previous post, HLE is not focused on speed or enhancements, but how the emulation actually occurs. It's high-level because you bypass certain steps to get the same or similar results. HLE and LLE have nothing to do with what kind of enhancements an emulator has. Your definitions of HLE and LLE are incredibly inconsistent with developer terminology.

Additionally, I just provided two real-life examples of HLE giving the same results as LLE and real hardware in my previous. Can you explain, in detail, how those HLE methods won't produce the same results as LLE? Can you pinpoint exactly where the HLE methods are lacking? byuu prefers to use LLE because it follows his goals of a completely cycle-accurate emulators as a way to preserve/document old hardware and games.

shoober420 Wrote:This is because its only emulating the BIOS or something else very simple. If HLE tried to emulate anything else, it would have no way of emulating it as accurate is LLE would.

delroth would very much beg to differ with you with regards to his reworking of the DSP (co-processor in the GC and Wii) for AX ucode games. A vast majority of games had imperfect audio. However, he was able to reverse engineer the AX ucode more than anyone else so far. Dolphin is now capable of producing identical audio in a number of games using HLE or LLE audio. The DSP isn't just a 256-byte program like the GB BIOS, it's its own chip. HLE is possible because the large-scale behavior of the DSP is controlled by specific, limited numbers of ucodes (microcodes). The complexity of how the DSP works has nothing to do with its potential for HLE.

shoober420 Wrote:The analogy fits perfectly. Just because upscaling uses interpolation, that doesn't mean that it is interpolation. Just because something uses something else, it doesn't become what it uses.

Upscaling doesn't "use" interpolation like its a tool; interpolation describes the overall behavior of what it does: estimating new pixel values from a set of given pixels. Upscaling is a very specific case of interpolating pixels to get a larger image. Cars are not specific cases or types of gasoline. Gasoline powers a car, but you can't describe or compare a car with gasoline. You can describe upscaling as interpolation, because the entire process of upscaling is a kind of interpolation.

Links for you, just random results from a quick Google search of "upscaling interpolation"
http://www.pcadvisor.co.uk/forums/21/digital-home-advice/329792/is-upscaling-just-a-kind-of-interpolation/
http://www.experts123.com/q/what-is-high-definition-upscaling-interpolation.html
http://www.sonydictionary.com/upscaling-interpolation/

Additionally, consider that interpolation is a mathematical concept. When something uses a mathematical concept, we can rightly say it is that concept itself or a specific or particular instance of that concept. You find this happening all the time; a prime example would be exponents being a specific instance of multiplication. You wouldn't find a right-minded mathematician in the world who wouldn't say that exponentation isn't multiplication. Regardless of the application, if you add something it's addition. Regardless of the application, if you divide something, it's division. Regardless of the application, if you interpolate something, it's interpolation. That's how math works. That's how upscaling is interpolation.

shoober420 Wrote:This is a bad analogy because you don't need to walk to exercise. You can exercise in many different ways. Unlike upscaling, that requires interpolation and can't use anything else to upscale. Your legs are used to exercise, does that mean our legs are called exercise? A computer uses a mouse to function. Does that mean the computer is a mouse now? Your lungs need oxygen to breathe, does that mean our lungs can now be called oxygen? Just because something uses something else to function, doesn't mean it becomes what it uses. Interpolation and upscaling are two totally different things. There is NOTHING you can say to convince me that they are the same.

You're twisting the analogy. My analogy never said that simply because an item uses something, it then becomes that something. That's what your car analogy tries to insinuate. Walking is a form of exercising. Exercising describes walking, in much the same way that interpolation describes the process of upscaling.

You seem to have a hard time understanding that one item (upscaling, a Toyota Tundra, red light) can be an specific instance of a larger, broader category (interpolation, trucks, electromagnetic radiation). This is pretty basic stuff that, as I linked to in my post yesterday, is fundamentally understood in various levels of organization in biology, computer science, linguistics, and mathematics. You can say that red light is electromagnetic radiation in the same vein that a Toyota Tundra is a truck in the same vein that upscaling is interpolation. Again, upscaling doesn't "use" interpolation like its a separate part of the process; interpolation pretty much sums up the entire process of upscaling images.

shoober420 Wrote:If what you were saying is true, when I use trilinear filtering on a texture, it upscales the texture no matter what, since upscaling is interpolation. This is simply not true. You can apply interpolation to something without the need to upscale, because upscaling isn't interpolation. Just as I can walk without the need to exercise. Interpolation is interpolation, and upscaling is upscaling.

Interpolation is the process of generating new data points from existing ones. Upscaling fits that definition; we can say upscaling is interpolation. Bilinear and trilinear filtering also fit that definition; just as well, we can rightly say they are interpolation. Remember, interpolation is a broad idea; it encompasses many different applications. Saying two things are interpolation says nothing about how they interpolate. You can rightly say that subtraction and division basic elements of math, but no person would honestly ever confuse subtraction and division. You can rightly say that upscaling and bilinear texture filtering are interpolation, but it isn't reasonable to equate upscaling and bilinear texture filtering as one and the same. My statements have only been consistent with the italicized parts, not the underlined part. The underlined part is what you're claiming I'm saying, but your argumentation showing that has been poor so far.

shoober420 Wrote:There's no doubt LLE emulation is used for accuracy. HLE is for speed. This is common knowledge.

But HLE isn't always used for speed. HLE can be used for a couple of reasons. 1) It's more convenient. If I don't have to dump my BIOS to begin programming an emulator, it's going to make my life as a developer that much easier. This is especially if I don't have the console itself on hand, but you still have the games and a way of dumping them (don't have a PSX any more, can still rip disks from my DVD drive). I can always add an option to run the BIOS later, but if I just want to get up and running, HLE is a good way to go. 2) It might be easier than implementing something via LLE, especially when there's a lack of documentation. I'm working on Gekko (the only other semi-active GC emu project afaik). I decided to work on getting the DSP working so we can get sound (development is on hold atm), but I chose to go with HLE because I figured it would be easier to implement. Even though I had a pretty solid idea of how the DSP works at a hardware level, Gekko had some HLE code laying around, so it gave me a headstart. From what I've heard, there are numerous functions in N64 emulators that are HLE'd because documentation is simply not there in some cases, and it's even worse on the Saturn.

shoober420 Wrote:Well apparently, there were a lot of SNES emulators that used HLE for the CPU, which caused the shadow from the plane to be missing in "Air Strike Patrol". Which would explain what was skipped and shortened in HLE CPU emulation. This is why byuu made a LLE emulator in the first place, to accurately emulate the CPU. It seems that all other SNES emulators behave in the same way, except higan, which uses LLE for almost everything. Meaning, most SNES emulators did indeed use HLE for the CPU, or else they would have the shadow there in "Air Strike Patrol" like higan does. See what happens when you use HLE? You loose accuracy for the sake of speed.

Air Strike Patrol was actually due to some scanline rendering issues with the PPU. Having dealt with pesky scanline problems myself, I will say that rendering like real hardware can save you from a lot of headaches. Even so, it's not like that graphical error was caused by HLE specifically in other emulators. Other emulators like SNES9x most likely do use LLE extensively (if not entirely?) in the PPU, it's just that their implementation isn't accurate enough, in which case, it's not a fault with the approach (HLE or LLE) but in how accurate the authors make the emulator . It's a bug, not an instance of HLE for speed.

shoober420 Wrote:That's because it uses HLE for the CPU. If there wasn't some form of HLE, it wouldn't allow you to increase the internal resolution at all. A true, pure LLE emulator (like Xebra), will not allow you to increase internal resolution because it aims for accuracy, not eye candy.

Can you explain where any instance of HLE occurs in the code for the CPU, either generally (it happens when altering such-and-such registers, it's in this set of instructions, etc) or specifically? If not, how do you know? Source?

You know, one of these days, when I start work on my own DS emulator, I'm going to LLE the whole thing and support internal resolutions. All with software rasterizing too

(07-05-2013, 03:32 PM)Shonumi Wrote: [ -> ]You can say that red light is ultraviolet radiation

But you'd be wrong, because these categories don't overlap. They're both electromagnetic radiation.

(07-05-2013, 10:14 PM)AnyOldName3 Wrote: [ -> ]

(07-05-2013, 03:32 PM)Shonumi Wrote: [ -> ]You can say that red light is ultraviolet radiation

But you'd be wrong, because these categories don't overlap. They're both electromagnetic radiation.

My bad. That's what I meant to post, but I copy + pasted from a text file without changing it. I write out long posts like these in text files and save them locally, in case of power failures, browsers crashes, or whatnot. It's incredibly annoying to lose your progress like that (NV understands this all too well). I do edit them for clarity and grammar, but this was sorely missed. The post is edited now, thanks for pointing that out. There are still some typos though, which is a larger issue :p

I had to use LLE audio when I was playing Eternal Darkness to avoid glitches in the cutscenes were audio would be missing. That's only one instance where LLE offers more accuracy and reliability then HLE. I'm sure there's countless other examples where LLE must be used for accuracy to avoid glitches. The Eternal Darkness wiki recommends you use LLE audio to avoid this problem.

There is absolutely nothing you can say to convince me that upscaling IS interpolation. In my eyes, upscaling is upscaling, and interpolation is interpolation. Please drop it. You will not convince me.

I'm pretty sure higan is the only emulator that renders Air Strike Patrol correctly. Most likely because of the use of LLE to avoid any "shortcuts" that HLE does which causes the shadow to go missing in the first place.

Most, if not all N64 emulators use HLE for the CPU. Most use HLE for the GPU as well.

I really hope you make this DS emulator that can increase internal resolution and be a pure LLE emulator. I haven't used a true LLE emulator yet that allows such an option.

Look, although I may disagree with you on some things, I am grateful you told me about how 2D emulators don't increase the internal resolution. This has made me realize the importance of why having the true hardware is the most legit way to have an authentic experience with the game and the console. But as regards to the other things, let's agree to disagree.

(07-06-2013, 06:41 AM)shoober420 Wrote: [ -> ]There is absolutely nothing you can say to convince me that upscaling IS interpolation. In my eyes, upscaling is upscaling, and interpolation is interpolation. Please drop it. You will not convince me.

I'm afraid you'll have to post a disclaimer explaining while you're wrong, then, just in case the next you uses your posts as evidence in the future.

One final example:

Cutting is using an object to separate another object into multiple pieces.

Sawing is using a saw (or saw-like device) to cut through an object.

Sawing is a kind of cutting, as it's using an object (specifically a saw) to separate another object (eg some wood) into multiple pieces.

Cutting is not sawing, as it isn't necessarily using a saw to separate things, as it could be using any object.


Interpolation is using existing data points to estimate values of other data points within the same range.

Upscaling is using existing pixel data to estimate new pixel data at a higher resolution within the same image.

Upscaling is a kind of interpolation as it's using existing data points (existing pixel data) to estimate values of other data points (new pixel data at a higher resolution) within the same range (the same image).

In English, you can say that something that is a type of something is tat thing.

For example, you can say a car is a kind of vehicle, so you can say a car is a vehicle. Because a vehicle is not necessarily a kind of car, you cannot then say that any vehicle is a car.


If you do not understand this explanation, then I'm afraid it's because you don't speak English well enough, and not because we're wrong.

shoober420 Wrote:I had to use LLE audio when I was playing Eternal Darkness to avoid glitches in the cutscenes were audio would be missing. That's only one instance where LLE offers more accuracy and reliability then HLE. I'm sure there's countless other examples where LLE must be used for accuracy to avoid glitches. The Eternal Darkness wiki recommends you use LLE audio to avoid this problem.

But how does the fact that Eternal Darkness still needs LLE audio counter the fact that HLE audio can produce the same exact sounds as LLE audio in other games? All it says is that one game isn't accurate under HLE audio, but that doesn't preclude other games from being accurate under HLE audio. Simply because Eternal Darkness doesn't produce accurate audio under HLE doesn't mean games like Sonic Adventure 2 or Super Smash Bros. Melee don't produce accurate audio (note: audio has been perfect under HLE for both games for some time).

shoober420 Wrote:There is absolutely nothing you can say to convince me that upscaling IS interpolation. In my eyes, upscaling is upscaling, and interpolation is interpolation. Please drop it. You will not convince me.

At this point, I don't think anything short of blunt force trauma will change your mind :p I don't care what you think, but if someone comes around using incorrect terminology and faulty argumentation about something I'm knowledgeable with, I'm not going to sit around and let misinformation stand uncorrected. You can think whatever you want, but there's a very large body of evidence and reasoning that says upscaling is interpolation, and you've shown little logic defending your position.

shoober420 Wrote:I'm pretty sure higan is the only emulator that renders Air Strike Patrol correctly. Most likely because of the use of LLE to avoid any "shortcuts" that HLE does which causes the shadow to go missing in the first place.

That's missing the point. If someone doesn't know how to implement a feature correctly (i.e. they make mistakes), or someone doesn't even know the existence of a feature, it's hardly considered high-level emulation by default if that feature isn't put into the emulator or is programmed badly into the emulator. That's generally a bug in the way the program is supposed to work. The example with Air Strike Patrol occurs because the developers used the SNES hardware in a way that was highly unusual, one that was not recommended and scarecly used by any other games (the only other similar game was Uniracers). You can LLE everything you can think of, but if you miss a rare, fringe case, you aren't suddenly "taking shortcuts" and doing HLE, you're just not making things as accurate as you could be.

Take the LCD Status Interrupt (STAT) on the Game Boy. I was studying gbemulator among various open-sourced GB emulators. Take a look at the second screen shot. You'll notice that there are a couple of pixels under the score (70420) and a bit of the bottom of the coin looks like it's missing. This happens when you update the LY (scanline) register before checking the LYC (scanline compare) register. Note the author is doing the necessary steps to generate an LCD Status Interrupt, just like real hardware. It's just that the steps are out of order (lines 333 and 334 should be flipped). The LCD is emulated via LLE; the author has made a mistake (a bug), but he isn't using HLE.

shoober420 Wrote:Most, if not all N64 emulators use HLE for the CPU.

That's entirely vague. I asked you to provide generalities (e.g. what instructions are usually HLE'd, what parts of the CPUs operations are normally HLE'd) or specific examples (code). You could have at least said "the developer of so-and-so N64 emulator said they use HLE for memory access from the CPU" or anything along those lines. As it is now, you're just saying things without a valid source. This is the internet my friend; anyone can say anything here. Using HLE for the GPU is no surprise, since it's largely been that way since UltraHLE.

shoober420 Wrote:I really hope you make this DS emulator that can increase internal resolution and be a pure LLE emulator. I haven't used a true LLE emulator yet that allows such an option.

There isn't any emulator capable of increasing the DS' internal resolution, and that's why I'm going to do it one day (I really impatient to dive in actually). It's a ways off, but I'm at least going to try. Once I get GB/GBC emulation sorted, I'm going to work on a GBA emulator (this will help me get more familiar with ARM and working with a more complex system) then I'll tackle the DS. Hopefully everything will go as planned, but I've got a lot of time to get going.

shoober420 Wrote:But as regards to the other things, let's agree to disagree.

As long as I get the last word

(07-06-2013, 01:22 PM)Shonumi Wrote: [ -> ]But how does the fact that Eternal Darkness still needs LLE audio counter the fact that HLE audio can produce the same exact sounds as LLE audio in other games?

HLE doesn't produce the same effects as LLE does. Its not as accurate like you said, which was the whole point I have been trying to make. I'm sure there are other games that require LLE audio to sound correct. Metroid Prime being an example. Although it says the new HLE has fixed this, I would rather use LLE since its more accurate

(07-06-2013, 01:22 PM)Shonumi Wrote: [ -> ]At this point, I don't think anything short of blunt force trauma will change your mind :p I don't care what you think, but if someone comes around using incorrect terminology and faulty argumentation about something I'm knowledgeable with, I'm not going to sit around and let misinformation stand uncorrected. You can think whatever you want, but there's a very large body of evidence and reasoning that says upscaling is interpolation, and you've shown little logic defending your position.

I've shown a tremendous amount of logic and reasoning to defend my opinion. And in the end, all everyone has stated is there opinions, not facts. Upscaling uses interpolation to add more data. Its not its own special interpolation. That is only your opinion.

(07-06-2013, 01:22 PM)Shonumi Wrote: [ -> ]That's missing the point. If someone doesn't know how to implement a feature correctly (i.e. they make mistakes), or someone doesn't even know the existence of a feature, it's hardly considered high-level emulation by default if that feature isn't put into the emulator or is programmed badly into the emulator. That's generally a bug in the way the program is supposed to work. The example with Air Strike Patrol occurs because the developers used the SNES hardware in a way that was highly unusual, one that was not recommended and scarecly used by any other games (the only other similar game was Uniracers). You can LLE everything you can think of, but if you miss a rare, fringe case, you aren't suddenly "taking shortcuts" and doing HLE, you're just not making things as accurate as you could be.

Exactly. If you use shortcuts that HLE does instead of LLE, you will get bugs like missing shadows from the plane in Air Strike Patrol. You can't emulate the shadow from Air Strike Patrol with HLE, which is why byuu used LLE in the first place. And if you're so emulator savvy, then code a HLE emulator that renders Air Strike Patrol correctly with no form of LLE involved. Please.

(07-06-2013, 01:22 PM)Shonumi Wrote: [ -> ]That's entirely vague. I asked you to provide generalities (e.g. what instructions are usually HLE'd, what parts of the CPUs operations are normally HLE'd) or specific examples (code). You could have at least said "the developer of so-and-so N64 emulator said they use HLE for memory access from the CPU" or anything along those lines. As it is now, you're just saying things without a valid source. This is the internet my friend; anyone can say anything here. Using HLE for the GPU is no surprise, since it's largely been that way since UltraHLE.

I'm not a programmer, so I can't provide code, but Project64, 1964, Mupen64Plus, and just about every other N64 emulator use HLE on the CPU, and GPU for that matter (Mupen having a special plugin to emulate the GPU with LLE). N64 LLE emulation is still in the minority, as is LLE emulation in general.

(07-06-2013, 01:22 PM)Shonumi Wrote: [ -> ]There isn't any emulator capable of increasing the DS' internal resolution, and that's why I'm going to do it one day (I really impatient to dive in actually). It's a ways off, but I'm at least going to try.

There also isn't any pure LLE emulator capable of increasing internal resolution either.