Star Wars Rouge Squadron gfx bug

[theboy181]

[AmbientMalice]

LLE mode for reference:

[olivieryuyu]

good eyes :)

[theboy181]

@AmbientMalice how did you get it working in LLE? when I tested it was messed up for me.. Latest build?

[AmbientMalice]

The game has always worked in LLE. What do you mean "messed up"?

[oddMLan]

Disable Antialiasing for LLE. It doesnt play well with it

[theboy181]

@oddMLan that seems to work with LLE, but not HLE.. also I like AA..

[AmbientMalice]

also I like AA.

Personally, GLideN64 should never have implemented MSAA. It breaks things, and SMAA/FXAA would have gotten just as good results.

[theboy181]

If I understand correctly MSAA has the best visual quality? I think he made the correct choice, but options are always nice.

I think it would be very cool if he implemented VI shaders, so the games could render as the developers had planned, and the ability to force different filters on/off would be a bonus too.

[AmbientMalice]

If I understand correctly MSAA has the best visual quality?

No, and it's a fundamentally wrongheaded method of AA in emulators. Plus it fell from favor in games years ago, replaced by post-processing and temporal AA methods. PCSX2 hides in it a hack menu, and it causes a lot of side effects in Dolphin. Post-processing AA has no side effects. MSAA just makes things worse.

[oddMLan]

You sure postprocessing AA had NO side effects? How about the smears created with complex objects + fast camera movement on screen. Plus unless you use a expensive version of temporal antialiasing the image just doesn't look as crisp, MSAA which is arguably one of the oldest methods still objectively provides the best visual quality. Only thing it doesn't do is smooth out 2d objects. You might prefer one method better than the other but, please, don't recur to hyperbole making x thing seem way worse than it actually while championing y thing because you of your personal preference. I've seen you do this many times already, but don't see this as a personal attack, just a constructive criticism.

[theboy181]

I think ambient just likes to keeps things entertaining. I usually take his opininions extremely lightly. However I have seen others waste a lot of time tryin to convince him they are opinions. ;)

[AmbientMalice]

You sure postprocessing AA had NO side effects?

Yes.

How about the smears created with complex objects + fast camera movement on screen.

Only temporal anti-aliasing causes smearing. And temporal anti-aliasing is not, strictly speaking, a post-processing AA solution.

Plus unless you use a expensive version of temporal antialiasing the image just doesn't look as crisp, MSAA which is arguably one of the oldest methods still objectively provides the best visual quality.

It is not objectively the best visual quality because it break things. Broken graphics are not "objectively the best visual quality". You may as well use supersampling, which in GLideN64's case would also break things because once you go past around 2x native resolution all the 2D alignment starts to fall apart. But it would break fewer things than MSAA.

You might prefer one method better than the other but, please, don't recur to hyperbole making x thing seem way worse than it actually while championing y thing because you of your personal preference.

MSAA in emulators (for consoles that didn't natively support it) causes a massive hit to accuracy and causes an endless array of bugs. Alignment problems are a very common one, as seen in Dolphin, PCSX2, and of course GLideN64. Post-processing methods don't have any side effects. They just smooth aliased edges. That's not hyperbole. Nobody should be using MSAA in GLideN64. It should never have been added. It breaks everything.

[oddMLan]

"It breaks everything." Wow. THAT'S hyperbole right there. MSAA only doesn't play well in LLE, but do no expect end users playing games in LLE anyways. For all purposes, MSAA works just fine in HLE while yes, breaking some stuff in games like Extreme-G. Due to the way N64-depth works, which is an option required for that game. It is warned that shouldn't use MSAA with it for that reason. But 5 games it breaks isn't "everything" by definition, buddy.

[AmbientMalice]

"It breaks everything." Wow. THAT'S hyperbole right there.

No, it causes 2D alignment issues in pretty much every single game. Similar to running the game at a high resolution. Which a lot of people do, unfortunately.

The problem with MSAA is that people use it.

[oddMLan]

But running a game in any other resolution other than native achieves the same defects. I must not notice much of the breakage anyways, because I only run games in multiples of native resolution, to avoid bilinear artifacts. I also don't notice any issues with AA playing on Dolphin, but they don't automatically scale the internal resolution to the window resolution unless you choose the option for it, which if you do, you'll inmediately notice similar misalignment issues. Instead they make multiples of internal resolution the default. So I don't think this is a problem inherently from MSAA, but games weren't designed to run in other resolutions. Post-processing AA would just be a workaround to that, but with reduced visual quality as result (unless you supersample it).

I agree it should be an option though. A post-processing shader backend would allow pretty much any post-processing effects users know and love, including post-processing AA. If only ReShade got along with GLideN64, without having to disable Framebuffer emulation to get access to the depth buffer.

[AmbientMalice]

But running a game in any other resolution other than native achieves the same defects.

Yes and no. MSAA's side effects tend to be more subtle.

Native resolution:

Native resolution with MSAA:

2x native resolution. No MSAA:

I must not notice much of the breakage anyways, because I only run games in multiples of native resolution, to avoid bilinear artifacts.

That doesn't really solve the problem of misalignment. The black line hack, and the option to render 2D elements at native resolution greatly helps, but the latter is expensive. I'm of the opinion that GLIdeN64 should default to N64 native resolution, with a warning that raising it will cause issues, but Gonetz was concerned about people complaining because the N64's native resolution is significantly lower than PS2/GC/Wii, which is a fair point but there is a long list of issues where the solution is "run at native resolution". Running above native resolution is an enhancement. It shouldn't be something that people use by default, IMO.

[AmbientMalice]

For the record, I'm sorry if I came across as smug and condescending. Essentially, the problem is that MSAA hurts accuracy quite a bit. I think it needs stronger warnings. Also, it should really be automatically disabled at 1x native resolution because it undermines the accuracy benefits of running at 1x native resolution.

[ghost]

Blame me. Problem solved.

[theboy181]

Then fix it @mudlord ;)

[retrobenny]

The VI shaders sounds like it would be a solution for rendering textures without either point-sampling or bilinear and thus being the original textures.
(if that is even possible,having them unfiltered then applying 5xBrZ or 6xBrZ could look amazing!)
Maybe even something like Waifu 2x could work seeing how some people clamor over wanting it on PS1 emulation.

Edit: Maybe having the options for not only Point-Sampling returning from its Glide64/GLN64 origin but also adding Nearest Neighbor to the filters would be great for enhancements applied on top of it since any bilinear by itself or the bilinear part of 3-point sampling makes enhancement shaders less effective because it still ends up blurry,even with Gonetz's improved bilinear due to the nature of that kind of filter.

I haven't seen nearest neighbor used on textures before,it may look great,its essentially the equivalent to not filtering textures at all like the comparison of zooming in a small image to your full resolution comparing unfiltered/nearest neighbor bilinear and the smoother and sharper looking but slower Lanczos.
Things with bilinear are always blurry while nearest neighbor keeps the original image into the stretched pixels plus enhancements would make it look extra good,and Lanczos would look decent for simple upscaling without even needing to use further enhancements but could benefit from any normal scale-based enhancement,then there is Waifu2x which could make things look similar to what it looks like with xBrZ enhancements but via only the filter alone and just looks really cool.

In the end,for the very least I would like to see what games look like with a basic nearest neighbor filter with and without enhancements applied.
(honestly don't care for AA because it is another thing that can blur the textures but Anisotropy helps for smoothing out rasterizing edges without as much of a performance hit)

[theboy181]

Campaign state only one bug. It I also opened an issue explaining how the swipe effect is broken when swiping from right to left too

[gonetz]

Swipe effect is not HLE related issue and thus not directly covered by the Campaign.
Texture bug you reported here reveals an issue in ucode implementation.
Of course, both issues need to be fixed, but only this one is introduced with new code.

[theboy181]

@gonetz anyway I can get around patreon for the builds?

[gonetz]

This bugfix, as well as other bugfixes is not related to Patreon early access. The code is already in git. I'll make new WIP build this weekend.

[olivieryuyu]

Fixed!

[theboy181]

:)

[olivieryuyu]

Closed?