RetroArch is running well for me, but only in a window, and only at the default video settings. I get about 55 fps on my A04. The CPU settings (2 vs 4 cores enabled) don’t seem to matter much.
What I want to do is run RetroArch fullscreen. Unfortunately, this drops the fps down to 35 (on the menu page), and game rendering seems much worse, seems lower than 35, with halting, stuttering, choppy audio, basically unplayable. Even maximizing the window drops the framerate, with no change in the game screen size.
Seems like something is wrong. I’d expect scaling to fullscreen to happen in hardware, with zero effect on performance.
I’m still finishing up building it, but I did notice there are a lot of options in libretro-config.sh in the libretro-super directory. I didn’t touch that file, but some of the defines at the top might be useful for optimization and for rendering. By default, it doesn’t have any active ARM optimizations (not sure any of these would apply anyway?), and it has ENABLE_GLES turned off which might be affecting your fullscreen performance…
I actually did something cheeky. I installed snap, and installed Retroarch via that, just to see if it would.
Needless to say, it did! And runs full screen absolutely fine.
I wouldn’t normally use this, being a cookie cut installation, but just wanted something basic to start with to get an idea of the capabilities.
A proper manual parameter list is obviously ideal, but if you just want to get Retroarch up and running, first follow this:
I’m curious about the printer issue too, as I’ve been avoiding installing snapd given all the issues reported…You may now be in a situation to test it! Does your printer work? If not, and you remove snapd does it work then? Or if printer no longer works, do you need to reflash your image and start over?
Hoping that you don’t have any printer issues, but based on other reports it seems quite likely, and an opportunity to investigate solutions to that issue. Might also be good to know if the snapd printer issue is just an A04 thing, just an A06 thing, or applies to both.
I think you are on to something! While I’ve been working with DevTerm A04, I have also been experimenting with another device that has very similar hardware, maybe a bit weaker (Odroid Go Advance, Cortex-A35 instead of A53, 1 GB instead of 2 GB memory, Mali GPU). It runs its supported emulators very smoothly.
Their stock image runs Libretro with “GPU accelerated OpenGL-ES on DRM-FB,” which sounds like exactly what the default build of libretro-super does not have, based on what you found in libretro-config.sh.
You are absolutely correct! Ha! It was very late, and my brain was going around in circles. I’ll edit that now! Thanks.
Although if snap is indeed responsible for breaking the printer, hold off for now. Strangely, my printer is fine, so I’m not sure what is going on there.
I’m going to check the forums more!
@adcockm im on A06 and it seems to be fine, just running the standard test print. Curiouser and curiouser.
Well, that’s both fortunate and unfortunate. So much for that theory, I guess! I saw your other post. Even if that’s not it hopefully it helps others get closer to whatever snap based application might be causing the issue. I’m also not sure how people are choosing to print – I’ve seen mention of some issues around using cups to print, even when command line printing continues to work. So it may be that the printer still works some ways but not others.
I beleive the cause of this is SDL2-DEV. Its OK to have SDL2 installed, however, SDL2-DEV gave me the same issue. I have one SD card with SDL2-DEV so I can compile binaries that require the SDL2-DEV library and then I move them to a card that only has SDL2. Retroarch should run at approximately 59.4 fps.
@mferrari do you know if uninstalling SDL2-DEV via apt fixes the problem? Or once it’s installed is retroarch speed affected even if SDL2-DEV is removed?
I recently installed it to build some other emulators and I’m not sure if I’m witnessing a slowdown or not. Kinda feels like I might be, but I didn’t do very thorough testing or take notes prior to installing so I’m not sure.
For the snaod printer issue, I found a post we must have all missed from a month ago that suggests a fix. I haven’t tried it because so far I’ve avoided installing snapd. Hopefully if this fix works, it’s something the ClockworkPi folks can update for everyone eventually, but until then it sounds like the manual fix may work.
I started a fresh SD card without SDL2-DEV so not sure if removing it would have the same effect. You might get stuck with some dependencies that are causing the problem. I would start a fresh SD with just SDL2 and not SDL2-DEV. It worked for me!
Somewhat related to window/full screen issues, I’ve been playing with a current MAME build I made and noticed that turning integer scaling off when stretching to full screen for a more demanding game like Darius (which uses three screens side by side) gives a performance improvement. I’m not very familiar with retroarch settings but it might be worth trying that if it’s available.
Since these builds take so long to complete, I’ve posted some compiled binaries here, if anyone else wants to experiment with these. I’ve got a working (current) MAME for libretro/retroarch as well as the standalone MAME binary. (The Retroarch version seems slightly faster to me, but only by ~5-10fps on games like Darius and Space Lords.)
At some point I will post threads for each of them, but I want to do more testing first. Both MAME builds are quite functional and work great depending on how demanding the game might be. Dolphin is more of a novelty and while it works I’ve not found anything running at playable speed. Flycast works great and seems like it has the potential for many playable games (though 3D stuff has noticeable slowdowns, which leads me to believe my build doesn’t use proper hardware acceleration.) PPSSPP runs at a good speed but there are graphical rendering glitches that make some games unplayable or cause issues. I’m not sure if that’s a problem with PPSSPP Linux builds or if it’s something specific to the DevTerm and perhaps I should have used different build options. Stella works great, and I’m not sure if the standalone version is any different performance-wise to the libretto core, though the standalone likely has more tweakable options. The VICE libretro core is standalone and not from “super” (which either wasn’t included or didn’t build), but this one works fine.
I haven’t tested many of the cores from the libretro super build yet. I’m thinking for any that work (well) I’ll post them to my repo here. I did try the Jaguar core from super and it was terribly slow running Tempest 2000 (which is one of the few games I might want to run on it anyway!) My long term plan is to try building from the standalone core repos in cases where the super version performs poorly, just to see if there’s an improvement. Also, there’s a ton of stuff included in the super repo that never actually gets built either because it tries and fails, or it isn’t even included in the build process. I’d like to either build those cores separately from that repo, or from a standalone repo (if one exists). But that seems like more of a bonus goal, since I’m guessing most of those cores cover systems that will already be working well enough in a different core, or they are more esoteric systems that few people (including myself) will care about. That said, I’m always curious to see unusual things being emulated. For instance, there’s a Palm emulator called Mu in the super core that built, but I haven’t tried yet. Not exactly practical without a touchscreen, but still might be cool to see running in the DevTerm.
I have never had an issue with the RetroArch menu. Only with the performance of specific cores under specific conditions. For example, with snes9x in full screen, with specific ROMs, I get a low framerate and audio stuttering. But the RetroArch menu works fine.
I tried the rewritten keyboard firmware, which I loved in general, but I ended up uninstalling it, because it didn’t support having two arrow keys pressed simultaneously (for diagonal input). [Forum: I've rewritten DevTerm keyboard & trackball firmware]
While I’ve got an A06 instead of an A04, like @poulsbo I installed retroarch via apt, and I’ve never had menu flickering issues. (I never tried the one via snap.)
I’m still using the new keyboard firmware for now, but I hate the keyboard multi-keypress issue. I took a look at that code and it seemed like the timer/delay stuff they were using to smooth out trackball movement essentially broke any recognition of multiple keys pressed. So it didn’t seem like a bug, but instead a “feature” of the solution for the trackball. Maybe someone else can come up with a way to fix the trackball behavior without messing up multiple keypresses, but it didn’t seem like an easy fix and I’m pretty sure was beyond my abilities.
That’s weird. I’ve tested both joystick arrow buttons(top left) and arrow keys (bottom right) works as I intended. I can press multiple arrow keys simultaneously.
I’ve tested them with
Also the keyboard part and the trackball part don’t share their states implicitly, so I guess the trackball cannot mess up the keyboard. They communicate each other only through class State, and it is only used for ‘fn’ and middle button things.
