[DRAFT] libretro core proof-of-concept

[jeapostrophe]

This PR has a basic version of a libretro core.

There are some obviously ugly things that would be a lot more beautiful with some (hopefully small) changes to Supermodel, but it performs very well on OS X and Windows with 'Spikeout: Final Edition'.

Things I wish were a little different about Supermodel

• Main --- I copied a bunch of code from Src/OSD/SDL/Main.cpp, which I would otherwise call if those functions were public. CreateGLScreen is almost identical, although I modified my copy to hide the window.
• Configuration --- I would have liked to have an easy enumeration of all the config variables that Supermodel looks for and then I would call them through the libretro environment callback. Instead, I've just hard-coded it.
• SaveStates --- It would be very nice if there were code not only in SDL/Main that dealt with save states and it would be even better if they could work without files. My implementation writes a temporary file and then reads it. It would also be nice to be able to predict the size of the state without writing it, but I don't know if that is possible.
• Audio --- The existing Audio system relies on implementations providing C functions, rather than using an object interface. If there were an object interface, it would be a lot cleaner. I think I understand why it does it the way it does because it is hard to get the audio callback pointer deep into the bowels of the sound board code. Maybe a compromise would be to abstract the Audio OSD interface with an SDL version and a version like this? I worked around this with a #define

Things I'm not sure how you'd prefer things to be implemented

• Building --- I've made it so there's a new build path that supports building the binary, but it actually doesn't work. Either the build system right now doesn't have a good way of giving different #define; although if the Audio issue is resolved, it wouldn't be necessary.

Hacks I made that are possible to fix but I just haven't done

• Input --- My InputSystem implementation is an okay way of working with libretro, but a "better" way would be to reflect the different input types with libretro's input descriptor system.
• OpenGL --- I am hacking by opening up a hidden SDL window and having it do rendering, rather than asking libretro for a context. This works well on desktop, but presumably would fail on mobile. I made a fake pixel format (1337) which is RGBA_UpsideDown, but it would be better to use XRGB8888 and do the transformation inside the core. My fake format is fine for my testing because I have a testing front-end that uses RGBA anyways.
• NVRAM --- I've ignored this, but libretro provides a way to look at a save directory.

I'm posting this to get feedback on the above points and advertise in case anyone else is interested in working on this.

[3v1n0]

This is lovely, is there any interest upstream (and by this, I mean: to refactor things so that this could be integrated without hacks)?

As it would make possible to get supermodel working in various handhelds devices easily!

[cerroverb]

LFG

[jeapostrophe]

FWIW, I play Spikeout with this almost every day and haven't had to make any changes. I haven't tested any other games. I expect that gun games will be the biggest problem.

[SRC267]

FWIW, I play Spikeout with this almost every day and haven't had to make any changes. I haven't tested any other games. I expect that gun games will be the biggest problem.

That's probably the only game I'd play, is the core available for android too? I'd like to test.

[trzy]

Need to look into this over the holidays!

[cerroverb]

FWIW, I play Spikeout with this almost every day and haven't had to make any changes. I haven't tested any other games. I expect that gun games will be the biggest problem.

I also play Spikeout, I'm working on my 1cc right now. I would love to test

[jeapostrophe]

Is the core available for android too? I'd like to test.

@SRC267 I have not done anything to port to new platforms. I have tested on macOS and Windows and I use Windows regularly. The way I did the core is not very conducive to a mobile port because of the hidden window creation and framebuffer read.

[SRC267]

Is the core available for android too? I'd like to test.

@SRC267 I have not done anything to port to new platforms. I have tested on macOS and Windows and I use Windows regularly. The way I did the core is not very conducive to a mobile port because of the hidden window creation and framebuffer read.

Okay, if you have the windows core, I can try it on my PC. I have a few PCs, I'll try it on my handheld pc.