A number of odd rendering issues, mainly in Chrono Cross

[WhiteZeroX]

First up, I'm not sure if this is normal or not for Mednafen, but I get black horizontal lines in some game menus, such as Chrono Cross's character menu or Silent Hill's map screen, when I increase the internal resolution above 1x. Software or OpenGL renderer Screenshot

Next up, I sometimes notice a bizarre pixel strobing/flickering with higher internal resolution as well. I've only caught it in Chrono Cross and it's not very repeatable and it seems to only be with the OpenGL renderer. What happens is when a dialog box is scrolls text, 3D assets seems to strobe between low and high resolution. I can't capture it with FRAPS because the effect stops as soon as I start recording, so I had to take a video with my cell phone. Video here. Watch the characters kind of "flicker" as text scrolls.

Lastly I seems to get odd texture corruption with the OpenGL renderer in Chrono Cross when entering and exiting the game menu, regardless of internal resolution, that or my screen just goes black after exiting the menu. Video 1. I get similar issues when just starting a new game. Video 2.

This is running in Windows 10 (Build 1607), with a GTX 1070 and nVidia drivers 372.70. Latested PSX HW core downloaded in RetroArch. My Mednafen Options are all default, except for renderer being OpenGL, Internal Resolution 2x, Internal color depth 32bpp

[simias]

The black lines are a known bug, it's because of the deinterlacing output being a bit messed up in beetle, IIRC I broke that when I implemented increased internal resolution.

The problem shouldn't happen with OpenGL though, since it never outputs interlaced video. Are you sure you restarted the emulator after changing the option? I don't have the issue over here:

This strobing is weird, does it happen with all the text or only in certain dialogues? I've tried to reproduce it during the intro and in the village and I don't notice anything weird there.

Usually this type of effect is due to the game reading back the contents of the framebuffer and then re-drawing the image from that. Since all framebuffer reads are done at 1x it becomes pixelated. I know some games do that, I didn't think Chrono Cross was one of them.

I do have the texture issues here as well, I've tested Chrono Cross in the past and I didn't get those so it looks like a regression. A temporary workaround is to save and then load a savestate, it forces the emulator to reload all the textures. I'll look into it to figure out what's really happening.

Thank you for the report.

[saftle]

I get the graphic strobing in Brave Fencer Musashi, along with the other regressions listed here: https://github.com/libretro/beetle-psx-libretro/issues/95

@WhiteZeroX since you're also on a Windows build, could you see if the other errors I mentioned in the related issue are reproducible on your end?

[WhiteZeroX]

@simias ah, you're right, the black bands don't appear win OpenGL, only Software.

As for the strobing, it seems to happen randomly with any dialog boxes. I can't always reproduce it on the same dialog from the same save-state either, so there must be some other factor causing it. Often when it stops occurring, it won't happen again until I've stopped the emulator or a time and come back to it.

Makes sense it has something to do with the framebuffer and that I can't catch it with FRAPS, since I believe FRAPS reads out directly from the framebuffer so that must be interrupting the glitch somehow.

[simias]

@WhiteZeroX Fraps should be able to catch it because it happens earlier in the pipeline, I'd guess that it's a framerate issue or something like that.

If as I expect the issue comes from the game copying the framebuffer back and forth there's no easy fix unfortunately. I'll have to look into it though, I'm not sure why the game would want to do that in that particular instance.

[saftle]

@simias I can reproduce the strobing issue as well in Chrono Cross, but only after the most recent commits, along with the aforementioned Brave Fencer Musashi. I can show you via the Steam's Broadcasting feature if you would like a closer look at the issue.

[simias]

Ah, that's good to know, I didn't expect it was a regression. Can you reproduce it at the very beginning of the game (during the dialogue in the "flash forward" or in the village)? I couldn't when I tried the other day.

[WhiteZeroX]

@simias I have had the strobing occur in flash forward on a new game as well, but I haven't reproduced it since. Again, it's really inconsistent. I think @saftle and I are also running on the Windows build, not sure about you.

[simias]

No, still not running on Windows. Okay, this time I'll do it, I finish what I'm doing at the moment and I setup beetle on my Windows partition. Wish me luck.

[WhiteZeroX]

@simias Good luck! What Windows version are you running, BTW?

[simias]

Windows 10 64bits using an AMD card (R280 IIRC)

[WhiteZeroX]

@simias Same here, except with an nVidia card. I wonder what brand card @saftle is using.

[saftle]

I'm using a Nvidia Geforce GTX 970 on Windows 10 x64 Anniversary Update. I will see if I can reproduce the Chrono Cross problem from the beginning, but the easiest game to reproduce is Brave Fencer Musashi, since the same strobing appears right from the beginning. I saw it on a few other games as well.

[iCatButler]

I'm able to reproduce this pixelation effect in the Chrono Cross attract sequence when Harle starts talking and also get it when driving through tunnels in Ridge Racer Revolution.

The effect seems to be reduced when recording, so might be performance related, but is still visible in these areas. This is using an R9 290x/4790k and Windows 10 x64.

[simias]

I can't reproduce the pixelation issue in Chrono Cross or Ridge Racer Revolution, however I managed to track down the issue with texture upload and I've found where it doesn't work. Unfortunately the "why" is still eluding me, looks like a weird race condition or coherency issue, I need to dig a little deeper to figure it out.

It's not entirely impossible that this same issue could explain the pixelation you observe: if the call to the texture upload gets broken and uploads more texture data than necessary it could end up uploading the framebuffer data as well, and the source buffer is always at 1x. It's pure speculation and seems a bit far fetched but it could be that.

Unfortunately the issue has the bad habit of disappearing when I try to trace the GL calls (which kind of confirms it's probably a race condition/coherency issue) so it's a bit tricky to debug.

In case you're curious about the details: the method GlRenderer::upload_vram_window is used to upload a portion of software VRAM to the OpenGL textures.

First the software buffer is uploaded to fb_texture (always 1x) using glTexSubImage2D. This part seems to work correctly.

Then the same portion of fb_texture is drawn into fb_out (which is scaled by the internal resolution factor, hence I can't just use a dumb copy function since scaling can take place). This part works... most of the time. Sometimes it seems to fail but I'm not clear on the conditions to make it fail, much less the reason.

I'm guessing that it's a regression since I completely rewrote the buffering code not long ago (just before the PGXP code was integrated).

[sergiobenrocha2]

I was going to open an issue, this glitch in the middle of the screen is related right? Software renderer, 2x

[inactive123]

@sergiobenrocha2 This issue has been there ever since we added internal resolution upscaling. I think we would have to update the deinterlacer to handle bigger resolutoins since it seems to not properly deinterlace a few lines of the picture when resolution is higher than 1x.