Easier said than done. Motivation is the main issue here. If you want something done really bad, look in the mirror - that is most likely the guy that is going to do it.
- higan bgba (most accurate GBA emu out there?)
I highly doubt that BTW. Certainly not in terms of compatibility. Correct me if I’m wrong - even if it were, it’s useless for my aims if it’s even slower than VBA (and that is already bad enough as is - very bad in fact).
What we need is an emulator way faster than VBA (because we need it BADLY on Android) and more compatible/accurate than gpSP. It’s a shame that gpSP was abandoned so prematurely just out of spite for certain PSP sceners - I actually think active development on gpSP by the main coder would be of more importance today than it was back then - especially if it would be multiplatform like a libretro port would be.
Unfortunately, as things stand, there are some big roadblocks (having looked at the gpsp code myself thinking of doing a port - in particular looking at notaz’ fork) -
1 - No way to do a non-dynarec version right now - it seems to insist on ‘translate’ macro blocks being there so I take it the interpreter still relies on some recompiler parts unless I’m simply not understanding it right or Notaz did some changes in his fork.
2 - Heavy reliance on SDL - and since I don’t really feel like baking in SDL (I did it once for Cave Story and honestly - I don’t trust the implementation of SDL on every one of the systems we support to be fast - not to mention that I think the SDL API makes for some pretty terrible implementation code in general), it would require a substantial rewrite.
3 - The dynarecs (even in the cases where we would be able to use them, like x86/MIPS/ARM) are 32bit only. This means that a 32bit x86 gpsp libretro library could only be played on a 32bit RetroArch frontend. Doesn’t really jive with the multiplatform portability we are trying to go for. That most of my development platforms are x86_64 as well doesn’t really help with doing the port in the first place.