Wii Backwards Compatibility

[shoober420]

(07-09-2013, 07:56 AM)AnyOldName3 Wrote: Also, is the apple pie a kind of apple in this context? If not, then your argument that my argument is invalid is invalid.

A pie can be made with different apples, just as an image can be interpolated with different methods.

(07-09-2013, 08:13 AM)MaJoR Wrote: Go outside on a clear day and look up. There's a color up there. People call it blue. Our ability to see is determined by the light that hits our eyeballs. Light is scattered when it passes through the atmosphere, makes blue, then hits our eyeballs. We call this "sky". Deal with it.

The sky is not blue, its black. The sun makes it blue. If it was truly blue, it would stay blue, regardless of the time of day. Deal with it.

(07-09-2013, 08:13 AM)MaJoR Wrote: *facepalm* You always miss the point. And respond without addressing the point. The point was that you, as an outsider who knows nothing about emulator programming, are telling an emulator programmer about emulation terminology. To continue with your football analogy, it's as if someone who's never seen a game in his life were correcting a football coach's terminology. The coach would immediately cuss him out and beat him up. Just be glad Shonumi has more patience than that.

This would make sense if I never read about and knew about emulators, which I do. I question Shonumi's knowledge since he insists that HLE can be as accurate as LLE, which is totally wrong. Everyone knows that LLE will ALWAYS be more accurate then HLE.

(07-09-2013, 08:37 AM)RachelB Wrote: This is HLE?

I'm pretty sure SNES9x uses HLE for the CPU. So yeah it is.

[RachelB]

Quote:I'm pretty sure SNES9x uses HLE for the CPU. So yeah it is.

Cool, so you have no goddamn clue what you're talking about. Good to know.

Quote:The sky is not blue, its black. The sun makes it blue. If it was truly blue, it would stay blue, regardless of the time of day. Deal with it.

If it were truly black, it would stay black regardless of the time of day

The sky isn't an object; It has no color.

[Shonumi]

shoober420 Wrote:Actually, it does indeed prove that HLE will never be as technically capable, and as accurate as LLE.

Not true. All it proves is that the current implementation of HLE audio in Dolphin isn't yet as accurate as LLE. That's not the same as saying HLE audio will never be as accurate as LLE audio. What technical limitations about Dolphin's emulation of the DSP prevent HLE audio from reaching the accuracy of LLE audio? Do the currently known microcodes have hidden functionality that we haven't observed yet? Are the timings irreconcilable? Is there some magic in the scarcely reverse-engineered InitAudioSystem OS function? What is making it technically incapable? You're not being specific. Saying "HLE is always less accurate than LLE" is not a reason (because it's not always true).

shoober420 Wrote:I already gave you an example. Air Strike Patrol.

And it's hardly a good one. You keep assuming LLE is the only way without ever demonstrating that LLE is the only way. Consider this as a way to emulate the shadow via HLE. We can always manually draw the shadow ourselves. The game code writes the X/Y coordinates regularly, so it isn't impossible to find them ourselves instead of relying on OAM to tell us where it is. Why hasn't this been implemented yet? Probably because it's a very hackish example of using HLE and it's pretty game-specific. That, and it's not something many developers feel like working on as opposed to other improvements they could make.

shoober420 Wrote:Okay, now emulate the CPU and GPU with 100% accuracy using HLE instead of the "simple" things like BIOS and you might actually be able to prove your point. And bro, emulation is NEVER 100% accurate no matter what.

What's the point in asking me to emulate a CPU or a GPU with 100% accuracy if emulation is never 100% accurate? Emulating a CPU or GPU with LLE with 100% accuracy is just as impossible. Additionally, the DSP-1 and DSP-2 co-processors in the SNES could largely be emulated via HLE with near bit-perfect accuracy. Furthermore, Dolphin's DSP emulation under HLE is perfect in a handful of games. These aren't programs like the BIOS, these are processors in their own right. Again, what is it specifically about a device's complexity that prohibits HLE as a viable method of emulation? You keep saying this without explaining yourself.

The possibility of HLE is governed by the hardware's large-scale behavior. If that large-scale behavior is too broad (such as running various or multiple programs or executing random instructions), HLE is going to be exceedingly difficult. If you can capture the large-scale behavior of a device and reliably reproduce that, you have a decent shot at using HLE. Machine complexity only affects the possibility of HLE in regards to how broad or narrow the large-scale behavior will be, but it doesn't outright determine whether HLE is possible or not.

shoober420 Wrote:No its not. When you say upscaling is interpolation, that is exactly what you're saying. Don't deny it.

When I say upscaling is interpolation, I mean upscaling is interpolation. Other things can still be interpolation. You've been claiming I'm saying otherwise, but that's not the case. I've maintained that upscaling is interpolation, but other forms of interpolation do in fact exist:

Shonumi Wrote:Upscaling is a type of interpolation, therefore we can reasonably say that upscaling is interpolation. Obviously saying something like this does not preclude other things from being interpolation.

Shonumi Wrote: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

I've been saying the same message for a couple of pages now. I haven't suddenly changed my position. Either you don't understand it or you're terribly mistaken about it. Saying upscaling is interpolation does not mean other things can't be interpolation as well, because interpolation covers many ideas and applications. I've not said anything contrary to it. If you believe so, quote me on it. I asked you to do that before, if I recall correctly. You can't twist my words, especially since you can't edit my posts...

shoober420 Wrote:All the older SNES emulators used HLE for the CPU, which is why there was no shadow in Air Strike Patrol.

Please read this link. I posted it before, but I have more than a passing suspicion that you utterly ignored it. It's probably written by byuu himself. The issue with Air Strike Patrol is specifically with the PPU (Picture Processing Unit, handles graphical stuff), more pointedly, it's due to the fact that OAM data (responsible for telling the SNES where to draw what sprite and where to find the data in VRAM) changes mid-scanline. The issue also stems from rendering per-scanline as opposed to per-pixel. It's not specifically anything to do with the CPU. If the CPU were writing garbage data to OAM or VRAM, then it would be affecting the shadow in Air Strike Patrol.

shoober420 Wrote:I'm pretty sure SNES9x uses HLE for the CPU. So yeah it is.

Pretty sure, but can't provide an ounce of evidence? If the link RachelB posted has examples of HLE for the CPU code, can you point it out? If not, can you explain in detail how SNES9x uses HLE for the CPU, or find someone else who can?

shoober420 Wrote:And you have no evidence that HLE can render Air Strike Patrol correctly. How ironic.

See my method above. If it's not technically possible (my method specifically) explain in detail. Valid responses would be something to the affect like "but you always need to read OAM data for x, y, z" or "you couldn't deal with background priorities because of such-and-such". I want real, technical explanations, not answering back with a question like "well then why didn't byuu do it that way". I don't really care what byuu wants to and doesn't want to do; I do, however, care about hearing a decent, well-reasoned response.

Furthermore, why would I need evidence to prove HLE can emulate Air Strike Patrol correctly? My entire point was that HLE wasn't necessarily the cause of the graphical glitch. Incomplete LLE implementations can cause bugs of that degree as well. I even pointed out the real-life example with gbemulator. It doesn't matter whether it's HLE or LLE, if a programmer doesn't fully grasp how a system works and how to recreate a system's functionality, you'll end up with bugs.

shoober420 Wrote:How about calling it BS-DS. Because its BS that you can increase internal resolution with a true LLE emulator.

We've been through this. Increasing the internal resolution is an enhancement; enhancements are neither HLE nor LLE if those features weren't found on the original hardware. Again, you can only emulate what the hardware itself does. According to your definition though, "true LLE emulators" don't even exist. A true LLE emulator has no enhancements. No save sates, no fullscreen, no nothing. But just about every emulator does that. I don't intend to make a "true LLE emulator" probably for the same reason no one's ever made one at all (no enhancements at all, really? Not even pausing or screenshots?). I'm going to make a cycle-accurate DS emulator capable of increasing the DS' internal resolution. Honestly, I'd prefer it if you didn't attempt to insult my ambitions when you don't have a clear idea about what I'm trying to achieve.

Now for some stuff I didn't respond to earlier.

shoober420 Wrote:That link is being run through a translator, its not valid. Find a better source please. That could be translated completely wrong.

Toshiba Wrote:Il s'agit d'une technologie de type upscaling (interpolation) conçue par Toshiba permettant d'afficher des images de résolution standard à une résolution proche de la haute définition

Toshiba Wrote:La technologie XDE « upscale » (interpole) les images d'une résolution standard de 480p à une résolution de 1080p afin d'obtenir une image de meilleure qualité.

Forgot to respond to this. The original French is pretty accurate to the translation (based on what I know of French and Latin-based languages). The key parts are that upscaling is a borrowed word (same in English as in French), yet upscaling and interpolation are equated even the French. We have several native French speakers who can verify this if you want.

shoober420 Wrote:If you're so technically savvy, then you can provide information on how these emulation use LLE for CPU instead of HLE.

Here is the current CPU implementation of Mupen64Plus. It looks extensively LLE'd to me, especially when you look at individual instructions in the interpreter files. Take how Mupen64Plus handles Load Byte. It's not cutting any corners as far as I can tell. It grabs the address from the immediate, increments the program counter and then reads the byte from memory at the address. From what I know, it parses the instruction (MIPS encode 32-bit instructions with various bits of info) specifically the rt section to see which register it needs to write this value to. In general, that's how most load operations happen when you emulate a CPU, from what I understand. I am not familiar with the MIPS architecture, but I from what I gather, LB instructions automatically sign-extend the data (hence the check at the end of the code). LBU (Load Byte Unsigned) doesn't sign-extend, naturally. Were I more familiar with Mupen64Plus and the MIPS instruction set, I could go on.