[OpenGL] Breath of Fire 3 - Sprites have black lines

[Papermanzero]

Settings

Renderer: Hardware (OpenGL) Software Framebuffer: Off Adaptive Smoothing: Off Internal GPU Resolution: 4x Texture filtering: bilinear Internal Color depth: 32bpp Wireframe Mode: Off Display Full VRAM: Off PGXP operation mode: Memory only PGXP vertex cache: On PGXP perspective correct texturing: On Widescreen mode hack: Off Frame duping: Off CPU Frequency Scaling: 100% GTE Overclock: Off GPU rasterizer overclock: 1x Skip Bios: Off Dithering pattern: 1x Display interal FPS: Off Initial scanline: 0 Last scanline: 239 Initial scanline PAL: 0 Last scanline PAL: 287 Crop Overscan: On Additional Cropping: Off Offset Cropped Image: Off DualShock Analog button toggle: Off Port 1 Multitap: Off Port 2 Multitap: Off Gun Cursoer: Cross Mouse Sensitivity: 100% CD Access Method: sync Memcard 0 method: libretro Enable memory card 1: on Shared memcards: off Increase cd loading speed: 2x

GPU: Nvidia 760 GTX

Description: All character sprites in Breath of Fire 3 (PAL) have vertical black lines.

Screenshot:

[Papermanzero]

Also with commit a8aa726, issue is still visible.

[iCatButler]

I don't think the remaining lines are caused by texture filtering, they appear when using Nearest Neighbour sampling and even using the software renderer with resolution scaling.

Software with 4x scaling:

It could be that the UV coordinates of the sprites/quads are actually set up to sample outside the correct area, but on original hardware and using the software renderer at native resolution this garbage data is never visible.

[Papermanzero]

I guess following bug is caused by the same root cause (which is currently unknown). https://github.com/libretro/beetle-psx-libretro/issues/351

[iCatButler]

I noticed this bug wasn't present in the Vulkan renderer implementation. Having investigated I found there's some additional code in there which handles incorrect texture sampling caused by differences in where the PS1 and modern GPUs take samples from.

Porting that code over to the GL renderer seems to have fixed the issue. I've created a PR for the changes.

[inactive123]

Merged it.

[inactive123]

Excited to see these changes BTW. There are some additional niceties in the Vulkan renderer which would be very useful for the GL renderer. The mask bit for instance allows for Silent Hill fogging and proper Chrono Cross battle screen transitions. It is implemented for the Vulkan renderer but not for GL.

[inactive123]

@Papermanzero Can you try these games again that suffered from these issues and let us know if things are fixed or not?

Would be interesting to learn how many issues can be closed now as a result of this.

[Papermanzero]

it is better. But not completely fixed. There are still lines at certain areas

[iCatButler]

@Papermanzero do those lines persist for you? They only appear for about a frame for me, not every time I run the scene either, and seem to be linked to a general instability in the UVs that cause the sprites to shake.

If I add a small sub-texel offset then those both resolve themselves but it would probably be better to understand why this is happening (it happens even with PGXP completely disabled). I'll try it on an AMD card when I get the chance because it could be the same Nvidia specific behaviour I was seeing with perspective correct lookups in games like Tomb Raider.

Edit: Neither error appears on the AMD hardware (well an R9 270X), so that suggests it's the same Nvidia specific variance that caused problems with perspective correct texturing.

[Papermanzero]

I updated my core via retroarch. This version does not contain the fix.

[inactive123]

Tell us the commit hash. When you have the core loaded, go back to the menu, and check the lower left part of the screen. It should show the name of the core plus a hash. The hash is the commit it is built from.

[iCatButler]

@twinaphex I just ran the core updater in Retroarch (Windows x64) and the downloaded version has the shortened hash for commit a8aa726b38d2e39a284360c1d6cf04d79fe57d98 from the 1st of July. That means the last two fixes aren't implemented in this version.

The only two commits that are missing are both merged pull requests, so perhaps that has something to do with them not triggering a new build.

[Papermanzero]

Same for me. I have the version a8aa726

[inactive123]

Sorry about this. We really are undermanned when it comes to the buildbot, and the Windows buildbot just keeps crapping out on itself from time to time for mysterious reasons unknown to us all. We keep bringing it back alive but then it happens again somewhere down the line. It is really frustrating. It is even more frustrating that when it doesn't build for a day, I don't get notified in the mail through some automated system or whatever so that at least I could be kept up to breast on system downtime.

Anyway, for now, I would recommend building from source.

[Papermanzero]

Can someone upload the newesr build? Then I could verify some games.

[saftle]

Awesome. Thank you @iCatButler ! Those two commits will most likely fix a bunch of the GL renderer bugs listed over at https://github.com/libretro/beetle-psx-libretro/issues/43 (most of the entries are hidden, until you show hidden entries somewhere towards the middle). I'll be sure to go through all of my entries over there to see if the errors still exist after the Windows build gets built.

[rz5]

@Papermanzero @saftle - Here's a fresh build for Windows, x86_64 using MSYS2.

mednafen_psx_hw_libretro.zip

Since the buildbot is having some problems and since you're on a roll with the bug reports, I highly, highly suggest you two learn how to compile your own builds. Read https://docs.libretro.com/compilation/windows/ and follow the instructions on the 'Environment configuration' section.

If you can't do it by using the docs but you're still willing to learn, ping me on the libretro Discord server and I'll walk you through all of it.

[Papermanzero]

It is not hard to setup a dev environment. But it will cost time, which I currently do not have. But thanks.

[Papermanzero]

Issue is fixed with 6094309

[inactive123]

BTW, the Windows buildbot should be back up and running again. Hopefully the lockfile issue doesn't happen again. I will keep a closer watch on this server from now on.