Wii Backwards Compatibility

[Scootaloo]

(06-29-2013, 08:17 AM)shoober420 Wrote:

(06-29-2013, 07:37 AM)jimbo1qaz Wrote: LOLOL don't do 98.
You can use windowed mode on the original resolution to play it near the original

Well, the thing is, I want to play it fullscreen. What if I kept it in windowed mode and just maximized the window to be fullscreen? Wouldn't that upscale the image?

Just out of curiosity what do you have against playing on high resolution(s)?

For instance I can play KH1 on PCSX2 with AA, scaling, and quite a few other enhancements. However the game still looks just as good, except it has less jagged edges, and overall it looks a lot better than the original. Maybe I'm just comparing two different things, but what is wrong with having enhancements that make things overall look better?

I understand that with older consoles (NES, SNES, etc.) increasing the size too much will probably make some of the sprites/environments look bad or simply wrong. Other than that though I'm not sure what you mean.

[shoober420]

(06-29-2013, 08:24 AM)Scootaloo Wrote: Just out of curiosity what do you have against playing on high resolution(s)?

For instance I can play KH1 on PCSX2 with AA, scaling, and quite a few other enhancements. However the game still looks just as good, except it has less jagged edges, and overall it looks a lot better than the original. Maybe I'm just comparing two different things, but what is wrong with having enhancements that make things overall look better?


I understand that with older consoles (NES, SNES, etc.) increasing the size too much will probably make some of the sprites look bad or simply wrong. Other than that though I'm not sure what you mean.

I only want to keep the native resolution for 2D games. For example, in Doom, the 320x200 resolution gives the pixels a more rectangular look then a square look (this goes for all games played at that resolution). This can give a way different look to the game, and upon just learning that 2D emulators don't increase the native resolution of the console and upscale instead, I'm now totally against it. I want to keep it authentic as possible.

[NaturalViolence]

You really need to understand the difference between scaling and rendering if you haven't already learned it. Most of your misinformation seems to stem from not understanding what these words mean. And no you can't arbitrarily redefine words when it suites you. These words have universal definitions, you need to follow them. You can't just decide that "upscaling the internal resolution" means "increasing internal resolution" because that's not what the word means. It doesn't matter what you think it should mean because it already has a definition. You also need to look up what "fixed resolution", "native resolution", and "interpolation" mean, among other things.

shoober420 Wrote:I'll take your word for it.

shoober420 Wrote:I'm still having a hard time believing it.

These statements make me believe that you still don't understand what we've been trying to explain to you. You've concluded that shonumi is right, but you don't seem to understand why. Which is what we've been trying to explain to you. You really need to do more research on these topics before you comment on them next time. And you really need to look up any terminology that you use if you are in any way unsure about your understanding of them. Wikipedia does actually have good articles on all of the terms that you used incorrectly. I would start there if I were you.

shonumi Wrote:but my point was that we don't use that as an excuse to go about correcting people (well, maybe not NV Wink)

You think this is fun for me? This is horribly tedious and frustrating. When I answered his question I didn't expect him to disagree with anything I said because it's all common sense and and widely known facts that can be easily confirmed. I just wanted to answer his question. Correcting people who fight back without an understanding of the subject at hand and view their misinformation as opinions is never easy or fun. I do it only because reading these things annoys me and because people deserve to be educated when they're wrong. Opinions deserve to be criticized. Misinformation deserves to be disproved. I'm far more adamant about the latter as you can tell.

The only people who have "fun" in these discussions are trolls. And I don't believe in that type of response. It's annoying and benefits no one.

[Shonumi]

shoober420 Wrote:Shonumi, I didn't mean to make you feel remorse for typing all that. I simply don't want to argue anymore.

I wasn't that disappointed by your first response. :p But I am a bit concerned that you're still holding on to some positions. I'll get to those in a moment.

shoober420 Wrote:HLE emulators far outweigh the accurate LLE emulators that don't allow increasing the internal resolution.

I'm still not sure either one "outnumbers" the other, at least not yet. It would be nice if you did a comparative list if you wanted to prove your point; just look at emulators for systems that might be capable of using an internal resolution (emulators for the Sega Saturn, Dreamcast, PSX, N64, PSP etc). I already gave some examples, perhaps you could expand it.

shoober420 Wrote:Not until recently have LLE emulators sprung up with the rise of overall CPU power. Back then, even 2D emulators were mostly HLE, like nesticle for example (I'm pretty sure its an HLE emulator). They are definitely way more HLE emulators then LLE ones. I also can say HLE and LLE, because LLE emulators do NOT allow to increase internal resolution. Main reason being, they are after accuracy. LLE goes for accuracy, and HLE goes for better graphics and/or speed.

You should clarify what specifically is being LLE'd in the emulators you're talking about; as far as I can tell, you're specifically referring to using LLE for graphic emulation. HLE works by knowing the large-scale behavior of a system (or a system's component) and being able to reliably reproduce that without having to go through all of the steps real hardware would necessarily have to do. Going back to the Game Boy (again, the original DMG version), the BIOS is most often HLE'd simply because it's just a 256-byte program that drops the Nintendo logo, makes a chime, then writes a bunch of values to MMIO registers and CPU registers (the same values every time, more or less). The first two parts (logo and chime) can be skipped in a GB emulator. On boot, an emulator only needs to know which values in memory the BIOS usually writes to and enter them in manually. If you wanted even more HLE, a GB emulator needs only set the Program Counter to 0x100 and ignore other values the BIOS writes to (GB programmers were taught not to rely on the BIOS values probably because Nintendo envisioned later GB versions with different BIOS like the GBC, so games often change any important values anyway). Of course you could use LLE, which just runs the BIOS like normal GB assembly.

The graphics are a different story for a number of systems, 2D ones especially. There aren't many "shortcuts" you can take with graphics as I demonstrated with the BIOS. Most of the pixel data must be acquired and processed from memory. For systems like the NES, GB, Genesis, you usually have to read VRAM or something similar to create a tile based on the internal image format of the system (pixel encoding and palette for example) then decide where and how the system wants it to be drawn onscreen. The large-scale behavior of the system's graphics can't be broken down any further, nor can any major steps be removed. Minor segments can sometimes be HLE'd, but for the most part, you have to use LLE for graphics emulation on these systems. Newer systems, on the other hand, have more levels to emulate with higher complexities, thus they may be prime candidates for HLE depending on what they do. Lastly, I can't find anything about Nesticle using HLE for the graphics on Google.

As such, LLE has been around for quite a while in handheld and console emulation. In addition to LLE being the only way of doing something (since it couldn't be shortened or othewise skipped), it was also fairly straight-forward if you understood the hardware (just do what the hardware do). It's actually been the other way around; only until very recently was HLE demonstrated as a viable for emulators of modern systems. Have a look UltraHLE.

One other thing, it's possible to use the z64 plugins for Mupen64Plus (which LLEs the N64's graphics and RSP), however, it's still possible to use larger, non-native internal resolutions. All the calculations are about as accurate as the author of the plugin could make; the only thing that isn't is how the emulator decides to display said calculations on screen. I really wouldn't say this is HLE, no more than having higan use HQ2X. Mupen64Plus merely takes output from the z64 plugin and decides how the user should view it. As far as I know, the Mupen64Plus core changes the data; the z64 plugin knows nothing about it once it hands the data off. It's not really valid to say that emulators that use LLE for graphics can't or don't alter the internal resolution while ones that HLE the graphics can.

shoober420 Wrote:But I see nothing wrong in saying upscaling the internal resolution to mean increasing internal resolution.

Then you obviously have failed to realize the significant differences between the meanings of each phrase, which has been expounded on extensively for the past few pages. That's your choice though.

shoober420 Wrote:Its just when I see games that are upscaled, they look blurry and the pixels blend together. I haven't come across a sharp looking upscale, which is why I assumed that 2D emulators upped the native resolution to whatever you choose. It just looks so sharp, that I couldn't think it was an upscale.

Well, at least you've learned that the Nearest Neighbor filter is a method of upscaling. Just like Scale2x, it doesn't introduce any new colors, hence you get a "sharp" look. As soon as you start creating new colors from existing (or non-existent) pixels, scaling filters can enter into the territory of blurriness (like the much maligned bilinear filter. Okay, maybe only I hate it that much...). It's a really fascinating study in how the algorithms determine how to maintain visual fidelity, smoothness, and how close they choose to stay true to the original image. I could bore you with the mathematics some time if you want. Given that you're a "purist" when it comes to emulation (you want a 1:1 recreation of the experience) I'm not sure how interesting you'd find it though

Personally, I don't care if the graphical output is 1:1. When I emulate my games, I'm trying to recreate the thoughts, feelings, and excitement that I found when playing the game. For me, the graphics are just one element in the overall experience. As long as the core experience is the same - as long as it's fundamentally the same game - I'm all too happy to play a game again, scaling filters or not. This is personal preference of course, and everyone's tastes vary. Also, good luck playing at native resolution with absolutely no filters. If you really are against all upscaling, then you'll have to forfeit nearest neighbor scaling, fullscreen that stretches, and even playing old games on a high-definition TV. Those situations all involve upscaling. You'd have to play in a tiny window that's exactly the same width and height as the native resolution. Hey, it's technically authentic :p

scootaloo Wrote:I understand that with older consoles (NES, SNES, etc.) increasing the size too much will probably make some of the sprites/environments look bad or simply wrong.

Depends on the filter. Some can go overboard with their smoothing or introduce too many colors in places, reducing vibrancy. I'm a fan of the Scale2x filter (not just because I know it well), since it does perform primitive antialiasing, and it maintains the original colors. With Scale3x and Scale4x, some shapes begin to look mishapen. For the most part, it's good for 2D (especially older ones) and some 3D games. I'm partial to HQ4X or HQ2Xs though for 2D games with complex colors (various SNES games, PSX games, DS games).

NaturalViolence Wrote:You think this is fun for me? This is horribly tedious and frustrating. When I answered his question I didn't expect him to disagree with anything I said because it's all common sense and and widely known facts that can be easily confirmed. I just wanted to answer his question. Correcting people who fight back without an understanding of the subject at hand and view their misinformation as opinions is never easy or fun. I do it only because reading these things annoys me and because people deserve to be educated when they're wrong. Opinions deserve to be criticized. Misinformation deserves to be disproved. I'm far more adamant about the latter as you can tell.

The only people who have "fun" in these discussions are trolls. And I don't believe in that type of response. It's annoying and benefits no one.

Yo, check the smiley. I'm almost never serious when there's a smiley involved I didn't seriously mean you enjoy this sort of thing. By all means though, you've a right to dispel that notion so people don't get the wrong idea about you, which has happened, as I've seen. You sometimes get labeled as the "resident argumentative bad guy" (made-up title btw) by people who don't understand why they're actually being corrected. I only enjoy these types of discussions as far as it's a chance for people to learn and an oppurtinity to share what I know (if I know anything substantial).

[shoober420]

I haven't ran across a LLE emulator that allows you to increase the internal reoslution, since LLE emulation is about accuracy. I don't have Linux so I can't test Mupen64Plus.

[Shonumi]

Mupen64Plus runs on Windows and OS X as well. You'll have to find or compile the z64 plugins yourself, however.

[shoober420]

I just thought of something. Going by what you're saying about emulators being both HLE and LLE, that would mean there are definitely more HLE emulators. Since like you said, some LLE emulators do contain certain HLE on certain chips. Meaning, there are most surely more HLE emulators then LLE emulators. I highly doubt that Mupen64Plus allows increasing internal resolution if its truly a LLE emulator. If that were the case, there would be more LLE emulators out there that allow increasing internal resolution. So regardless of what you and NaturalViolence say, I cannot see any possibility that LLE emulators are more common then HLE emulators. There is just no way.

About upscaling internal resolution, that Pikachu picture from Super Smash Bros. on the left is upscaling the resolution, not the INTERNAL resolution. If you upscaled the internal resolution, Pikachu would look like the picture on the right. Why you, NaturalViolence, and the rest can't understand this, I have no idea.

Shonumi Wrote:Well, at least you've learned that the Nearest Neighbor filter is a method of upscaling.

No its not. Its a method of interpolation. It has nothing to do with upscaling. You can apply a filter to an image without doing any sort of upscaling. For example, like using bilinear or trilinear is 3D games. When you use a texture filter, it doesn't upscale at all, it just apples the interpolation method to the texture to smooth it out. No upscaling is involved. Though it is common to use interpolation on upscaled images, because if you didn't, they would look like poop.

[Shonumi]

(07-02-2013, 01:36 PM)shoober420 Wrote: I just thought of something. Going by what you're saying about emulators being both HLE and LLE, that would mean there are definitely more HLE emulators. Since like you said, some LLE emulators do contain certain HLE on certain chips. Meaning, there are most surely more HLE emulators then LLE emulators.

Again, you keep saying "HLE emulator" and "LLE emulator". Please define or narrow it down to what you mean. Are all processes (the whole emulator) LLE'd? Are some processes LLE'd and others HLE'd? Does an emulator that HLEs one tiny function and LLE the rest constitute an HLE or LLE emulator? Vice versa? You seem to only be talking about the graphics, so when you say HLE/LLE emulator, please just say "emulators that LLE the graphics". Otherwise it's very, very vague and difficult to understand what you're talking about.

If you're only talking about graphics, then you're still mistaken. Nearly every emulator for any system up to the 5th Gen emulates the graphics via LLE, for the specific reasons I mentioned in my previous post. HLE is not really going to happen because there aren't any shortcuts or steps you can take out of the equation for these systems. There are tons of emulators for such older systems, and I would reckon that currently the number of these emulators exceeds the number of newer emulators that rely on HLE to emulate the graphics. It's far from an exhaustive, comprehensive list, but Wikipedia will give you an idea. Just look at how many emulators are available for consoles and handhelds like the NES and the Game Boy in comparison to PSX, N64, DC, or PSP emulators.

Again, if you want to prove it, make a list like I suggested for emulators that use LLE for emulating the graphics and ones that use HLE for emulating the graphics. It should be pretty simple to count once you have all (or enough) entries.

(07-02-2013, 01:36 PM)shoober420 Wrote: I highly doubt that Mupen64Plus allows increasing internal resolution if its truly a LLE emulator. If that were the case, there would be more LLE emulators out there that allow increasing internal resolution.

There's that ambiguous phrase again. Please specify what "LLE emulator" means. Again, I'm assuming we're talking strictly about graphics, since that's where this discussion has been going for a long time. There's little to doubt if you know how emulators work or how others design emulators. Mupen64Plus is plugin-based; it has an API that abstracts sound processing, graphics processing, and input handling from the core. The plugins do their job, then they hand over the data to Mupen64Plus using the API. The API ensures that plugins have a standard way to communicate with the core. The z64 plugins emulate the RSP (Reality Sound Processor) and the graphics via LLE, again, as accurately as the author could make them (the N64 is notoriously missing on documentation). The plugin then hands over the data to the Mupen64Plus core, which can decide to do whatever it wants with it. Take this fake conversation as an illustration of how it works:

Spoiler: (Show Spoiler)

Core: Hey there Z64, what do you have there?
Z64 Plugin: Oh, just another frame I finished rendering. It's all yours.
Core: Great, send it over.
Z64 Plugin: I rendered it as accurately as I could, just like an N64 I think. But I heard the user wants to play this game in 1080p :/
Core: No problem.
Z64 Plugin: What? How so? :0
Core: You only gave me the raw data, data that says "draw this polygon here, draw this polygon there." You haven't drawn it to the screen yet. All I have to do is scale the vertices and whatnot. Nothing else changes, so you've done your job accurately. Only the final, 1080p won't be "accurate", since it's in HD ;)

Or something along those lines. I've not looked at Mupen64Plus' plugin API, so it could be the other way around, where the core tells the plugin to do the scaling, rather than doing the scaling itself (this makes more sense, since it keeps everything segregated). At any rate, the plugin is doing everything accurately via LLE. Scaling the resolution at the end does not (or at least should not if programmed correctly) affect the accuracy in any sense other than that's not the N64's native resolution. Again, it's no different from using something like HQ2X on Higan; it's an enhancement done at the very end of the rendering process. Every graphical plugin compatible with Mupen64Plus is capable of having the internal resolution increased; it's most likely a function of the plugin API. The z64 graphics plugin is no exception.

(07-02-2013, 01:36 PM)shoober420 Wrote: About upscaling internal resolution, that Pikachu picture from Super Smash Bros. is upscaling the resolution, not the INTERNAL resolution. If you upscaled the internal resolution, Pikachu would look like the picture on the right. Why you guys can't can't understand this, I have no idea.

You're saying that like we are the ones with the misconception. The picture on the left was demonstrating what your incorrect terminology was referring to (upscaling the internal resolution) the one of the right demonstrates the correct usage (increasing the internal resolution). I already pointed out the upscaling involves using algorithms to estimate the missing pixel values of a larger image. "Upscaling the internal resolution" would mean taking an image of an arbitrary internal resolution (1x for example), and using an algorithm to scale it to a larger size. That's exactly what the one on the left is doing. "Increasing the internal resolution" would mean taking an arbitrary resolution and multiplying the 3D data used in the scene before rendering it to get pixel values. These are two completely different approaches.

(07-02-2013, 01:36 PM)shoober420 Wrote: No its not. Its a method of interpolation. It has nothing to do with upscaling. You can apply a filter to an image without doing any sort of upscaling. For example, like using bilinear or trilinear is 3D games. When you use a texture filter, it doesn't upscale at all, it just apples the interpolation method to the texture to smooth it out. No upscaling is involved. Though it is common to use interpolation on upscaled images, because if you didn't, they would look like poop.

Not trying to sound aggressive or anything, but I honestly wonder if you read the things I post :( For example this quote from Wikipedia - Image Scaling:

Wikipedia Wrote:Enlarging an image (upsampling or interpolating) is generally common for making smaller imagery fit a bigger screen in fullscreen mode, for example. In “zooming” a bitmap image, it is not possible to discover any more information in the image than already exists, and image quality inevitably suffers. However, there are several methods of increasing the number of pixels that an image contains, which evens out the appearance of the original pixels.

Upscaling has everything to do with interpolation because it is interpolation. Interpolation is

Wikipedia Wrote:a method of constructing new data points within the range of a discrete set of known data points.

That's what upscaling an image scaling does. You have to create new pixel data using existing pixel data. Nearest Neighbor upscales an image; it creates new pixel data. With 2x Nearest Neighbor, you generate 4 pixels of output for every 1 pixel of input. Filters like Nearest Neighbor, HQ2X, SuperEagle, etc, are all methods of upscaling. Unless you have multiple copies of an image at various resolutions, you can't scale raster graphics without creating new pixel data.

Additionally, texture filtering will upscale (and conversely downscale) textures depending on how close or how far away a textured object is from the camera. If you move the camera very close to a textured 3D object, the textured face of the object could eventually occupy the whole screen. Since the texture is at a fixed resolution, texture filtering helps determine what that texture should look like as the camera moves closer or farther and at different angles. By necessity, it has to upscale or downscale the image. Have a read at this if you need further understanding: http://gaming.stackexchange.com/questions/48912/whats-the-difference-between-bilinear-trilinear-and-anisotropic-texture-filter

[Scootaloo]

(07-02-2013, 03:01 PM)Shonumi Wrote:

Spoiler: (Show Spoiler)

Core: Hey there Z64, what do you have there?
Z64 Plugin: Oh, just another frame I finished rendering. It's all yours.
Core: Great, send it over.
Z64 Plugin: I rendered it as accurately as I could, just like an N64 I think. But I heard the user wants to play this game in 1080p :/
Core: No problem.
Z64 Plugin: What? How so? :0
Core: You only gave me the raw data, data that says "draw this polygon here, draw this polygon there." You haven't drawn it to the screen yet. All I have to do is scale the vertices and whatnot. Nothing else changes, so you've done your job accurately. Only the final, 1080p won't be "accurate", since it's in HD

I felt obligated to post this after reading that: http://imgur.com/gallery/Y2FdtVE

[Shonumi]

Oh, now I'm embarrassed because I'm really not sure that's how Mupen64Plus communicates with the Z64 plugin (as I said earlier, it might be the other way around, where the plugin does the scaling, the core just tells it how much).

At any rate, if an image is worth a thousand words, I wonder how many words a couple million pixels are worth. It's just visual proof of z64 scaling the internal resolution of Super Smash Bros. to 720p. The window title tells you it's rendering using Z64gl, and the console output matches it. You can notice aliasing (don't have it forced via Nvidia drivers) but it's definitely not using a scaling algorithm. Dial-up users, beware!

Spoiler: (Show Spoiler)