@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)

Tasosgemah created this issue in libretro/mupen64plus-libretro-nx open Add support for bsOnColorImageChange bufferswap mode #72

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

There might be a bug in RetroArch which picks the first resolutions offered by the display instead of the current resolution. If the first resolution is 4k@30fps, you'll see it as a slowdown.

You can check the resolution picked by RetroArch by running with verbose logging enabled from the Runcommand launch menu and then looking into /dev/shm/runcommand.log (which you can upload to pastebin.com if you want us to take a look at it).

You can forcibly disable the 4K resolutions by modifying config.txt on the boot partition and adding

[hdmi:0] hdmi_max_pixel_freq=200000000 [hdmi:1] hdmi_max_pixel_freq=200000000

(Ref: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=255970&p=1561266)

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