libretro core build target/example

[eadmaster]

is there an example for building a libretro-compatible core?

I think this would be interesting to have support for a lot of platforms.

[raysan5]

@eadmaster there is already a related project: https://github.com/RobLoach/raylib-libretro

[eadmaster]

If i am not mistaken, that is a libretro frontend, not a core using raylib:

A libretro frontend is a program that can run libretro-compatible programs.

A libretro core is a program (a game/emulator/miscellaneous) that has been ported to the libretro API so that it can be used by libretro frontends.

https://www.libretro.com/index.php/develop/

[orcmid]

The purpose of Libretro is to have portable cores for which a front-end provides all of the "platform" and adaptations. So in this case, as in raylib-libretro, the use of raylib is accomplished in the front end, not in the core. (The use of "front-end" is a bit confusing as a term, think of it as a "harness" for a core game.)

I looked at libretro.h and the current code of rayib-libretro to confirm this as well as I could.

If you want to create a libretro core, it is not about raylib and you need to look for examples. You could test it with a libretro front-end that employs raylib, such as raylib-libretro. Also, contributions to raylib-libretro (which has many unimplemented libretro features) would doubtless be welcome.

I think this is a pretty round-about way to make a new game. There are some performance costs in harnessing the way libretro operates that are insignificant when preserving a game that ran on now-ancient hardware. A new graphics intensive game might be a bit pinched.

[raysan5]

@RobLoach what do you think? is it possible? :D

[RobLoach]

It could be possible, would be quite a bit of work. raylib-libretro is a libretro frontend allowing to run cores. A core built to use raylib would mean embedded raylib within the a libretro-raylib core, and mapping all the APIs to use libretro's platform-agnostic callbacks instead. A few things to consider out of that...

• Graphics: libretro does allow stating a few different hardware contexts (OpenGL, Vulkan, D3D, etc). The contexts can be a challenge to map correctly, so mapping the GLFW calls over to libretro calls could be tricky.
• Platform: raylib targets glfw, but for libretro we'd need to introduce a PLATFORM_LIBRETRO and switch some of the APIs to use parts of libretro-common
• Audio: libretro expects an audio buffer set for each frame, which likely possible with raudio/miniaudio.
• Input: Rather than using glfw, we'd map over retro_input_state_t to get input state
• Control Flow: raylib expects one int main() function, where windows are set up, and then the game loop starts. However, similar to how emscripten somewhat flips the runtime flow, libretro is built upon callbacks instead. retro_run() is called each frame, for instance.
• File System: raylib does a great job ensuring all files are loaded through a singular file API. We'd have to wrap those functions around libretro's VFS functionality

So, not impossible, just a good amount of work 😅 ... Another interesting approach could be introducing a _GLFW_LIBRETRO to GLFW, but haven't looked deep into how GLFW is designed.

[raysan5]

@RobLoach Wow! Thank you very much for such a detailed explanation! Personally I'm not interested in follow that route for now but it's a great review on the key requirements to make it possible for any adventurer facing this challenge! :D

[RobLoach]

Haha, I don't blame you! Big endeavour 😉 ... Also wouldn't want to bloat the code base!

[RobLoach]

@eadmaster Took another approach with a fork of rtextures.c for the framebuffer over at https://github.com/RobLoach/libretro-rimage . Discussion about a cleaner design of it over at: #2865