byuu's message board

Hi monochrome please respond to my post that is showing something directly contradictory to what you're saying that would help a lot thanks.

You clearly only understand if the online translation service you are using can translate correctly. Otherwise, you wouldn't have continued to quote massive images. This isn't 4chan. Try to use some courtesy and refrain from criticising others on a personal basis.

He can't understand, that's why he's not responding.

but
I made an ms paint diagram
AN MS PAINT DIAGRAM
;_;

Markov chain bots can't process images.

He said increasing internal resolution doesnt affect accuracy if its programmed correctly I take their word on it over yours.

I'm not giving you my word. I'm giving you a mathematical truth and an example proving that mathematical truth.

Please tell me how this example is not a proof that:
increasing the sampling rate of an image meant to be rendered at a set resolution will introduce elements that did not used to be there.

I set the important line alone to make it easier to comprehend.

I've got some submarine screen doors to sell you.

Oh, lord, this thread is back?

Monochrome1, you are my hero. I REALLY needed a laugh right now.

So here's something I came up with last night, talked about it with Sintendo cos the others were busy.

I call 'em "Low Impact Enhancements". Basically, it's any kind of "extra" that the original console didn't have, that the user can enable, and that enhances (or intends to enhance) the gameplay experience. Importantly, if the game can tell the enhancement is in play, it is not low-impact.

One example of a LIE (lol) would be post-processing like HQ2X or CRT shaders. The game can't tell they're there, they enhance the gameplay experience, and they're entirely up to the user to decide.

As a counter example, allowing simultaneous opposite directions would be a high-impact enhancement. Games can tell you're doing something that would ordinarily be physically impossible, and some of them are pretty silly in how they react, such as having the player character shoot off at roughly quarter impulse.

Now, how does this relate to increasing the render resolution of a 3D system? Easy. If the system has a framebuffer or similar method to tell what's actually on the screen, render two copies. One is in the native, un-enhanced form and goes into the framebuffer, one is non-native for display. Things like anti-aliasing and texture filtering would fall in the same category, with the same workaround. The only problem with this approach is that things like transitions may cause a sudden jump in quality.

Now, Sintendo came up with the example of a game with bad mesh data. On the system's native resolution, nothing seems to be wrong. But when rendered at double or better, gaps suddenly appear between edges. This is not so much a problem with rendering at double the size, but a problem with the game's own data that came to light under special circumstances. Which is why double-res rendering should be an option to enable at the user's discretion. Which is also why I put that "or intends to enhance" up there.

Unfortunately, texture packs cannot be low-impact; if the framebuffer copy is rendered with the texture pack, the game can tell. If it's not, the user experience becomes at least one order of magnitude weirder than a transition quality jump could ever hope.

FTFY :P

> But when rendered at double or better, gaps suddenly appear between edges.

HQ2x may not be as bad, but it definitely harms certain graphics, too. Super Mario Bros 3 (from Super Mario Collection) has a zig-zag texture at the bottom ground that is destroyed with HQ2x, but looks like glass with Scale2x. Donkey Kong Country looks terrible with it.

> Unfortunately, texture packs cannot be low-impact

You can't use the original texture for the framebuffer, and the nice one for the upscale?

Question though, do you have to use the native-res framebuffer when actually displaying that framebuffer onscreen, or is an IIR sequence acceptable for rendering? I would guess it is, but my mind's not fully working as I just woke up.

...

The problem why I look at hires 3D as being "high impact" is because of the changes you have to make to the emulator itself. But I'm told that 3D systems don't work like the conceptual "Starfox" model I have in my head.

The way I perceive it is that you have these low-level instructions (GSU1 instructions, or R4300i instructions->RDP micrcode) that you execute and it walks you through rendering. But emulators instead tend to go for HLE, and will flag a subroutine call at offset 0x20134800 as "render a triangle at the coordinates in r0, r2, r3 using the texture at address r8". Now it's a whole hell of a lot easier to multiply those by a floating-point number to upscale the triangle on the screen. But you're essentially cheating. When you want to do the accurate emulation / low-level rendering, you have to simulate all of those actual instructions. And I find that few people want to do both models. Although if you did, you could conceivably pull off even upscaled Starfox (although not with textures, since the game didn't have any. But you could do nicer dithering patterns, I suppose.)

But the way 3D systems actually work in practice is that the lowest-level output from the GPUs eventually end up being dispatch lists of "render a triangle at coordinates x,y,z using texture at VRAM address w", and Starfox is just a weird fluke from being made way before 3D had a chance to develop into something remotely powerful yet. So yeah, given those circumstances, 3D upscaling isn't really cheating so long as you do that framebuffer copy.

That is correct. Star Fox doesn't use a 3D accelerator in the conventional sense. Same with 32X games. But starting with consoles like 3DO, PS1, Saturn, etc that started to change. And this is really just an extension of what consoles were doing with 2D - you didn't have a processor with instructions that explained how to draw sprites, and to get a little closer to what 3D does, you didn't have a processor that calculated anything for affine transformations in SNES's mode 7.

These days GPUs have moved a lot back towards programmability, where the shaders do a bulk of the work in making graphics happen. But they still have fixed function blocks that convert from triangles to pixels, and some other important stuff.

Watch and enjoy as this in-game screen in Mario Kart shows different character textures than the player is actually seeing:



Or watch the pause menu in Ocarina of Time suddenly revert the 3D scene in the background to original textures until you leave it.

Still, HQ2x and its ilk are optional, and the game can't tell you're using them. If a game looks like shit with a certain filter on it, you can remove the filter. To the game, it makes no difference.

> You can't use the original texture for the framebuffer, and the nice one for the upscale?
Thank you, Covarr, for that screenshot. If you were to use a texture pack for the regular scene and the game's own for the framebuffer, that screen would show a visually clearly distinct image that goes way beyond mere resolution and maybe a lack of AA.

> Question though, do you have to use the native-res framebuffer when actually displaying that framebuffer onscreen, or is an IIR sequence acceptable for rendering?
I'm not sure what you mean by IIR.

That shoober guy in the dolphin thread seems kinda like Monochrome, maybe they are the same people? Cept shoober has better English.

Monochrome seems to be the only one who thinks artifacts from upscaling doesn't means it's inaccurate. Or that because a game won't crash or have any major gameplay bugs pop up due to upscaling it can't effect accuracy. So because he doesn't view accurate emulation of the output of a console a part of emulation accuracy he will never agree with the ones that do. I like and use upscaling but I consider upscaling inaccurate to the original consoles output.

Edit: Might as well add something I saw that neobrain said at dolphin
"... and as should be stressed, there's no proper fix for anything higher than 1xIR due to the nature of non-native IR. It's just not as on the console, hence it's not guaranteed to work properly. People may be lucky using a particular choice though, e.g. on my system 3xIR works while 2xIR doesn't."

Why is this happening though? Either the texture replacement is defective, or it's incomplete.