-
Notifications
You must be signed in to change notification settings - Fork 36
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
Comments
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 :) |
@DSkywalk thank you very much and understood - I will see what I can do! Thanks |
@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! |
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! 🎄 |
It is true that is very slow compared to other cores like Snes9x in example. Runs about half frame rate. |
finally merged new 8bpp rendering f02e94e |
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
The text was updated successfully, but these errors were encountered: