FYI: Retroachievements will improve more

sirhenrythe5th

As soon as RetroArch will be ready to get updated to the current v1.20 within the retropie_setup we will be granted with cool new features:

Rank & Points are showing up with the widgets
Your Rank within the leaderboards will be directly shown (great!!!!!)

mitu

1.20 had some regressions which were fixed after the release. I was hoping they'd release a 1.20.1 to repair it, but that didn't happen. There's no other reason why 1.20 is not in RetroPie at the moment, I'm just waiting for a new release (with less regressions) to package it for RetroPie.

sirhenrythe5th

I just saw that 1.21 has been released, could this version be verified for Retropie by any chance?
(dont get me wrong, i am not impatient!!! i just recognized some issues with newer releases for retroachievements as i am missing the update to "rcheevos11.6".)

mitu

@sirhenrythe5th said in FYI: Retroachievements will improve more:

I just saw that 1.21 has been released, could this version be verified for Retropie by any chance?

There's a proposited update for the new version, but it's not yet included.

roslof

@mitu said in FYI: Retroachievements will improve more:

There's a proposited update for the new version, but it's not yet included.

@mitu is there a WIP location for the RetroPie-patched/blessed version of v1.21.0 source? No supporting branch yet from your proposed PR. There are several shader tests I'd like to perform. I can otherwise build from 1.21.0 upstream source, but then missing out on RetroPie-specific tweaks.

mitu

@roslof said in FYI: Retroachievements will improve more:

@mitu is there a WIP location for the RetroPie-patched/blessed version of v1.21.0 source?

Yes, you can use my repository where the specific (patched) RetroPie branch is hosted - https://github.com/cmitu/RetroArch/tree/retropie-v1.21.0. You can replace the repository path in retroarch.sh and point to my repository instead of retropie's, then bump the version in the same line.

roslof

@mitu said in FYI: Retroachievements will improve more:

@roslof said in FYI: Retroachievements will improve more:

@mitu is there a WIP location for the RetroPie-patched/blessed version of v1.21.0 source?

Yes, you can use my repository where the specific (patched) RetroPie branch is hosted - https://github.com/cmitu/RetroArch/tree/retropie-v1.21.0. You can replace the repository path in retroarch.sh and point to my repository instead of retropie's, then bump the version in the same line.

Worked perfectly, thank you. I would like to avoid an off topic post, but I found that some new RetroArch functionality (Viewport Anchor Bias X/Y) caused immediate issues with custom scaling. If desired, I can perform a moderate sweep of 1.21.0 and report any issues in a separate topic, or offline somewhere.

mitu

@roslof said in FYI: Retroachievements will improve more:

I would like to avoid an off topic post, but I found that some new RetroArch functionality (Viewport Anchor Bias X/Y) caused immediate issues with custom scaling

You can report the issues to RetroArch directly, but make sure you start with a 'stock' config and not with any RetroPie configuration. This feature has a regression with the RGUI display - see my comment in the PR - and I wish I've caught that sooner.

roslof

@mitu I reported an issue regarding incorrect screen positioning with gl and glcore when the aspect ratio is set to custom. A common use case would be somebody using overlays with a custom bezel that's using those video drivers. Vulkan and SDL2 work fine...

The screen is shifted vertically in every scenario with any core. The issue occurs with RetroArch 1.20.0 up to current and it's definitely related to the inclusion of Aspect Bias X/Y functionality. The default values (each at 0.5) try to put the game in the center of the screen. Overriding each to 0,0 allows custom settings to map to pre 1.20.0 values. Bias Y is jacked...

Although I already reported the issue, In wondering if you too could replicate this. I created a simple video that demonstrates the problem.

Since this only occurs with gl and glcore, wondering if there's a way to update these video drivers in case there are fixes that prevent this issue -- or if the issue is wholly with RetroArch's binary.

For games that break, a workaround is to set Bias Y to 1 which isn't ideal, hacking around a bug.

mitu

Since this only occurs with gl and glcore, wondering if there's a way to update these video drivers in case there are fixes that prevent this issue -- or if the issue is wholly with RetroArch's binary.

Hm, not sure what does that mean - are you referring to the OS/Mesa video drivers ? I don't think that's easily done without messing with backports or manually compiling MESA and - in any case - I don't think this would solve the problem. IMHO this is a bug and the changes causing this should have been reverted.

roslof

@mitu said in FYI: Retroachievements will improve more:

Hm, not sure what does that mean - are you referring to the OS/Mesa video drivers ?

Essentially, yes. I've been surprised that this issue hasn't surfaced in 2 RA releases, leaving me to speculate that others aren't reproducing this outside of the RetroPie project.

But I get it. This definitely feels like an RA bug.

mitu

@roslof I tried to reproduce the issue and I'm more confused of how it's supposed to look. System used is Windows x64 and FBNeo/RetroArch 1.21, with gl here.

I've set a custom AR for a vertical game and viewport size to 400x1080. Even with Viewport Anchor BIAS Y set to 0.0, the game viewable area is pushed down and cut at the bottom. I expected 0.0 to make the game viewable area to be hugging the top size. I'm expecting the X/Y positions for the Custom AR to be anchored top left, so 0 vertical bias should fuse the image to the screen top.

roslof

@mitu said in FYI: Retroachievements will improve more:

I expected 0.0 to make the game viewable area to be hugging the top size. I'm expecting the X/Y positions for the Custom AR to be anchored top left, so 0 vertical bias should fuse the image to the screen top.

That's exactly the issue I reported. Switch to Vulkan and it will appear as you'd expect. The Y position is only wrong when using gl or glcore.

Play with Bias Y and watch the viewable area in the background. You should see that one single frame where it appears where you'd expect before it pops into the incorrect position.

ADDING: I searched online for others having the problem. They are. Most are using GL and are advising others to set Bias Y to 1. This "looks" correct, but is a terrible workaround for a fairly obvious bug, especially for those who mix render modes.