LÖVE

Hi All,

I've created a module that makes it possible to load and run libretro cores in LÖVE. It's a native module and it uses the native LÖVE API, so it needs to be built with LÖVE.

The repository is here, and the module is in the libretro branch. After switching to that branch, build LÖVE how you normally would, the module should be compiled in.

Load a core with love.libretro.newCore('path_to_so', 'path_to_rom'), and call core:step() at a fixed interval depending on the core. Get an image to draw with core:getImage(), audio plays automatically. Use core:setInput() and core:setKey() to send inputs to the core before calling core:step().

There are more methods, i.e. to query information from the core, exist, take a look at the wrap_Core.cpp file to see them all.

The API is not set in stone, the input API is likely to change. I'm also thinking in returning ImageData and SoundData from core:step() instead of having the core:getImage() method and playing the audio automatically. Ideas welcome.

Yes, I've been told that a pure Lua module is possible, using FFI. While I think it's completely feasible, my focus for now is to finish this native module. If someone wants to make a pure Lua module, it shouldn't be difficult to translate the b.

Cheers,

Andre

leiradel wrote: ↑Mon Apr 27, 2020 10:38 pm Hi All,

I've created a module that makes it possible to load and run libretro cores in LÖVE. It's a native module and it uses the native LÖVE API, so it needs to be built with LÖVE.

That rocks! Indeed an FFI implementation would be even better, but hey, you've achieved quite a lot!

How about the opposite, a libretro core that implements Löve? (I'm only half joking; there's Lutro after all).

leiradel wrote: ↑Mon Apr 27, 2020 10:38 pm The API is not set in stone, the input API is likely to change. I'm also thinking in returning ImageData and SoundData from core:step() instead of having the core:getImage() method and playing the audio automatically. Ideas welcome.

Returning ImageData allows using Image:replacePixels which I think is better for multi-frame. Even better, it could accept an ImageData object sent by the user, and fill it in; that way there's no garbage generation or useless allocation/deallocation.

Or it could do that, but with an Image object, and use replacePixels internally. Or perhaps it could even use the video facilities.

As for sound, I'll defer that to our sound expert

pgimeno wrote: ↑Tue Apr 28, 2020 6:20 am

leiradel wrote: ↑Mon Apr 27, 2020 10:38 pm ...

...As for sound, I'll defer that to our sound expert

That's probably not me but let me chime in regardless

Full disclosure is, we did discuss this at length in Discord previously; i can only say that while it would give more options for the person that wants to use this module to do stuff with the audio if they could query for SD buffers already queued (which could introduce some extra latency), but handling sound automatically like this would be fine for those that don't want to mess with QueueableSources and the like... although i must admit that exposing at least a volume setting would be nice.

...If anything, if or whenever an FFI implementation would surface, and if libretro could give you PER-VOICE mono/stereo output (depending on the emulated system of course), that would unlock even further processing... but yeah, that's not that important for the overwhelming majority of use cases.

pgimeno wrote: ↑Tue Apr 28, 2020 6:20 amHow about the opposite, a libretro core that implements Löve? (I'm only half joking; there's Lutro after all).

I wanted to port Löve to the Libretro API when i was part of the team there, but it needs OpenGL and it makes a port much more difficult.

pgimeno wrote: ↑Tue Apr 28, 2020 6:20 amEven better, it could accept an ImageData object sent by the user, and fill it in; that way there's no garbage generation or useless allocation/deallocation.

I would reuse the data objects to avoid generating garbage.

pgimeno wrote: ↑Tue Apr 28, 2020 6:20 amOr it could do that, but with an Image object, and use replacePixels internally.

That's the current approach

zorg wrote: ↑Tue Apr 28, 2020 12:17 pmFull disclosure is, we did discuss this at length in Discord previously

Thanks again for all the info.

zorg wrote: ↑Tue Apr 28, 2020 12:17 pmi can only say that while it would give more options for the person that wants to use this module to do stuff with the audio if they could query for SD buffers already queued (which could introduce some extra latency), but handling sound automatically like this would be fine for those that don't want to mess with QueueableSources and the like... although i must admit that exposing at least a volume setting would be nice.

I agree, I'll leave audio and video alone until a good need for something different arrives. And I also agree with the volume setting, I'll add it to the core API.

zorg wrote: ↑Tue Apr 28, 2020 12:17 pm...If anything, if or whenever an FFI implementation would surface, and if libretro could give you PER-VOICE mono/stereo output (depending on the emulated system of course), that would unlock even further processing... but yeah, that's not that important for the overwhelming majority of use cases.

The Libretro API only exposes the stereo, 16-bit PCM audio data