[Megatron]

Amazing work!

Would this work for all platforms like OpenELEC?

[squarepusher]

RetroArch is merely a frontend that makes use of the libretro API, that's all.

The way I see it, RetroPlayer is basically XBMC's RetroArch.

Basically, RetroArch and libretro complement each other and depend on each other, and one wouldn't exist right now without the other. I've spent the past year and a half now creating the foundational framework porting RetroArch to as many devices as possible and increasing the libretro ports library precisely so that it could get adopted by third parties now. It's the chicken and egg problem - if there were too few libretro ports there would be no interest in the API, and if RetroArch was not ported to as many platforms as possible, there would be no userbase, no recognition and also no believability concerningthe 'multi platform' goals of the project.

Regarding alternative libretro frontends - I totally support it and I think the XBMC libretro player is very promising stuff. The more apps that get onboard like this, the better. That being said, RetroArch will likely not become obsolete anytime soon - for one, it's still the reference frontend - when new features get pushed in either the API or we come up with new frontend additions, it will likely end up in RetroArch first before everyone else. Second, it probably is the most portable frontend right now (having been ported to the most amount of systems). And third, it will probably be pretty hard for any derivative frontend to beat our audio/video/input perfomance levels that we achieve in RetroArch - thanks in no small part due to things like this -

https://github.com/libretro/libretro.git...ontrol.pdf

Another advantage of alternative libretro frontends is that we have been getting rather annoyed by some of the requests we have been getting regarding kitchen sink GUI features and 'support every archive under the sun' requests - so if other frontends can pick up the slack for our total indifference to catering to that stuff, that would work out great for both end-user and developer involved - I could just point them to alternative frontends then instead of just totally alienating them.

Back on topic: I don't wanna bother garbear cause this isn't exactly retroplayer related but, what's usually used to compile these cores (in this case, on Windows)?

Some ports dont have MSVC project files and I was thinking of using MinGW.

I will have to add MSVC project files for the Mednafen ports, yes (to name but one prominent port that has no MSVC solutions right now). This is a particular pain in the arse because the main author doesn't care the slightest about MSVC backwards compatibility and she seems fond of using non-standard GNU-specific things like computed gotos and case ranges (it's the only project I've seen so far that has gone down this road so blatantly - all the rest are pretty much portable). There's basically no way to get the Mednafen cores working without some extensive changes. All of this could be easily solved if the author and porter in this case were to try to settle for a good compromise so that converting code would not be so time consuming and that Mednafen would gain in portability, but unfortunately, that requires caring about it. Tried reaching out but it seems a lost cause.

Anyway, yeah, expect the Mingw port for most libretro ports to arrive sooner than MSVC ports for this reason. The reason I still get around to adding MSVC ports to begin with is because I target Xbox 1 and 360 as well- and that basically means getting a VS2003 / VS2008/2010 solution ready that compiles into a library.

Thing is, there are lots of libretro ports nowadays and not all of them are included there, that's why I'm compiling some of them myself.

I would be highly interested if you could point me to libretro ports that are not covered by libretro-super - for better or worse we still control all main libretro ports - I either push updates/patches upstream to the respective projects' repositories or I do git pull requests and it gets synced upstream that way. Either that, or when a new porter comes along and makes new libretro ports, I invite him to the libretro organization so that we can do collaborative development on them.

One of the upshots of being hands-on with the libretro ports is that ports to nearly every libretro platform that we support can be maintained - not many people like me have all these consoles at their disposal nor would they care enough to port to them all.

[garbear]

I've been waiting for something like libretro for a few years, a common emulator api is an idea too good not to happen.

I stand by these words

[paendorz]

I would be highly interested if you could point me to libretro ports that are not covered by libretro-super - for better or worse we still control all main libretro ports - I either push updates/patches upstream to the respective projects' repositories or I do git pull requests and it gets synced upstream that way. Either that, or when a new porter comes along and makes new libretro ports, I invite him to the libretro organization so that we can do collaborative development on them.

Off the top of my head, I can think of the Doom, NXEngine and DOSBox implementations. But I remember only trying those on Linux (both ARM and x86/x64), maybe they don't have a Windows build and that's the reason they're not there, portability.

Edit: Now that I think about it, I did build prboom on windows, but it raised an exception when using it on retroplayer. Can't remember if I ever used it via RetroArch.

@garbear
I made a pull request to your repo adding RGB565, it was a pretty simple edit. As far as the A/V sync issue, I don't know that much about AudioEngine but I'll look into the code.

[squarepusher]

I would be highly interested if you could point me to libretro ports that are not covered by libretro-super - for better or worse we still control all main libretro ports - I either push updates/patches upstream to the respective projects' repositories or I do git pull requests and it gets synced upstream that way. Either that, or when a new porter comes along and makes new libretro ports, I invite him to the libretro organization so that we can do collaborative development on them.

Off the top of my head, I can think of the Doom, NXEngine and DOSBox implementations. But I remember only trying those on Linux (both ARM and x86/x64), maybe they don't have a Windows build and that's the reason they're not there, portability.

Edit: Now that I think about it, I did build prboom on windows, but it raised an exception when using it on retroplayer. Can't remember if I ever used it via RetroArch.

Prboom should have an VS 2010 solution at least. I'll look at getting NXEngine ready.

[paendorz]

I would be highly interested if you could point me to libretro ports that are not covered by libretro-super - for better or worse we still control all main libretro ports - I either push updates/patches upstream to the respective projects' repositories or I do git pull requests and it gets synced upstream that way. Either that, or when a new porter comes along and makes new libretro ports, I invite him to the libretro organization so that we can do collaborative development on them.

Off the top of my head, I can think of the Doom, NXEngine and DOSBox implementations. But I remember only trying those on Linux (both ARM and x86/x64), maybe they don't have a Windows build and that's the reason they're not there, portability.

Edit: Now that I think about it, I did build prboom on windows, but it raised an exception when using it on retroplayer. Can't remember if I ever used it via RetroArch.

Prboom should have an VS 2010 solution at least.

It does, that's how I built it. But it's giving me trouble on RetroPlayer, I'll look into it when I have the time.

Edit: Crash is related to D_DoomDeinit, that much I know.

[King Dude]

Does RetroPlayer have LAN capabilities? If not, do you think a LAN feature could be added sometime in the future?

[joolz]

This is awesome, will RetroPlayer eventually support pixel shaders for the authentic CRT look?

edit: Also background shaders are very cool: http://filthypants.blogspot.se/2012/09/b...oarch.html

[natethomas]

Whoa. Those background shaders are a really cool idea.

[King Dude]

This is awesome, will RetroPlayer eventually support pixel shaders for the authentic CRT look?

edit: Also background shaders are very cool: http://filthypants.blogspot.se/2012/09/b...oarch.html

Those shaders are awesome.

[DigitalAnvil]

This is awesome, will RetroPlayer eventually support pixel shaders for the authentic CRT look?

edit: Also background shaders are very cool: http://filthypants.blogspot.se/2012/09/b...oarch.html

Those shaders are awesome.

CORRECTION:
This WHOLE post is awesome

[Themaister]

This is awesome, will RetroPlayer eventually support pixel shaders for the authentic CRT look?

edit: Also background shaders are very cool: http://filthypants.blogspot.se/2012/09/b...oarch.html

Those shaders are awesome.

For shaders in RetroArch, we made a specification for Cg (which work on GL and D3D9). There are half a bazillion shaders for that spec already.
Spec: https://github.com/Themaister/Emulator-S.../Cg/README.
It supports multi-pass, LUT/border textures and most stuff you'd want from 2D retro game image shading.

Of course shaders aren't part of libretro itself, but hey.

[King Dude]

This is awesome, will RetroPlayer eventually support pixel shaders for the authentic CRT look?

edit: Also background shaders are very cool: http://filthypants.blogspot.se/2012/09/b...oarch.html

Those shaders are awesome.

For shaders in RetroArch, we made a specification for Cg (which work on GL and D3D9). There are half a bazillion shaders for that spec already.
Spec: https://github.com/Themaister/Emulator-S.../Cg/README.
It supports multi-pass, LUT/border textures and most stuff you'd want from 2D retro game image shading.

Of course shaders aren't part of libretro itself, but hey.

It would also be cool if people could use custom artwork for background shaders.

[wimpy]

we over at emuxtras.net are following this thread and will see how we can help with xtras support (artwork etc) in skins.
the idea and project is amazing and something people are really eager to see happen

[spjonez]

garbear did you branch off Eden or Frodo? I saw your GIT link, I've used SVN but I don't have any experience with GIT and was wondering if it would be possible to merge your branch into the current Frodo trunk (locally).

This looks very promising and I'd be willing to donate for beta testing privileges. I got a Raspberry Pi for Christmas and I'm currently using two SD cards, one for XBMC and one for RetroArch (both auto-start respective front ends). Being able to launch games directly from XBMC and have it all on one build would be a dream come true!