byuu's message board

I was playing Mario 64 today with some "enhancements", including rendering at 1080p with AA and AF.



If that isn't obvious proof that enhancements affect accuracy, I don't know what is.

Actually, it looks like your plugin or drivers are at least having serious trouble with alpha transparency sorting.

The question is, what does accuracy even mean in the context of HLE?

I think we can at least settle on the baseline of "doesn't look completely fucked".

Drivers don't sort polygons, at least not in a way that changes the way the scene looks. You're referring to the blocky black edges around the glyphs at the top of the screen right? What's probably happening here is that those polygons are rendered w/o alpha blending (that's probably the setting the game intended) and only show transparent pixels if alpha = 0. Those edges would contain a gradient where alpha transitions from 0 to 1, but are only a hard 0 outside of the edge.

It's hard to tell for sure but I think you may actually see a little bit of these artifacts in the original game. That or they deliberately did weird outlines. I looked at this video here: https://www.youtube.com/watch?v=X7rmHeZ4zPE and in particular the area on the bottom left of the coin icon looks suspect. If these really are artifacts they're minimized because the texture resolution and alignment fits closely to the screen resolution. On the other hand, if it is supposed to look this way, either the image is perfectly aligned or bilinear filtering is turned off for it (in which case the emulator probably shouldn't be applying it either)

Having some kind of option to change the alpha test threshold may help...

No, I was referring to the skybox rendering on top of the level on the edge of the fence texture.

I know all about the "black alpha" problem. The problem there is that when you interpolate an alpha channel that was originally (effectively) point sampled, you can show data that wasn't originally meant to be shown. You can avoid this somewhat by somehow blending opaque pixels into fully transparent ones, but it's a huge hack -- another form of enhancement error.

I wish people wouldn't call resolution and other enhancements like this HLE. That really gets confusing. HLE is where you capture software routines and emulate them based on what the functionality is supposed to be instead of emulating the instructions that make up that that code. The naming parallels low level vs high level in programming languages.

If the 3D rendering was being done by some software routine on a processor and you intercepted that it'd be HLE (regardless of whether or not you then rendered it with a GPU or changed the resolution or filtered the textures or whatever). But this is almost never the case, or at least we don't have evidence of cases where there's secretly some processor embedded on the console generating 3D. In the cases where software rendering really is used in console games (like SuperFX, 32X, those 3D games on GBA, etc) I don't know of any attempts by emulators to change the way the rendering looks.

What you have is something where you're emulating something at the level of "draw this polygon" no matter how you do it. With these enhancements you're choosing to draw that polygon in a way where you know the end result isn't like what the console would have done. If you just try to draw it w/o enhancements but without extensively studying the console it'll probably still look slightly wrong, and most emulators of 3D hardware do. But here's the thing, even if you draw it so it looks exactly like the original the way the emulator accomplishes it is still probably going to be very different from what the embedded logic in the hardware does. And you're probably not going to know how the hardware does it precisely outside of some educated guesses. Unless you somehow got a transistor diagram of the GPU and emulate it at that level, the terms high level vs low level don't really apply to it.

I get what you're saying though, the whole point of these enhancements is to make it look wrong. It's not supposed to be accurate. I guess the criteria for best possible accuracy would then be:

1) Can the game code tell it's wrong, and to what extent? On N64, the game can read the framebuffer, so are you generating the framebuffer correctly in addition to outputting something else for the user?
2) How much does it fall in line with what the original developers intended? This can be kind of subjective, but there are still artifacts that are pretty easy to classify as unintended.. pretty much any kind of introduced visual discontinuities...

I didn't notice that, but I'm sure that's something else than being sorted out of existence...



Yeah, isn't that what I said?

The big question is still this: did the game enable filtering on those polygons to begin with? You're assuming it didn't, but I think it did. If it didn't then the emulator shouldn't.

Looks like it asks the ucode to filter both the alpha and the texture.
http://i.imgur.com/bLTdTaP.png
At least glide64 thinks so. Not sure what an LLE graphics plugin would do.

> HLE is where you capture software routines and emulate them based on what the functionality is supposed to be instead of emulating the instructions that make up that that code.

I was never sure why the ZSNES/SNES9x emulation of the DSP-(1,2,3,4), ST-01(0,1) and Cx4 weren't called HLE. But that's exactly what that was.

> What you have is something where you're emulating something at the level of "draw this polygon" no matter how you do it.

Now that's interesting to me. I obviously haven't written an N64 emulator, but I have always assumed that knowing you were executing a function that was "render a polygon here" (HLE) would be easier to scale to 1080p with new textures than if you were executing "add 1 to this register" (LLE). So for that reason, I've considered upscaling to be something that benefited from HLE, and thus usually (but certainly not always) went hand in hand.

But if in the end the output of the LLE is to a queue that gives you the same render commands, then yeah. You could easily do upscaling with LLE. Which is great news, because I really have a hard time enjoying N64 games at 320x240.

Do you know how the frame buffer aspect works on the system? My understanding was that Mario Kart 64 would render the screen to a texture, and then put that texture onto a "monitor" that you could see on the track. Seems like you'd have to emulate writing out the proper image at 320x240 for that to look right, but then you could take the final image and scale that up.

> I guess the criteria for best possible accuracy would then be

I think it would be fair to say that if you could get raw digital RGB output from the N64 ... that accuracy would mean it not being possible to tell the difference between emulator output and N64 output to that same TV. But being able to compare it at a superhuman level, down to each pixel, detecting the most infinitesimal timing differences, etc.

But it's also very fair to categorize hardware emulation accuracy and output display accuracy separately. In theory, the latter should be 100% undetectable to the game, and never interfere with its operation. It just may look like crap in some cases like some of the pictures above.

Display accuracy also pushes you too much toward emulating a specific display, eg CRT+NTSC artifacts. Yet if you capture raw RGB and output it to an LCD, you're bypassing most if not all of those artifacts.

In a way, the idea of having the final output from the emulated processors being a display list, feels a lot like emulating a Vectrex display. And would seem to be the one thing that probably should exist as a plugin, or at least be entirely modular from the emulator core.

I (and most other people, I guess) only heard of the term HLE when UltraHLE appeared.

Because there's low-level emulation, high-level emulation, and then there's ultra-high-level emulation

There are degrees of HLE and LLE. HLE is how much you emulate something by its interfaces and outside behavior, rather than its internal mechanisms.

I think BSNES counts as LLE if you want to dichotomize it, but it's still HLE in a very pedantic sense where you apply HLE to emulating the behavior of the low level systems that make up the console rather than emulating said systems' transistors and shit.

At any rate, it's lower than most other SNES emulators. That you cannot deny.

Yes, very true. It emulates the SNES instead of emulating the games.