@mitu thanks for the reply. I turned off my shader preset to see what would happen, and it does improve performance to "mostly" 60fps. The global shader I use is just "sharp-bilinear-2x-prescale" which afaik isn't supposed to be demanding at all, so I'm surprised performance tanks so badly with it on.

Unfortunately I've screwed up the video settings for all the snes cores by attempting to remove the global shader preset from bsnes, while keeping it in place for snes9x. Shaders don't work at all for snes anymore, and different resolutions in the runcommand menu aren't even working... I don't know why that happened.

Bsnes is causing me too much trouble, so i'm just gonna uninstall it once I restore my backup...

@dankcushions It worked! Thanks. I’m officially on 1080p.

Afaik there isn't gles support. If GL is slower it will be because it's using non accelerated rendering. Which is likely the case. It shouldn't be enabled by default on the RPI also.

@MarcuFinx76 Nevermind, I ended up finding the option for it in the retroarch on screen display settings. Again, sorry for the double posting

Thanks for providing the log file. I don't notice anything different between the 2 runs, so it's not something related to a configuration.
Try removing pulseaudio completely then reboot the system, this might get rid of any PA interference.

@sad_muso you didn't say what emulator you're using. afaik even simple shaders are often very system bus intensive, so they're constantly fighting for bandwidth with the GPU, CPU, etc. afair, lr-genesis-plus-gx really hammers the system bus, so try using lr-picodrive instead, if you're using the former.

Are they CPU/RAM intensive or both? Does the Pi 4 cope with shaders better than the 3 B?

first part answered above. pi 4 will cope better.

Do overlays cause any hit on performance, specifically when used in conjunction with shaders?

yes, for whatever reason they seem to.

What is the least expensive way to implement curve and scanlines that is currently in existence?

the way you're doing it already - z_pi_crt.

Classic remark in case it's the issue: can you try disabling vibration in the Retroarch core options menu and seeing if it improves it?

@Brunnis he actually just added the option: https://github.com/libretro/mupen64plus-libretro-nx/issues/72 (not sure which branch, but i'm sure you'll figure it out)

@bbloke I removed the link to the image - per the forum rules, there's no links to ROMs or copyrighted material.

@mitu This was helpful! But I also had to force 1080p by setting hdmi_group and hdmi_mode:

hdmi_group=2
hdmi_mode=82

For more video mode options see:
https://elinux.org/RPiconfig#Video_mode_options

Update:

Updated the RetroPie-Setup script and all OS packages and restarted the Pi. This got the Bluetooth to connect (unreliably, it still fails to register about 1/4 of the button pushes I make). Frame rates are still very poor but I think that might just be the state of RetroPie on Pi 4 at the moment.

@TANKARD @mitu

Custom configs for CRT using the built-in composite out

You can also tweak the runahead settings for 8bit/16bit consoles to further improve the input lag and use wired controllers.

No ideas from anyone? Disappointing... But I guess we can't expect to figure out a fix for everything. (especially if my friend is right)

EDIT: YEAH, my friend was right. Screen was dying. No longer functioning at all. Sorry to have wasted the time of anyone who read this - fix a dying screen with configuration changes is....kind of impossible.

got it fix
DYNAMIC RECOMPILE was off

@Kentinator there are several threads concerning N64 Emulation with the Pi, but to say it with a few words: your experience nails it.
Mario64, MarioKart64 and a few others work well, a lot of other games do not.

@tackskull

Move out to the root menu, then to 'Input'. From there, you should see the player one input map menu selection.

@jonnykesh I went into the settings, but vsync was already on. The issue persists