bright horizontal Line in Gran Turismo

[zschigi2]

in Gran Turismo there is always a bright line between the sky and the horizont. (buffered rendering or non buffered rendering makes no difference) the bug is the same on pc and android version.

I don´t know if this effect is the same in other games.

It would be nice, if one of the developers can have a look on it.

Thanks in advance!

[dbz400]

How about in softgpu ?

[zschigi2]

It´s the same problem, even with softgpu.

[dbz400]

Humm or may be real PSP also looks like this ?

[hrydgard]

I don't think so, to me it looks like some bizarre alpha testing/filtering glitch but really not sure what's going on here. PSP has some rarely used functionality to only alpha test some bits of a pixel value, maybe that is being used (we can't emulate that except in the softgpu ... but I think we do emulate it there so it's probably not that)

[zschigi2]

i played it on a real psp and it definitely don´t looks like this! ;-)

[DonelBueno]

This glitch goes away if you force Texture Filtering to Nearest, so it's probably a bug with Linear Filtering.

Default Texture Filtering Setting:

Force Nearest Filtering:

[dbz400]

I think softgpu has bilinear filtering and why causes the white line as well

[zschigi2]

I noticed that too, but if i turn on force nearest filtering, i always get a very blocky sky. So am i doing something wrong?

[unknownbrackets]

Well, that's expected really. Things will get blocky if you force off texture smoothing.

-[Unknown]

[zschigi2]

That was my idea too. But it seems not to be like this on the second picture from DonelBueno. That´s why my question.

[hrydgard]

Well the picture is compressed and downscaled. The drawback would be very obvious if you tried it yourself, especially at highres.

[DonelBueno]

@zschigi2 Turn on Texture Scaling, it will help A LOT in this problem. With Texture Scaling on, you can leave Texture Filtering in auto, since it will minimize the white line a lot.

[thedax]

Forcing nearest + using scaling helps to eliminate weird line issues like this while keeping a relatively clean picture as well, though your results may vary depending on each game.

[dbz400]

Humm just tried latest build and interestingly cannot see the white line anymore even filtering is auto only .Anyone can double confirm ?

[daniel229]

another issue come,that sky is just too bright,and the line is still there,you can see it from my picture,this commit causes the bright issue. https://github.com/hrydgard/ppsspp/commits/master

[dbz400]

Ooops i;m even not awared the sky is changed .......

[dbz400]

#5760 should fix it now.

[zschigi2]

it's really brighter than it should be. but in my opinion its not so bad. looks much better than the bright lines before (which are still there but less visible)

[dbz400]

I think probably this one can be closed and we can simply 'fix' it by selecting nearest filtering

[zschigi2]

I dont think so. Because with nearest filtering the sky gets very blocky an by scaling down it you will loose to much speed. So it´s no real option for android users .

[dbz400]

Nearest filtering is the way suppose to be blocky . Probably we have to live with it .

[unknownbrackets]

Has this improved with texture filtering set to auto on desktop? If it's using alpha test masks, it won't work on gles2 yet. Otherwise maybe it could've been fixed by other recent changes.

-[Unknown]

[zschigi2]

unfortunately there are no changes with this problem. just tested it.

[thedax]

@unknownbrackets: You asked me in IRC, but yeah, this still happens at least on my PC.

[ppmeis]

Tested in latest build. correct sky colorbut bright line still there (using xBRZ scaling in both cases):

With Nearest is less agressive but still some white points:

Without scaling filter there's no white bar using Nearest but yes with Linear:

[unknownbrackets]

Could you try exporting a GE debugger dump on PC? I'm wondering if this is antialias, it probably is.

To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.

After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.

-[Unknown]

[ppmeis]

@unknownbrackets tested with latest build. Same issues. Debugger dump:

UCES01245_0001.zip

[unknownbrackets]

For posterity: texture 0x0881ee20 in this dump right now.

Some interesting things about this draw:

1. The mountain texture actually has an outline, but it has alpha = 0. This is true for all 4 mip levels.
2. The texture is somewhat minified in this screenshot (and it has mipmap linear/linear enabled.)
3. Alpha testing > 0 is enabled, and blend is fixed 1.0 + 1.0 - src.a. All parts of the mountain are either 255 or 0 alpha, so this actually forces the interpolated alpha to be treated as 1.0.
4. Bit 0x100 of tex format is used, but this is otherwise DXT1.
5. Texture alpha is enabled, plus a mystery bit (0x8000).

So first, it could be one of these mystery bits somehow impacts alpha interpolation. Maybe 0x8000 means don't interpolate alpha, or something.

Another interesting thing is DXT1 decode. Normal DXT1 has the final color as transparent black if c1 > c2. We use color2, but transparent. Because of the blending parameters, if it was transparent black it would have a thinner outline (though, it'd still be there.)

It's possibly also interesting, but likely irrelevant, that the framebuffer is 5551.

Finally, if it used a standard blending parameter (src.a + 1.0 - src.a), it'd have no outline AND we could skip the alpha test. A shame. It's almost like it's intentional...

-[Unknown]