Stella 2014 no longer rendering since 6/21 build

[theflyingape]

Current git pull / build works fine for every core I've tested but only shows a blank screen for any Stella / Stella 2014 core running content. It also does not accept any core inputs as if somehow it lost 'focus', but all of the RA hotkeys work.

When exiting the running content, there is a brief 1-frame flash of the game's screen, then exits perfectly fine. Does not matter if it's Vulkan or OpenGL core, with or without Overlays or Shaders, on KMS or Wayland context.

I revert back to the 6/21 retroarch binary and all runs fine on Raspberry Pi 4 and 5 running latest Bookworm.

[hizzlekizzle]

Hmm, we've had quite a few commits in the past couple days that touch keyboard input: https://github.com/libretro/RetroArch/commits/master/

Any chance you can bisect to find which one is the culprit?

EDIT: oh, wait, this a rendering issue rather than a keyboard one. Nevertheless, if you can find an exact commit, we'll be better off, for sure.

[gouchi]

@theflyingape Also may you provide some log when the problem occurs, it will help for the diag.

Thank you.

[theflyingape]

I can confirm RetroArch source works thru 05faba7
but shows this blank screen behavior with the next commit 2805694

This mirrors the use of video_viewport_get_scaled_integer for
non-integer scaling at various aspect ratios. Two variants are
provided, one with implicit device and desired ratios and one with
explicit ratios.

Also added a flag to video_viewport_get_scaled_integer to indicate the
direction of positive y.

[hizzlekizzle]

I'm not able to reproduce this on the latest nightly (linux x86_64). Is it still happening for you? If so, are you using a different environment.

[theflyingape]

Correct: Raspberry Pi 4 and 5 running latest Bookworm 12.6 off both KMS and Wayland modes.

[JoeOsborn]

This is perplexing since it’s only one core, and that code doesn’t have any core-specific stuff happening. Does it display ok if you set the aspect ratio to custom, or if you use a specific aspect ratio like 4:3? I wonder if something is funky with the core provided ratio?

[theflyingape]

Agreed. I did working/broken runs below using default retroarch settings and I can tell you that not only does the current retroarch show a blank screen, but it also does not accept / pass ANY core remap inputs from keyboard nor gamepad -- but the ESC+ESC hotkey sequence is available to quit retroarch. It's as if the running core does not have "focus" as I know the content is indeed running just its canvas is not up front to be displayed.

NOTE: this occurs the same with both stella and stella2014 cores on Pi 4/400/5. I cannot get stella2023 to build a core, only the standalone gui. A drive link to working runtime binaries can be found here:
https://drive.google.com/drive/folders/16CximL9KxdzFGZAFYo4HX5qvil6rE-qc?usp=drive_link
LMK if you want the current retroarch runtime binary built.

$ retroarch -c default.cfg -v
... their diff logs follow:

< [INFO] RetroArch 1.19.1 (Git 05faba73e3)
---
> [INFO] RetroArch 1.19.1 (Git 5ee1e16595)
5,6c5,6
< [INFO] Git: 05faba73e3
< [INFO] Built: Jul  1 2024
---
> [INFO] Git: 5ee1e16595
> [INFO] Built: Jul  2 2024
64c64
< [INFO] [EGL]: Current context: 0x55a8337cd0.
---
> [INFO] [EGL]: Current context: 0x55837b08f0.
115c115
< [INFO] RetroArch 1.19.1 (Git 05faba73e3)
---
> [INFO] RetroArch 1.19.1 (Git 5ee1e16595)
119,120c119,120
< [INFO] Git: 05faba73e3
< [INFO] Built: Jul  1 2024
---
> [INFO] Git: 5ee1e16595
> [INFO] Built: Jul  2 2024
197c197
< [INFO] [EGL]: Current context: 0x55a8f6eaa0.
---
> [INFO] [EGL]: Current context: 0x558524f4d0.
247c247
< [INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 23 seconds.
---
> [INFO] [Core]: Content ran for a total of: 00 hours, 00 minutes, 30 seconds.

[theflyingape]

Aargh, same occurs on other cores such as Nintendo MESEN and Commodore VICE, but not Mupen64Plus-Next, etc.

So, I tinkered and found if I flip auto_overrides_enable = "false" whereas it does not use any game content configs but only the global configs, all cores "work" -- of course, that kills a lot of customization and flexibility for me. 👎

RetroArch configuration does not seem to be very consistent in its consumption of startup config values, in that, some attributes bork the runtime if a value is "defined" upfront but later changed in an --appendconfig list. I find I have to (mostly) comment out those offending values in the main retroarch.cfg in order for them to remain undefined until I set them in an append config file. This behavior only gets worse when "new" attributes are added over time -- perhaps configuration startup needs re-engineering?

[JoeOsborn]

This is really interesting! I did add two config variables (four on mobile), so config parsing or management could be implicated somehow, but you said the commit that did that was fine… maybe they’re getting junk values somehow? Can you elaborate on the repro? It only happens for cores with config overrides? Do the bias variables have values in the base config or the override or both or neither? Is there any way to attach a debugger to see what those variables’ values are in the viewport computation code?

[theflyingape]

Ah, so after some more trial & error with my chain of configurations, seems that "something" is affecting overlays -- whereas ANY PNG overlay used (ArcadeBezels, GameBezels, Mr RetroLust, custom) is simply taking over the foreground while the game is running & rendering behind it -- no "view" through its PNG transparent area as it shows only to be a solid black background,

I don't think its related to any new configuration consumption.

I was able to reproduce (just now, again) this issue (working/broken) off the commit IDs noted in: #16738 (comment)