Videomode file ignored if game override cfg file exists?

stevas

Pi Model: 4
Power Supply used: official Pi4
RetroPie Version Used: 4.6.1
Built From: retropie-buster-4.6-rpi4.img (TWICE)
USB Devices connected: 64gb thumb drive
Controller used: M30 8bitdo
Error messages received: none
Emulator: lr-flycast, lr-genesis-plus

How to replicate the problem:
RETROPIE itself is set to a 1080p/60hz resolution.
(Note: I have tried setting the boot to ignore edid also.)
WITHOUT a game override cfg file present (no file for chosen game at /opt/retropie/configs/all/retroarch/config/emulator/), resolution will correctly change to whatever is chosen (say, a 720p/60hz one - in order to decrease resolution and maybe increase performance).
WITH file present (eg. ..as above../Flycast/Capcom vs. SNK.cfg), resolution will not switch: it will STAY at 1080/60.
Note that in both cases the video mode choice will correctly be saved in videomodes.cfg.

Hi. I'm going mental with this, tbh. And it doesn't feel like I'm trying to do anything special here?

Simply put: I want to be able to switch specific emulators down to 720p (Dreamcast, say). But if I try to do that with a game config file present (one that simply loads a save state, for example), whatever is in the videomode.cfg file is straight up just being ignored?

I've even tried rebuilding, and I get this happening immediately after that. (That is, I've rebuilt, and all I did after that was copy across a megadrive ROM and created a game cfg override which simply autosaves/autoloads a state).

I know I'm missing something here, but WHAT am I missing?
Is there another setting/file which controls this behaviour?

Thanks in advance.

mitu

Can you post your game override on pastebin.com ? If it saves the video resolution there, it might override (sic!) your video mode selection.

stevas

Hey mitu. Thanks for the swift response.

It literally does not matter, which is why I suspect there's a setting I'm missing, or something similar.

Right now I have a .cfg with literally just:
video_vsync = false
In it for a megadrive game, and it will not switch to a 720p resolution even though it's in videomodes.cfg

Something that I just discovered, shouldn't the output of tvservice -m CEA match what I see in run command video modes?

mitu

video_vsync = false

OK, I might have to try that to see. Just to check, can you enable verbose logging when launching the game and then post the resulting log file (/dev/shm/runcommand.log) on pastebin.com ?

Something that I just discovered, shouldn't the output of tvservice -m CEA match what I see in run command video modes?

Not necessarily, the Pi4 doesn't rely on tvservice to change the video mode resolution. In the video mode selection you might see also the DMT modes, as reported by the TV's EDID.

stevas

There's not a lot in that log, I did check that already and nothing jumped out? Other than it executing something with CRTCID (=49) and KMSDRM (=12) in the names.

Is pastebin the only way to do that? Don't have an account, see.

What you might find useful is:
In both cases, i.e. when the cfg file is present (and video switching does not happen) AND when the cfg file is NOT present (video switching DOES occur), my output in the /dev/shm folder IS IDENTICAL.

Also of interest, the --appendconfig retroarch.cfg file there has 720 info inside, ie:
video_refresh_rate = 60
video_fullscreen = true
x = 1280
y = 720

And while I'm here, what's the point of launching with verbose? All it seems to do is add a redundant --verbose to the runcommand.log? That is, running without it adds literally nothing else. Am I missing something here too? Beginning to feel like an NUFC striker here, missing so much (sorry, a football joke).

Am I correct in saying that outside:

retroarch.cfg (and system cgfs which #include that)
core/game overrides (such as what I'm attempting)
/boot/config.txt
There's nothing else which could be forcing this 1080p behaviour somewhere?

It's starting to feel like a bug (I doubt I'm literally the only person trying this, so...) or my crappy old TV?

Thanks for sticking with me btw.

mitu

@stevas said in Videomode file ignored if game override cfg file exists?:

Is pastebin the only way to do that? Don't have an account, see.

You don't need one. Please post the verbose log, at least we have a chance to see what configurations are parsed and how RetroArch initializes the video.

stevas

That's my TIL for today then! Every day a school day...

https://pastebin.com/raw/DBch4eja

mitu

The log doesn't have debugging enabled. When launching the game, use the Runcommand launch menu and run with verbose logging enabled. This should add more information in the log file.

mitu

I tried with a MD game and cannot reproduce the issue.

created an 'Alladin (USA).cfgwith justvideo_vsync=false`.
chose 800x600 as ROM video mode during the launch, the video mode gets applied

$ grep KMS /dev/shm/runcommand.log
Executing: SDL_VIDEO_KMSDRM_CRTCID=49 SDL_VIDEO_KMSDRM_MODEID=5 /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-genesis-plus-gx/genesis_plus_gx_libretro.so --config /opt/retropie/configs/megadrive/retroarch.cfg "/home/pi/RetroPie/roms/megadrive/Aladdin (USA).md" --verbose --appendconfig /dev/shm/retroarch.cfg
[INFO] [KMS]: New FB: 800x600 (stride: 3200).
[INFO] [KMS]: New FB: 800x600 (stride: 3200).
[INFO] [KMS]: New FB: 800x600 (stride: 3200).

if I don't specify the video mode, then the game will run at default display resolution:

$ grep KMS /dev/shm/runcommand.log
[INFO] [KMS]: New FB: 1600x1200 (stride: 6400).
[INFO] [KMS]: New FB: 1600x1200 (stride: 6400).
[INFO] [KMS]: New FB: 1600x1200 (stride: 6400).

Are you sure you don't have any other configurations in place ?

stevas

Hey there. Thanks a load for confirming this at least should work as I believe.

That is partly what I was asking, what else could there be? What other configurations are there?
I've went with the default retroarch.cfg files and all I've added is a game override? I've not messed with core overrides, and all I've changed is maybe integer scaling as a general setting.
Since a full rebuild (as I assumed, as you've confirmed, that I'd clearly done something previously to break it) all I have updated is:
WiFi
Updated packages
Updated shaders/overlays
Setup Bluetooth devices
Larger font
Swapped A and B
That's it.

As for:
The log doesn't have debugging enabled. When launching the game, use the Runcommand launch menu and run with verbose logging enabled. This should add more information in the log file.

That's what I was saying earlier, I do this? I interrupt the load to get to the runcommand, launch with verbose logging...
And all that appears to happen is the text "--verbose" gets added to the log? I get none of those "stride" lines you do - that pastebin is all I get? An I missing some other setting which enables this correctly?

mitu

@stevas said in Videomode file ignored if game override cfg file exists?:

And all that appears to happen is the text "--verbose" gets added to the log? I get none of those "stride" lines you do - that pastebin is all I get? An I missing some other setting which enables this correctly?

I see, the verbose log should look more detailed - like this.

EDIT: How are you copying the file, for uploading it ?

stevas

Yeah, I figured. I have no idea why mine isn't like that.

I'm moving it across to the PC via the share //retropie, then opening it there to cut and paste. And if I open it with nano on the pi itself, I can see the exact same output.

Wait, is it possible the unrelated error is stopping verbose output? How do I get rid of that CDROM error?

mitu

@stevas said in Videomode file ignored if game override cfg file exists?:

Wait, is it possible the unrelated error is stopping verbose output? How do I get rid of that CDROM error?

I don't think so - that error message is benign and comes from RetroArch's real cdrom support. I think that if you update to the latest RetroArch version (from the RetroPie-Setup), the message is gone.

stevas

Interestingly though, if I remove the thumb drive (which works fine, and I'm using symlinks to it incidentally) I get a different error at the end of the same, truncated log file:
[CDROM] no sg devices found and sg kernel module is not loaded.

What's the easiest way for me to get this all updated to where you are? And please don't say rebuild from that image...

mitu

@stevas said in Videomode file ignored if game override cfg file exists?:

What's the easiest way for me to get this all updated to where you are? And please don't say rebuild from that image...

Just use the normal update from RetroPie-Setup. Maybe install/update RetroArch from source.

stevas

Updated all core packages from binary, all that did was remove the benign error as you said.
Same annoying behaviour. Same truncated log file.
Updating retroarch from source didn't change things at all.

dankcushions

@stevas
megadrive_hacks is a rom folder that comes with a famous third party image. are you telling us porkies?

stevas

Haha, entirely coincidental I assure you!

I've edited es_systems.cfg to include that (apologies, something else I did was copy across that file from the previous build in order to test that particular game, as I wanted to use a game I KNEW was previously causing this issue).

Edit: though that's an interesting point. I'll investigate what happens if I reset that file...
I should add, I did just try Aladdin (which is in the original megadrive folder) and got the same issue. Though that's with my edited es_systems, which may well be a/the problem here (as I can think of nothing else presently).

mitu

Did you modify the default retroarch.cfg configuration file or used the RetroArch menu in RetroPie to change the global options ?

stevas

I changed a couple, yeah. From memory, integer scaling off, and some qol stuff like swap A/B.

I literally just reimaged. Plan was to do as little as possible, get Aladdin on there.

Annnnnnd... now I'm getting even weirder stuff happening. Like, either it won't list SSID's, or it will eventually list them (and they appear to double up), and if I select mine it takes an age to connect before just... not.
Maybe I'll run a check on this SD card.