[N3MIS15]

Ive been trying to compile for android (patiently awaiting my ouya). But no luck so far

[Niks]

I happen to be the proud owner of a Xios DS, the little things are fricken awesome I haven't attempted a port because I haven't heard any interest so far. Something people are interested in?

It would be great if you would to port it!!!!
I'd be the first tester.

Do you use it on android or linux? Sorry it's certainly off topic...
But a port to play on SNES good old games would be amazing!!

[garbear]

I just reinstalled Xcode and I am currently compiling it. If it is successful I will post binaries.

Any luck?

[drivesoslow]

I just reinstalled Xcode and I am currently compiling it. If it is successful I will post binaries.

Any luck?

Not much. There are a bunch of issues. I think they probably exist in the mainline xbmc too.

[BLKMGK]

I too have a Pivos and would try it but I'd suggest getting it working on Linux first and then moving it ti Pivos Linux. It's an awesome box!

[squarepusher]

Ive been trying to compile for android (patiently awaiting my ouya). But no luck so far

You can try it of course but I honestly think on Android you're better off with the standalone RetroArch Android port.

Android has horrendously bad audio latency issues and using RetroPlayer on XBMC for Android is hardly a good idea when even the standalone RetroArch Android version has trouble matching the same performance as seen on iOS/Blackberry, never mind PCs or consoles. Having to go through audio and video layers that were originally meant for video playback purposes has the potential to make it much, much worse still. And the Ouya CPU already isn't that hot to begin with compared to the hardware that is coming this year (Tegra 4 will perhaps at last put Android at parity performance-wise with PS3 and 360 - assuming that the dreadful garbage collector stalls have been resolved by then - which they still aren't - Tegra 3 has absolutely no hope of even matching a Wii though in terms of CPU performance [at least on Android] - so you need every little ounce of CPU power you can get out of it).

So bottom line - it is unlikely to be practical on Android from a performance standpoint - the audio API is simply too high latency and this screws up our entire syncing model where you need a combination of moderately low audio latency and moderately low video latency (and at a fixed refresh rate) to get smooth gameplay. With XBMC's audio/video drivers you will have absolutely no chance in hell of getting a satisfying experience - when even the official XBMC Android version has massive audio lag (this is not Team XBMC's fault of course - it is all Android's -since XBMC iOS performs just fine by comparison) - unless you want to spend a lot of time trying to fiddle around with buffering options.

For PC it is much more practical OFC.

[garbear]

I had to fight tooth and nail to minimize the audio buffering problems on windows and alsa, if android audio is as bad as you say in the android stack itself... well, that doesn't leave us with much hope :/ I read about your refresh rate challenges on android, that doesn't sound too promising either. So basically, audio sucks, video sucks, cpu sucks... 3 not good things an emulator wants to hear. At least XBMC's use of java is pretty light, so GC shouldn't be much of an issue.

[N3MIS15]

Ive been trying to compile for android (patiently awaiting my ouya). But no luck so far

You can try it of course but I honestly think on Android you're better off with the standalone RetroArch Android port.

It would only be for testing purposes, more a curiosity than practicality. I have many other devices that are more capable than any android box.

[Robgue]

I happen to be the proud owner of a Xios DS, the little things are fricken awesome I haven't attempted a port because I haven't heard any interest so far. Something people are interested in?

I'd be very interested and can test. Linux version...

[BLKMGK]

You move to a new Branch? Retroplayer5? :-)

[Coups]

I happen to be the proud owner of a Xios DS, the little things are fricken awesome I haven't attempted a port because I haven't heard any interest so far. Something people are interested in?

I'd be very interested and can test. Linux version...

I'm interested too, and could also test the Linux version.

[mwaterbu]

Android has horrendously bad audio latency issues and using RetroPlayer on XBMC for Android is hardly a good idea when even the standalone RetroArch Android version has trouble matching the same performance as seen on iOS/Blackberry, never mind PCs or consoles. Having to go through audio and video layers that were originally meant for video playback purposes has the potential to make it much, much worse still. And the Ouya CPU already isn't that hot to begin with compared to the hardware that is coming this year (Tegra 4 will perhaps at last put Android at parity performance-wise with PS3 and 360 - assuming that the dreadful garbage collector stalls have been resolved by then - which they still aren't - Tegra 3 has absolutely no hope of even matching a Wii though in terms of CPU performance [at least on Android] - so you need every little ounce of CPU power you can get out of it).

Could we potentially get around some of android's overhead using the NDK for android development (not sure if this is already in use or is even feasible at this point in development)? I know that it allows you to do some lower level calls since you can use C/C++, but I'm not sure how much benefit this could give.
As a different alternative though, since the Tegra 3 is an ARM CPU, it would be conceivable to just get Linux running as a dual boot on the OUYA and run XBMC there. I don't believe XBMC has a live CD for ARM yet, but that would be a nice option in the future.
Also, Ubuntu will be coming out on android before too long, and from what I read, it will just share the kernel android uses (since it is practically the same as the Linux kernel finally), so it can run alongside android as a native OS. With this, you can run android apps, as well as any Linux program with the right interface. So this seems like another possible option for the future.
Anyway, just throwing out a few ideas. The OUYA could be an awesome (and cheap!) emulator machine, and XBMC + Retroarch would be an ideal all in one software solution!

[garbear]

xbmc is entirely NDK. it used to be 1 line of java, now I think it's around 19.

BLKMGK, I found some race conditions, they'll show up in the retroplayer4 branch but they might be the last commits there

[squarepusher]

I had to fight tooth and nail to minimize the audio buffering problems on windows and alsa, if android audio is as bad as you say in the android stack itself... well, that doesn't leave us with much hope :/ I read about your refresh rate challenges on android, that doesn't sound too promising either. So basically, audio sucks, video sucks, cpu sucks... 3 not good things an emulator wants to hear. At least XBMC's use of java is pretty light, so GC shouldn't be much of an issue.

Regretfully the Garbage Collector is always an issue regardless of how 'native' (ie. C/C++) your actual main code is.

That is because all of the system services running in the background are all Java (not to mention that a 'native activity' is just 'glue code' that glues your 'native' app to a couple of Java services - to call it 'native code' is really a stretch on Google's part).

So to put this into perspective - even though your native code is compiled into an ARM/Thumb library and run through Java Native Interface - the OpenGL implementation is still Java - the audio APIs (and there are several layers of them) are all still Java, the input APIs (and there are several layers of them) are all still Java, and any of them can still invoke the Dalvik garbage collector from time to time if they are not used prudently (and this happens outside your control anyway as an NDK developer).

Then you have the little enduser-specific problems where they might have installed some superfluous weather app that consistently creates Java exceptions for simple 'logging' messages or for simply not being able to connect to some server (you never know how crappy these Java services are written because the programmers themselves quite honestly are just as crap most of the time) and that in turn can set off your garbage collector as well. Or - for instance - your e-mail app might decide - based on some constant interval - to check your e-mail right while you're in the middle of a PS1 RetroArch session which will result in a sudden and devastating performance dip - little issues like that which are impossible to program around because you have no control over what kind of services are running right through your program.

Never mind that the worst offenders in this case are Google's Play Store services since it seems Google cares more about almighty ad sense and data mining than they do guaranteeing an actual reliable runtime performance state.

You have NONE of the aforementioned problems on iOS, or on QNX - both had the good sense not to have the entire OS revolve around some managed code VM. It is enough to make me basically consider Android to be a total piece of garbage (compared to iOS/QNX) that should be 'gutted' and 'rebooted' - Windows 9x to NT transition-style - if Google has any hope of keeping on top - when the latest Apple OS (iOS 6.1.3) fits happily inside the iPad 2/iPad Mini's 512MB of RAM while still leaving you with at least 300MB RAM free or more, whereas Google's Android 4.2.2 requires 'at least' 768MB of RAM if you don't want constant onLowMemory invocations, that represents an epic collosal engineering failure on Google's part and quite frankly this is going to catch up with them and haunt them for a long time.

[Kandungo]

I am running this on xbmcbuntu, compiled your branch just fine, however when i try to launch any of my snes roms (their all .smc, none are zipped), it tells me "install emulator" no matter which emulator i install, it keeps popping up, and the logs say this.

[QUOTE]
21:38:38 T:3037677312 DEBUG: CPlayerCoreFactory::GetPlayers(/mnt/DunDu/DunDu/Roms/FULL Super Nintendo -- Fa micom (GoodSNES 2.04)[GoodMerged]/Zoop (U) [b1].smc)
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: system rules
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: matches rule: system rules
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: rtv
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: hdhomerun/myth/mms/udp
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: lastfm/shout
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: rtmp
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: rtsp
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: streams
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvd
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvdimage
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: sdp/asf
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: nsv
21:38:38 T:3037677312 DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: radio
21:38:38 T:3037677312 DEBUG: CPlayerCoreFactory::GetPlayers: matched 0 rules with players
21:38:38 T:3037677312 DEBUG: CPlayerCoreFactory::GetPlayers: adding retroplayer
21:38:38 T:3037677312 DEBUG: CPlayerCoreFactory::GetPlayers: added 1 players
21:38:38 T:3037677312 INFO: RetroPlayer: Opening: /mnt/DunDu/DunDu/Roms/FULL Super Nintendo -- Famicom (Go odSNES 2.04)[GoodMerged]/Zoop (U) [b1].smc
21:38:38 T:3037677312 DEBUG: RetroPlayer: ---------------------------------------
21:38:38 T:3037677312 DEBUG: RetroPlayer: Game tag loaded
21:38:38 T:3037677312 DEBUG: RetroPlayer: URL:
21:38:38 T:3037677312 DEBUG: RetroPlayer: Platform:
21:38:38 T:3037677312 DEBUG: RetroPlayer: Title:
21:38:38 T:3037677312 DEBUG: RetroPlayer: Game Code:
21:38:38 T:3037677312 DEBUG: RetroPlayer: Region:
21:38:38 T:3037677312 DEBUG: RetroPlayer: Publisher:
21:38:38 T:3037677312 DEBUG: RetroPlayer: Format:
21:38:38 T:3037677312 DEBUG: RetroPlayer: Cartridge Type:
21:38:38 T:3037677312 DEBUG: RetroPlayer: ---------------------------------------

[\QUOTE]