Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
andymcca opened this issue Dec 12, 2022 · 6 comments
Closed

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

andymcca opened this issue Dec 12, 2022 · 6 comments
Labels

Comments

@andymcca
Copy link

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
Copy link
Collaborator

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
Copy link
Author

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

@andymcca
Copy link
Author

@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
Copy link
Collaborator

DSkywalk commented Dec 23, 2022

@DSkywalk is your GP32 port on Github?

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

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! 🎄

@metallic77
Copy link

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

@DSkywalk DSkywalk mentioned this issue Jul 12, 2023
2 tasks
@DSkywalk
Copy link
Collaborator

DSkywalk commented Jan 5, 2025

finally merged new 8bpp rendering f02e94e

@DSkywalk DSkywalk closed this as completed Jan 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants