libretro / libretro-cap32

caprice32 4.2.0 libretro
21 stars 34 forks source link

Core performance on old ARM 32-bit SoC - ways to improve? #128

Open andymcca opened 1 year ago

andymcca commented 1 year ago

Hi,

I've built this core using the LOWRES option which is great and together with the 16-bit colour core option means it works on my Leapster Explorer at 320x240 with no borders! (screen is centralised so borders are in the overscan)

Unfortunately performance is very slow (~15fps) and this is undoubtedly due to the CPU involved (ARM v5te running at 532Mhz, no hardware floating point). I'm happy to dive in to the code to seek optimisations but before I do, are there any overriding reasons for this? I know the base emu is quite old now so I'm guessing it's the libretro requirements involved that are perhaps the issue.

Many thanks! Andy

DSkywalk commented 1 year ago

The CPC is a rather complex machine with a proprietary chip that allows custom resolutions and lots of effects. Emulating all that is not "cheap". I made a GP32 port that ran at 133Mhz almost fullspeed, but a lot of compromises were made and the audio I think I lowered it to 11Khz...

My focus for improvements has always been to increase the emulation accuracy, trying not to raise the load of rendering a CPC frame.

I have to tell you that despite the base is old, it's very well done and uses very ingenious tricks. Anyway, if you see that you can improve something without affecting the current emulation, that's great :)

andymcca commented 1 year ago

@DSkywalk thank you very much and understood - I will see what I can do! Thanks

andymcca commented 1 year ago

@DSkywalk is your GP32 port on Github?

The issue I see with RetroArch being all things to all platforms is that it's simply overkill in some instances - taking your comment about audio for example, the Leapster Explorer handheld has a single 1-inch speaker for audio, so cores producing stereo audio at 44.1Khz is kind of a waste of time and unnecessary use of an already weak CPU.

I started looking at this in gpSP (standalone and core) as with the dynamic recompiler it runs great but in some cases the audio is quite choppy - I believe the original GBA only did audio at 32Khz, yet gpSP seems to output at 44.1Khz!

DSkywalk commented 1 year ago

@DSkywalk is your GP32 port on Github?

No the code is on my blog, but it's awful... :rabbit2:

As far as I remember the low quality sampling part was all removed from the core. But changing it to mono and 8bits I think is still possible to work and could be set with a compile flag (I prefer not to complicate the configuration for the user in this case).

Happy Christmas! :christmas_tree:

metallic77 commented 1 year ago

It is true that is very slow compared to other cores like Snes9x in example. Runs about half frame rate.