search

ares-emulator / ares

ares is a cross-platform, open source, multi-system emulator, focusing on accuracy and preservation.
https://ares-emu.net
Other
998 stars 123 forks source link

libretro target support #1375

Open eadmaster opened 10 months ago

eadmaster commented 10 months ago

Is your feature request related to a problem? Please describe. I'd like to use ares as a Retroarch core.

Describe the solution you'd like Add a build target in the makefile to produce a libretro core. (could be a single libretro core or a separate core for each ares' native core)

Describe alternatives you've considered There are bsnes and higan libretro ports, but they only provide the snes core.

Additional context could help with some pending issues: https://github.com/ares-emulator/ares/issues/1259 https://github.com/ares-emulator/ares/issues/167 https://github.com/ares-emulator/ares/issues/182 https://github.com/ares-emulator/ares/issues/660 https://github.com/ares-emulator/ares/issues/1101 https://github.com/ares-emulator/ares/issues/1357

libretro docs: https://github.com/libretro/libretro.github.com/blob/master/documents/libretro.pdf

dracc commented 10 months ago

Is this a mock request?

eadmaster commented 10 months ago

sorry, what do you mean?

EDIT: i see this was discussed on discord a few months ago:

I could be wrong, but I think making ares into a libretro core would be a gargantuan task and I doubt anybody would undertake that unless many cores were complete and most features were implemented

dracc commented 10 months ago

sorry, what do you mean?

Yes, it's a huge undertaking, but the ares devs doesn't seem to back down from an interesting challenge. The thing I meant was that Near and the RA team didn't have the best relationship. Like, bad bad if I've understood correctly.

eadmaster commented 10 months ago

i see.. no problem, even if it takes some time i think it may be worth the effort for the extra features the RA frontend provides, rather than reimplementing them from scratch.

I'll keep watching this issue if there is any progress, feel free to close or reopen.

mudl0rd commented 9 months ago

rather than reimplementing them from scratch.

It would be better to reimplement an emulator exclusively from scratch, rather than port Ares. Certainly, info such as instruction/N64 system behavior and things can be gleaned from Ares and MAME, like with simple64 and gopher64, which are new emulators while still using info from Ares/MAME/etc.

That way, performance problems due to libco and libretro's design can be mitigated, plus it allows for things outside the scope of Ares (for instance, you could do HLE emulation of audio microcodes while still using LLE for video/other RSP tasks, or even HLE video emulation while still having a cycle based R4K). For instance, libretro cores require completely reentrant code. Which might not work with Ares' and other emulators' design, which leads to performance problems when using libco to sidestep the hassles of rewriting core loops to fit libretro's design philosophy. libco for libretro often involves thrashing register state per frame and using thread local storage, and also sometimes not preserving SSE/NEON register state between calls, which can reduce performance for cores which use JIT.