lr-fbalpha now fast on PiZero & rpi1

Darksavior

Nevermind, not sure if the argument is enabled. Had to try an older build to compare and didn't notice

barbudreadmon

@Darksavior said in lr-fbalpha now fast on PiZero & rpi1:

Excellent. This helps on the pi3b/b+ as well.

I don't recommend using it on arch besides rpi0/1 for several reasons :

savestates from cyclone aren't compatible with savestates from musashi
for the reason above, it's also breaking netplay cross-platform compatibility
i can't really say for sure that this cyclone implementation is bug free
at the very least i think it breaks support for megadrive games (if you are using fbalpha for megadrive)

Darksavior

@barbudreadmon Yea I just noticed it breaks system18.

barbudreadmon

@BuZz now i build cyclone support for all arm platform, however you have to enable it through the core options (disabled by default, for the reasons explained above).

@Darksavior i guess it solves the issue with system18 since you'll be able to use core option overrides.

BuZz

@barbudreadmon Thanks. Enabled for all arm platforms. Binaries have also been updated now.

lostless

i just tried the cyclone support on a pi zero and did not notice any improvements. All i tested was some neo geo games though. Am I missing something?

Darksavior

@lostless Enable Cyclone from Rgui: Quick Menu, Options.

BuZz

Just to note, I did actually update Jessie packages too. But this may be the last time. (I have to build everything 4 times currently and I want people to update to Stretch)

lostless

@Darksavior did that, seem to make no difference.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

@Darksavior did that, seem to make no difference.

You need to restart the core (most likely close and reopen actually).

Edit : my bad, i confirm i messed up when reworking this as a core option, cyclone is always disabled, should be fixed in my next commit.
Edit 2 : Should work as expected now, also improved description of the core option...

lostless

@barbudreadmon after spending 5 hours compiling on a pi zero, Lol, there still is no difference.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

there still is no difference.

Having no difference at all doesn't make any sense, at the very least it is using ~30% less cpu with cyclone enabled. I tried downclocking my rpi3 again (this time to 600Mhz), i played Street Fighter Alpha 3 which is probably one of the most demanding m68k games :

with cyclone enabled, max cpu usage was 80% (happened once around the end of the attract mode) with a minimum around 50%.
with musashi, cpu couldn't handle it, minimum was 80%, regular spikes above 100%, causing slowdowns

Let's confirm your issue is not elsewhere :

what's the commit you are using (next to the emulator version in bottom left of rgui) ?
do you have something that could cause heavy cpu usage ? like rewind or advanced shaders ?
did you shutdown the emulator after enabling cyclone ? not just "restart" in the ui ?

Also, you don't need to spend 5 hours building this, downloading the armhf version at libretro buildbot and replacing yours should be fine : http://buildbot.libretro.com/nightly/linux/armhf/latest/fbalpha_libretro.so.zip

lostless

@barbudreadmon Im using build cb4826a. I guess some games speed up better then others. I tested neo geo and was a tad faster. Games like simpsons arcade I noticed no change. But its still not full speed on a pi zero. But was fun to test out.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

@barbudreadmon Im using build cb4826a. I guess some games speed up better then others. I tested neo geo and was a tad faster. Games like simpsons arcade I noticed no change. But its still not full speed on a pi zero. But was fun to test out.

I explained it was only affecting games using the m68k cpu, simpsons is not one of them.
Could you try using a frameskip of 1 in core options for neogeo ? To see if the bottleneck is the rendering.

barbudreadmon

@lostless said in lr-fbalpha now fast on PiZero & rpi1:

Im using build cb4826a

What the fuck with that commit actually ? It doesn't even exist in https://github.com/libretro/fbalpha/commits/master, seems to me like you are not even using the right emulator...

Darksavior

@barbudreadmon lol, that build number is from mame2003...of last year.

barbudreadmon

@Darksavior Thanks for confirming. I guess we are back to step 1 then.

@lostless congratulations on pissing me off, how is it even possible to not notice you are running the wrong emulator when it is written next to the commit, and i even explained you needed to set cyclone in core options, which you obviously didn't, seriously.... no need to do more tests, you are obviously not trustworthy.

lostless

@barbudreadmon I’m really trying to help here. Im sorry if there has been any misunderstanding here. I’m no stranger to computers and retropie. I somehow made a simple mistake. How? Beats me. Lol. Anyway, I really want to figure this out. The real build number is cdc6d71. I have enabled the cyclone, restarted the emulator and did notice a difference in neo geo games. Turned on frameskip to 1, and it’s almost full speed. So the cyclone driver is working, just not full speed. And that’s not a complaint, but a report on the status of this emulator on a pi zero. I really do appreciate your efforts.

barbudreadmon

@lostless Might be that the neogeo driver had too many accuracy fixes over the years then, because on my rpi1, neogeo through the old lr-fbalpha repository (now known as lr-fbalpha2012) was close to full speed (~60 fps with some slowdowns iirc). Might be a good idea to backport the cyclone stuff to lr-fbalpha2012 actually.

What about cps1/cps2 ?

lostless

@barbudreadmon cps1 and 2 (tested strider, final fight, and cadillacs and dinosaurs) are almost there. There are small moments in which they are running at full speed, but typically are running at around 90-95% speed. Soooooooooo close.