S2DEX: all issues listed here please!

[olivieryuyu]

1896

1897

1870

1869

1695

1619

936

1518

315 (is it ucode issue though?)

329

133

[theboy181]

@gizmo98 Yes it looks really good! Is this a per game hack? this doesn't seem to make Puyo Puyon Party (J) look any better.

Are there other s2dex games that take advantage of the changes in this fork?

[theboy181]

One other think is the left eye on the right most hamster is missing an entire row of vertical pixels. in NATIVE mode, and in 2x mode and above there are multiple issues still

[gizmo98]

@theboy181 This is no per game hack. I read somewhere texture clamp is on if st values are smaller or equal to texture width and texture height. I enable clamp_to_edge if this condition is met.

The eye of the hamster could be a little bit better. I cannot see lines if i use nativeRes=0 with multisampling =0 or 2:

[theboy181]

I'm not being nasty here, but there are other issues all over this picture.

I agree its better, but I bet if you counted the pixels in AL plugin and GLideN64 plugin both using 640x480 output resolution you are going to find some lines of resolution are still missing, and that the pixels are not in the same positions.

[gizmo98]

@theboy181 Yeah. Higher resolutions still look a little bit weird. But there are no seams anymore. NativeRes=1 looks in my opinion good. Have you found any regressions? I think 2D elements and 2D games are most of the time not supposed to be used with higher resolutions.

Could you test another branch? I modified the bilinear filter a little bit to remove outlines around transparent parts of a texture. Don't use 3-Point filtering. I was not smart enough to modify this filter. https://github.com/gonetz/GLideN64/compare/master...gizmo98:bgclamp4?expand=1

Kirby has no white lines around menu icons if NativeRes > 1.

Hamster 64 start screen has no black lines around the text if NativeRes > 1.

Mario Kart 64 trees have no black outlines.

Puyo Puyo looks better:

Starcraft cursor and message boxes look good (not compared with current master but both things were broken last month)

[gizmo98]

If i compare my current branch with master only mario kart character selection screen looks worse if nativeTexRecs is not enabled.

master vs bgclamp4 branch nativeTexRecs = True nativeTexRecs = False

[Jj0YzL5nvJ]

Good job @gizmo98

'gonetz/GLideN64@4f302cc7773fa79edd540025f7fd593b00bd1f0c' https://0x0.st/sYhh.png

gizmo98/GLideN64@8fa221752e7d86e5b6a029d3d38b3ceff298985a https://0x0.st/sYhF.png

Unfortunately, the Jinjos of Banjo-Kazooie continue immutables u.u

gizmo98/GLideN64@8fa221752e7d86e5b6a029d3d38b3ceff298985a https://0x0.st/sYhC.png

[oddMLan]

@gizmo98. Everything looks good, but the kirby save selection screen looks worse IMO.

[CallistoNTG]

There's a thin red line on the right hand side of inventory elements with bgclamp4.

Some other issues. PD pause menu has fractals. Conker vegetation distorted.

[gizmo98]

@gonetz I rewrote bilinear filtering to have color-bleeding. According to this article another approach is premultiplied alpha: http://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/ Is it possible to implement this approach as well? Blender equation needs to be modified.

[CallistoNTG]

@gizmo98 Just so you know, every branch after bgclamp4 looks like this for me. There's a decent chance you're aware, but there is a slim chance it only happens on certain GPUs or something like that.

[gonetz]

@gizmo98 Very interesting article, thanks! The idea is nice and clean, but I'm not sure that it can be easily adopted to our case. N64 blending equation generally is not that simple, especially for 2Cycles mode.

[oddMLan]

Maybe the color-bleeding bilinear filter can be implemented as an user setting? Next to the "fix black lines" options. Because while it does help in some places it causes issues in others.

Also I stumbled across this article a while ago... not sure if it helps in this situation. Might be worth a try. https://colececil.io/blog/2017/scaling-pixel-art-without-destroying-it/

[theboy181]

I just saw this and I wonder if it applies to any of the alignment issues in GLideN64

https://www.supermodel3.com/Forum/viewtopic.php?f=7&t=1585

[gizmo98]

This sounds familiar. The bgclamp commit adds an combination of GL_CLAMP_TO_EDGE and GL_REPEAT for background textures and should work like the supermodel3 fix. ;-)

I also tried to implement texture bleeding like described there. But as you can see above the result is not perfect atm.

[theboy181]

@gizmo98 Is there anything different going on with Model 3 fixes? the have an in depth link in the forum post I linked too.

[gizmo98]

It works a little bit different. Supermodel solution should only work if texture format has 1Bit alpha. I can modify my filter for testing.

[theboy181]

:)

[gizmo98]

@theboy181 you can try this branchs bilinear filter with supermodel solution: https://github.com/gonetz/GLideN64/compare/master...gizmo98:betteralpha?expand=1

Conker and Perfect Dark seem to look good at first glance. Puyo Puyon Party looks better as well.

[oddMLan]

Current master:

Your build:

Make sure you delete any shader cache to be able to see it.

[gizmo98]

This looks really weird. :) But it´s not surprising because n64 has texture formats with 4bit and 8bit alpha values which can produce smooth transitions. Supermodel implementation shouldn‘t be as good for n64.

[theboy181]

@gizmo98 I am unsure if I compiled correctly, Puyo Puyon Party looked really bad to me, can you share screenshots?

[theboy181]

conkers shadow looks rather pixelated now.

[gizmo98]

@theboy181 All does filters are not perfect. I have another one under https://github.com/gonetz/GLideN64/compare/master...gizmo98:filtertest?expand=1. Puyo Puyon Party looks better in highres but perfect dark looks a little bit blocky. Sprite borders look also blocky (is this good or bad?). Don't know if we should add an option so some games can be played better in highres.

[gizmo98]

@theboy181 here is another one and it looks really interesting (https://github.com/gonetz/GLideN64/compare/master...gizmo98:filtertest2?expand=1).

[theboy181]

Interesting, or amazing? These look too good to be true. What is the downfall this time?

[theboy181]

Zooming in on a few there are still some undesired artifacts, but generally text looks loads better!!

[gonetz]

@gizmo98 Stefan, please explain the idea behind these fixes. Results look cool, but calculations look too complex for such simple thing as bilinear filtering.

[theboy181]

Didnt look the same for me ? Why do you think I would get different results?

[theboy181]

oh oh.. this is why

[theboy181]

The largest problem is the 2d textures get molested (filtered possibly) as small pieces then assembled. This makes them look like they were stitched together.

This needs to be sorted :)

[theboy181]

AL on the RIGHT

[theboy181]

AL+ linear filtering on the far left.

[gonetz]

It seems that this issues must be renamed to "Fix bilinear filtering". This discussion is not related to S2DEX issues. Anyway, it is important, lets continue.

Jason, the issue with that filtering of that icon is not a bug in Stefan's code. It is my bug. These textures with hieroglyphs are rendered in COPY mode, which does not use texture filtering. That is, these textures must not be filtered at all, as with AL. I fixed wrong use of texture filtering in a44d5a8960 You may also disable mip-mapping to get the same result.

[theboy181]

point taken.. moving along.

[gonetz]

Ok, I tried to make my own fix and now I see what Stefan's code does. First, I tried the simplest approach suggested in the article mentioned in https://github.com/gonetz/GLideN64/issues/1898#issuecomment-427563738. The idea is simple. Most, if not all N64 textures intended for bilinear filtering have 1 bit of alpha, that is fully transparent or fully opaque. The problem with color outlines appears when texels with zero alpha have some color. Such texels supposed to be invisible and they are invisible in native resolution. In high resolution these texels are fetched by bilinear filtering and they give that color outline. As the article suggest, we can Use Premultiplied Alpha, that is multiply color of fetched texel by its alpha. It will eliminate color for transparent texels. This approach works, color outlines seems to be removed. Then I realized that this method just replaces color outlines by black ones - transparent texels still participate in bilinear filtering equations, but now as black texels. So, we need to get rid of transparent texels. My idea: if any of texels fetched by bilinear filtering shader has zero alpha - do not use filtering at all. That way we will have sharp edges of filtered textures, which should be much better than outlines. This works better indeed: no color or black outlines:

However, this method causes "hot pixel" problem:

Some opaque texels near transparent ones left unfiltered, which makes too sharp difference between them and their filtered neighbors.

We can't use transparent texels and can't use unfiltered texel instead. Thus, we need to replace transparent texels in our equations by somewhat correct. Stefan just replaces transparent texel by neighbor opaque one. It is questionable solution, but the result is surprisingly good:

Comparison with AL (on the right):

It does not work well for 3point filter though.

So, in my opinion, the method is working. It need to be fixed for 3point filtering, if possible. All 'if ' statements need to be replaced by 'step' for performance.

[gizmo98]

Yeah i use neighbor opaque ones color like supermodel is doing it. This is the so called "color bleeding" implementation of supermodel. Supermodel is doing if (neighbor.a > current.a) current.rgb = neighbor.rgb. I use if (neighbor.a > 0.0f && current.a == 0.0f) current.rgb = neighbor.rgb because i do not want to change color of translucent texels. There were still some black dots in Puyo Puyon Party. I use name.a = smoothstep(0.35,1.0,name.a) "after" bilinear filtering to clamp and smooth alpha transition a little bit. This removes black remnants at higher resolutions in Mario Kart and Puyo Puyon Party.

[gonetz]

Btw, smoothstep is OpenGL 4.0 We probably will need to replace it with its exact formula to keep compatibility with older GL versions.

[theboy181]

this is going to be a decent victory for GLideN64 if you guys can figure this out.

[theboy181]

Were the portraits in the picture above ever sorted in one of your builds @gizmo98

[gizmo98]

@theboy181 No. These texture are point sampled since https://github.com/gonetz/GLideN64/commit/9f936be57e5c411cebe4291fa72bdbb93ad5e48b so a modified bilinear filter will not do anything here. Olivieryuyu mentioned it could be ucode related because LLE and HLE look the same https://github.com/gonetz/GLideN64/pull/1894#issuecomment-418177122.

[gizmo98]

@gonetz I replaced name.a = smoothstep(0.35,1.0,name.a) with this piece of code:

name.a = max(0.0, name.a - 0.35) / 0.65;
name.a = clamp(0.0, 1.0, name.a*name.a*name.a*(name.a*(name.a*6.0-15.0)+10.0)); 

It works the same. See also http://www.iquilezles.org/www/articles/texture/texture.htm.

[gonetz]

Ok. Actual formula for smoothstep is simpler: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/smoothstep.xhtml

[gizmo98]

Ok. Smoothstep from gl4 looks the same:

name.a = clamp((name.a - 0.35) / 0.65, 0.0, 1.0 );
name.a = name.a * name.a * ( 3.0 - 2.0 * name.a );          

Iquilezles version is "smootherstep" -> http://sol.gfxile.net/interpolation/

It makes everything a little bit more smooth ;-)

[gizmo98]

Sergey do you think this is ready to be used? I could tidy everything and open a PR. Two extra notes about my current code.

• I use Quilez bilinear filter implementation because i found it better readable without TEX_OFFSET macro and step functions http://www.iquilezles.org/www/articles/hwinterpolation/hwinterpolation.htm. Filtering result is the same.
• I disable color bleeding and alpha clamping/smoothing if fbFixedAlpha is 1 because name.a will always be set to 0.825 if fbFixedAlpha is 1.

[gonetz]

Stefan, it is almost ready:

• is it possible to make it work that good for 3point filtering?
• if statements need to be rewritten (with step?)

[CallistoNTG]

Unfortunately, this does cause some pretty notable issues even in games where it provides a benefit. For example, while it fixes the pink outline on some 2D elements in Body Harvest, it causes the map to look really wrong. Master: Branch filtertest3:

[gonetz]

Serious argument, thanks!

[gizmo98]

@CallistoNTG Good point. I will check body harvest. Please use filtertest2 because the other branch was just a test.

[gizmo98]

@gonetz I think i know why this is happening. Color bleeding should only be enabled if uAlphaCompareMode = 1. If i discard alpha == 0 texels 3/4 of the body harvest map disappears. http://fgfc.ddns.net/PerfectGold/SetOtherMode_L.htm