shoober420 Wrote:Only at simple things like BIOS.
You keep ignoring the examples of complex things (specific processors) being emulated via HLE with bit-for-bit accuracy. You keep saying "only simple things can be HLE'd" without ever providing in-depth reasons, at least not anything more than "this emulator uses HLE, so look how inaccurate it is." That's not an answer. What is it specifically about complex hardware that prevents it from being HLE'd? (Hint: I've given you some clues if you want to make this argument, look at my previous posts).
shoober420 Wrote:Saying bit for bit is very misleading, and down right wrong. LLE will always emulate those things you mention more accurately then HLE, but not even LLE can emulate bit for bit, let alone HLE.
What's misleading is to say that LLE will always emulate those things more accurately. The ones I just posted are proven cases where HLE and LLE can emulate features on par with one another. If you want to say that things can't be emulated bit-for-bit, feel free to argue
byuu himself:
byuu Wrote:only the DSP-1 and DSP-2 were considered to be emulated bit-perfectly (meaning: feed in X, get exactly Y value out.)
Notice how byuu said HLE was not going to be possible for the other co-processors found in the SNES. The article doesn't say things like "you can only HLE simple things", it provides specific information on why HLE is not ideal for certain hardware, chiefly the amount of effort needed to reverse engineer it:
Quote:The Super FX and SA-1 were (relatively) easy to reverse-engineer, but the DSPs were proprietary chips, making their architecture and code all but impenetrable.
And
Ars Technica explains it further:
Quote:Often, these processors are so segregated from the host processor that it is possible to implement them using high-level emulation (HLE). This isn't unique to the SNES coprocessors; you also see it in N64 video microcode emulation, among other areas.
The idea here is to not think of individual instructions, but about what an entire group of them do together. In other words, think about a program in terms of functions like "render a triangle at these points" or "rotate this sprite by N degrees." It is then possible to simulate these operations with virtually no overhead. Unfortunately, this approach also discards all timing information required for the execution of each individual instruction. And worst of all, it's usually anything but perfect: minor edge cases, quirks, and flaws in the original implementations are lost, resulting in subtly different operation.
This is the kind of reasoning and level of examples that I've been asking for you to demonstate when trying to prove that you can only HLE simple things. These themselves quotes don't demonstrate that complex things can't be HLE'd (because, again, we have examples of complex hardware being HLE'd). What it does prove is that, in addition to being able to reliably reproduce the large-scale behavior, the hardware has to be thoroughly reverse-engineered and understood. You haven't proven how we can't reliably reproduce the large-scale behavior of complex hardware or that we can't thoroughly reverse-engineer complex hardware (because we've already done both). The quotes prove why we can't HLE
specific complex hardware, but doesn't prove why we can never HLE
any complex hardware.
shoober420 Wrote:HLE uses shortcuts, which is why the shadow goes missing.
And I explained a method that uses HLE to manually draw the shadow. Again,
technically explain how this specific HLE method won't work.
shoober420 Wrote:Maybe 90% at the most, but emulation can't 100% replicate original hardware, no matter how hard you try. Although I would say the BIOS is replicated 99%, not 100%. Nothing can be emulation with 100% accuracy. Its emulation after, not replication. It will never be 100% accurate.
You've never even studied the GB BIOS, much less even looked at the assembly that composes it. You haven't any standing to say that. The BIOS is a 256-byte program that runs on startup.
We have the exact, byte-for-byte instructions that the GB runs for the BIOS, hence we know exactly what it's doing at any given time. This is like saying you wouldn't know what a program does 100% even when the source code is available and it's been reviewed by dozens of people. It's not a law in computer science that emulation can never be 100% accurate. It depends on what the original hardware is and what it does. With some hardware it's likely that we might not see 100% emulation, but other hardware might be a different story. Let's not forget that when there's money to be made, the original hardware vendors themselves do step up to make (as far as we know) 100% accurate emulators for older systems, a la Sony and Nintendo. The Virtual Console version of Mario Tennis absolutely beats any N64 emulator I've tried.
shoober420 Wrote:That is not the definition of upsclaing. That is your made up definition. According to wikipedia, it states:
Wikipedia Wrote:A video scaler is a device for converting video signals from one size or resolution to another: usually "upscaling" or "upconverting" a video signal from a low resolution (e.g. standard definition) to one of higher resolution (e.g. high definition television).
Did you read what you quoted from Wikipedia thoroughly? It's talking about a hardware device (called a video scaler) that's responsible for doing the upscaling. How do you think a video scaler converts the video signals from one size or resolution to another.
I'll give you a hint.
Upscaling doesn't use interpolation as if it were a tool in its overall process. Interpolation perfectly defines the entire process of upscaling on a broad mathematical level because interpolation is the very process that directly resizes an image. Upscaling happens to be a very specific form of interpolation to enlarge images.
shoober420 Wrote:You're a hypocrite, because you can't show it yourself. You just copy and paste code to a non-programmer and expect him to be able to find it. Since you are the programmer, you should easily be able to show proof that HLE isn't being used on the PPU. All SNES emulators prior to bsnes/higan couldn't emulate Air Strike Patrol correctly, and since bsnes/higan uses LLE, is that just a coincidence that its because of LLE? I don't think so.
Could you try to keep up with the points I've been making? Seriously, all the text is there, just read it. I've been trying to explain to you HLE doesn't have to be the reason for graphical glitches of that sort. I've already demonstrated to you that flawed or incomplete LLE implementations can be just as culpable (again refer to the gbemulator example) as HLE, therefore you can't just assume the glitch is outright caused by HLE. My point was that even if an SNES emulator used LLE, if they had a flawed implementation of mid-scanline rendering in the PPU, they'd still have issues. The point isn't about HLE or LLE, it's about getting mid-scanline rendering to work correctly. If you screw up your code or don't understand mid-scanline rendering well enough, it won't matter if the underlying code uses HLE or LLE. Both can be just as guilty. byuu and higan, avoided this by getting the implementation right. That says nothing about whether other emulators used LLE but didn't correctly implement mid-scanline rendering.
shoober420 Wrote:The reason it emulates correctly is because of LLE, something all the other emulators prior to bsnes/higan didn't implement on the CPU.
That's ridiculous, since you couldn't prove anything in the code of SNES9x's CPU used HLE, even though RachelB apparently examined it and thinks it uses LLE. I know from experience that using HLE in the CPU is an exceedingly rare occassion; most of the time it just isn't possible. This is due to the large-scale behavior (essentially running instructions based on random input, i.e. game code) and due to the fact that most of the instructions a CPU does are basic math operations that can't be broken down, shortened, or skipped. It's pretty hard to HLE one-off math operations such as XORing a single register, shifting another register right, or resetting various CPU flags. If you wanted to settle this for yourself, just ask the developers over at SNES9x (they're active as far as I can tell) and they should be able to answer you.
shoober420 Wrote:Talk is cheap. Until you are able to create the very first true LLE emulator to increase internal resolution, you have no say and are wrong.
There's that fallacy again. Just because something doesn't yet exist doesn't mean it can't ever exist. You know, before I started working on my Game Boy Enhanced, there weren't any other GB emulators that could utilize custom sprites (that is, replacing sprites and background tiles on-the-fly, without altering the ROM, much like Dolphin's Load Custom Textures). That didn't stop Game Boy Enhanced from doing it, or being the first to do it.
shoober420 Wrote:Since upscaling uses different types of interpolation, that can conclude that upscaling isn't at all interpolation, but that it uses interpolation. Not that it IS interpolation
That's not logical at all. The whole process of upscaling is interpolation (it fits the definition). Upscaling itself can be achieved through numerous methods (nearest-neighbor, bilinear, HQ2X), but that hardly means that those methods aren't interpolation (they are
according to Wikipedia) and that hardly means that upscaling isn't interpolation (which it is, as has been explained and demonstrated to you countlessly).
shoober420 Wrote:Oh that's very on topic bro. If the CPU uses an LLE interpreter, but the emulator itself is HLE, it still uses HLE on the CPU in some form, making it not a true LLE CPU emulator (unlike MESS which is).
Go back to where this was introduced in your other thread. We were talking about the z64 LLE plugin for Mupen64Plus:
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.
Which caused us to debate on whether or not N64 emulators use HLE on the CPU. We then looked at some code from Mupen64Plus for the emulated CPU, and I detailed how it's LLE'd. Now you're saying how Mupen64Plus is derived from Mupen64 and saying that it's not a full "true" LLE emulator. What does the fact that it's not an LLE emulator matter? You said it used HLE on the CPU, and that's wrong. I get the feeling that you think if HLE is used in one area, it will affect other parts of the emulator even if they are LLE'd, which is probably why you're bringing up the fact that Mupen64Plus isn't an LLE emulator.
The inaccuracy of, say, an HLE'd GPU (Glide64 for example) wouldn't affect the accuracy of an LLE'd CPU, although it obviously affects the overall accuracy of the emulator. Say the Glide64 plugin is raising an interrupt at the wrong time; the interrupt get processed by the CPU, but it causes it to crash since it read from memory that wasn't available yet. Since the CPU is accurate as far as LLE is concerned, it's doing everything it's supposed to, just like real hardware (we'll assume real hardware would crash as well from trying to read unavailable memory). It's the graphics emulation that's the culprit, but the behavior of the CPU stays true to the N64. I've done this a few times myself when I took shortcuts with sprite rendering in early versions of Game Boy Enhanced. The underlying CPU was doing everything it was supposed to (it was LLE'd of course), bit-for-bit, it was just that my sprite rendering wasn't working correctly (it was somewhat HLE'd at the time, just trying to get things drawn on the screen).
In short, using HLE in one department doesn't somehow mean everything else is suddenly using HLE or even affected by the parts that do use HLE. It just doesn't work like that.
fagoatse Wrote:See mednafen's psx core thats low-level and uses software rendering while being relatively easy on resources(2.0 GHz dual core required
What's this? Someone else who sees the glory of Mednafen?
I was surprised when I first ran it on my laptop (T3400 @ 2.16 GHz) and it ran smooth as butter and more accurate (read: less issues) than the other PSX emulators that'd I'd been using. Anyway, this is a continuation of the "Wii Backwards Compatibility" thread in General Discussion, just without posts going towards our post counts now.