[Adam7288]

So I think we can all agree that progress on this promising project has completely stalled out. While interested people who are not writing code do need to exhibit patience, there is a time and a place where alternative plans must be discussed and considered.

Here is my proposal:

OpenEmu is a mac-based open-source piece of software which has accomplished all of the goals of retroplayer, albeit not inside xbmc. Also, without a 10 foot UI. I propose that a significant chunk of their code be used to move things forward swiftly. The benefits of using their code are the following:

1. Controller / joystick abstraction completed
2. Games library + scraping engine completed
3. Auto detect + custom emulator core options
4. Simple to select shaders (changed on the fly)

Basically, if you could take openemu and put on a new coat of XBMC paint to it - you would have a full blown retroplayer right now. Why reinvent the wheel?

[Kib]

You realise that retroplayer is an implementation of libretro but with the XBMC coat of paint being applied to it ?
What you are suggesting is almost exactly what retroplayer is doing already.

[Adam7288]

Openemu is also an implementation of libretro, yes. But the aforementioned items are what gives retroplayer its whole point vs running libretro from command line. All these UI-related items have successfully been implemented in Openemu.

[encript]

I imagined that since this project began in late 2012 we would have reached somewhat of a milestone by now. Agreed OpenEMU is pretty awesome, and more of a finished product, but as Kib said its essentially the same thing with a different coat of paint. The only difference is that OpenEMU's coat of paint has dried and Retroplayer's is still a bit wet. But you cant rush perfection. When this is ready, this is gonna blow everyone's mind (also retroplayer is not limited to only Macs). Perhaps some code in OpenEMU might be useful to the RetroPlayer project.

[Adam7288]

This is not a matter of a coat of paint. There are missing features, regardless of the way it is presented, from Retroplayer at the moment. The most important one being the games library. However, the player itself needs to take cues, at a bare minimum from openemu. Instead of building, for instance, the controller setup dialog from the ground up, why not use the logic already developed for OE? There is no reason to have duplication of efforts, especially when many of the features are going to be fairly identical. The only difference being, as you note, the color of the "paint".

[OmniBlade]

The logic for OE will be written in objective C no doubt and will be specific to OS X (calls to cocoa and other OS X frameworks a libraries), I'm sure any code that can be used or inspiration drawn from will be, but its not a cut and paste job. Retroplayer pretty much IS the putting an XBMC coat on libretro in the same way OE is the putting on an OS X coat.

[squarepusher]

This is not a matter of a coat of paint. There are missing features, regardless of the way it is presented, from Retroplayer at the moment. The most important one being the games library. However, the player itself needs to take cues, at a bare minimum from openemu. Instead of building, for instance, the controller setup dialog from the ground up, why not use the logic already developed for OE? There is no reason to have duplication of efforts, especially when many of the features are going to be fairly identical. The only difference being, as you note, the color of the "paint".

OpenEmu is totally nonportable. Dependencies on Objective C, Cocoa, Quartz - good luck with porting that to any non-Apple platform. Hell, it isn't even ported to iOS (unlike RetroArch) and it would probably take considerable effort for it to ever appear on iOS to begin with (but they probably don't like iOS anyway since they know they can't get emulators on the app stores and jailbreaking is pretty much niche).

Also, OpenEmu is not 'really' a libretro client - SOME of the libretro cores' sourcecode is taken and then modified so that it works with OpenEmu. It doesn't really take libretro cores as dynamic libraries and runs them - so it's not like RetroPlayer really and it's much more monolithic. OpenEmu and the RetroArch project can be considered as friendly to each other, but overall I don't think OpenEmu is really a good base to build upon on a non-Apple platform. It just isn't - and I think even the developers agree with that - hence it being Mac-only (v10.7 and up - RetroArch is v10.6 but has far less eye candy).

Anyway, I might be willing to help with this RetroPlayer project so that progress can be sped up. In the long run, RetroPlayer will REALLY have to support libretro GL - since more and more cores will start appearing that implement libretro GL.

[ChrisMyhre]

This is not a matter of a coat of paint. There are missing features, regardless of the way it is presented, from Retroplayer at the moment. The most important one being the games library. However, the player itself needs to take cues, at a bare minimum from openemu. Instead of building, for instance, the controller setup dialog from the ground up, why not use the logic already developed for OE? There is no reason to have duplication of efforts, especially when many of the features are going to be fairly identical. The only difference being, as you note, the color of the "paint".

I think the project has come along awefully quickly especially since there is only one programmer working on this project. Especially comapred to the other project I ahve watched closly (built in transcoding, which seems totally dead). There are pretty obvious flaws in trying to adapt a Mac project for XBMC. Also I'm pretty sure that the games library you're so desperate for will be extremely easy to impliment in XBMC once this is merged to mainline and really more approprate to add there anyway. For now you can pretty easily use advanced launcher or rom colelction browser.

Thanks again to garbear for all of your efforts on this project.

[Adam7288]

Perhaps I was not clear enough. I am not suggesting that a copy and paste job is going to get us where we want to go. Let me try again.

The "retroplayer" in its purest definition is a new player which sits side by side with the video player in xbmc. It makes API calls to libretro via controller inputs which are abstracted, and then displays the output from libretro in the form of audio and visual output.

Thats all well and fine, and in actuality that part is closer to completion than anyone could have hoped for.

The problem we face is that this is not a complete product. It is not a complete experience. The "added value" comes down to two basic ideas:

1. Setting up the environment before the player is launched. The experience here is going to be the game library, divided into systems, hopefully be searchable, including scraping, etc. Favorites a plus. Also, the controller setup. It should have a user friendly way to assign buttons.

2. Changing the libretro environment while already in a game. This can be by[/b] changing shaders, rewinding, save states, changing cores, changing roms. This too should be accomplished in a user friendly way.

OpenEmu, while written in an entirely different language and using libraries which are irrelevant to xbmc, still provides a blueprint. Logic is logic. Algorithms are still algorithms no matter what language they are in. Design philosophy is independent of code.

Deciding now how to most efficiently move forward will save lots of unnecessary work and backtracking going forward. If there is one thing I have learned when it comes to designing complex systems - it is that an hour of planning saves a day of unnecessary work and floundering without direction.

[OmniBlade]

Garbear has already stated he has plans for the joystick a pi and the scrapers but they are relying on other projects within xbmc to be completed. If it was just a matter of pulling algorithms, passable scrapers are already in ROM collection browser, omthing already much closer aligned with xbmc. From my limited perspective it looks like its man hours implementing, not planning that is needed.

[GSP-UFC]

Just curious once Gotham gets released are there any plans of other XBMC programmers to come over and help Garbear out? The guy seems to be pretty busy with school.

[Dippo]

I would really like to help out a bit. Git branches look pretty messed up right now and I don't really know where to start. Garbear seems to be working on it at the moment so maybe after the Gotham release we have some clean base to start with.