Win64 and Android Test Builds

General Development
#841

@newisle, I’m not sure what is going on with your device, I always test each Android build on my Note 3 to make sure both RA & the cores are working. Does RA even launch or does it crash immediately? I also haven’t played around with 4DO yet, so I can’t answer that right now.

@r-type, That and fixing emu.mak fixed the issue, should I submit a PR for it?

@BlockABoots, Let’s see if this version specifically for OpenElec works, I use kUbuntu as my Linux distro but I wasn’t sure what dependencies would be needed. I’ll still build the Win64 builds for myself but also to help find any issues that do pop up and the same for Android when/if it makes it to the buildbot.

@AndresSM/Radius, maybe you can help me out on something. I did some testing compiling bSNES with strange results. With my gcc 4.7.3 toolchain then Megaman X3 plays fine but Megaman X2 has that one slowdown, but when I compiled using my gcc 4.8.3 / gcc 4.9.1 / Maister’s 4.8.1 / cross compile on Linux with mingw64 gcc 4.9.1 it plays them at half the speed and yet the one from the buildbot plays them just fine.

Edit: Before I forget I was able to compile the latest UME for both Win64 & Linux-x86_64 using gcc 4.9.1 and load games without issue.

#842

I would guess your 4.7.3 toolchain uses structured exception handling and the newer ones are SJLJ. SJLJ is much slower than DW2 EH and SEH (penalising even normal execution when no exceptions are thrown) but it seems to be safer. I’ve read up to 25% slower in code that uses lots of exceptions.

Not sure if that’s the case with bsnes. I’m building everything with SEH except problematic cores. (MAME/MESS/UME x64/x86 and Mednafen x86). Bsnes works fine on the SEH/DW2 builds. And yeah actually buildbot MAME builds are built with 4.9.2-SJLJ and it’s working fine.

#843

Now , I tested 4do with more ISO,I found it should be a compatibility issue, some games work eg. theme park ,the others not.

Great Work! lordashram! Now RA is the first 3do/jaguar emulator for android :lol:

And about the gamepad control…I use the GPD G58,a device like JXD 5800 with SoC rk3188. There must some big change between build 0918 to 1007.It maked custom binds not working.I can detect my keys in RA menu, but They just don’t work in game.

#844

Hello Lordashram

Thank you so much for all the work you do for us !

I’ve the same issue here : None of my gamepads works with the last months releases. It used to work perfectly on your release of early May 2014, with the custom binds (desactivating gamepad auto detection) It doesn’t work either with the 0918 here.

And I cannot desactivate Overlay display !!!

I’ve a TV-box device, with RK3188 chip. My gamepads are pretty old generic USB gamepad from Logitech, Moga, and unknown manufacturer.

Any idea ?

#845

build 0918‘s key binds do works in this way on my g58 but build 1007 wouldn’t …

1.uncheck the autodetection

2.use “custom binds” manually bind your gamepad key

3.check the autodetection

#846

Ok i have tried to run the executable in OpenElec but i am given this error message when trying to launch RetroArch via SSH (im using the PuTTY program)

“error while loading shared libraries: libpulse.so.0: cannot open shared object file: No such file or directory”

This is the steps ive taken…

  1. Unzipped your OpenElec zip file to “/storage/.xbmc/addons/” so the full path read as “/storage/.xbmc/addons/emulator.retroarch/”
  2. In PuTTy typed, “chmod +x /storage/.xbmc/addons/emulator.retroarch/bin/*” 3, and then, “ls -l /storage/.xbmc/addons/emulator.retroarch/bin/”
  3. which reports the following…

“total 5528 -rwxr-xr-x 1 root root 5213316 Nov 14 12:01 retroarch -rwxr-xr-x 1 root root 439742 Nov 14 12:01 retroarch-joyconfig -rwxr-xr-x 1 root root 1268 Nov 14 12:01 retroarch.sh”

  1. and they typed, “/storage/.xbmc/addons/emulator.retroarch/bin/retroarch --config /storage/.xbmc/addons/emulator.retroarch/config/retroarch.cfg --menu”

but after this it then reports the “error while loading shared libraries: libpulse.so.0: cannot open shared object file: No such file or directory” error.

Any suggestions on what the issue maybe?

#847

Hi Lordashram,

Thank you for your amazing work and willingness to do an openelec release of retroarch.

Two things:

  1. Building on BlockABoots post - For Retroarch: If you come past the hurdle of missing pulseaudio dependencies - then the next needed dependency is “libXinerama.so.1” a lib which openelec doesn’t come with either.

  2. I have tested most - if not all - of the cores you compiled, with an older version of the retroarch frontend and they all work flawless and fast on openelec, including ppssp, desmume, snes9x, 4do and mupen64plus.

So the only challenge is to get the frontend working.

But again, thanks and congratulations on your move.

#848

Just popping on to say controls on JXD devices have stopped working too.

Also do you need a bios rom for Videopac emulation? When i launch a game it just closes retroarch

#849

How did you fix the libpulse.so.0 error?, i copied the libpulse.so.0 from zaggash’s repository on sourceforge.com (http://sourceforge.net/projects/zaggxbm … urce=files) from an older build. But when i do that i then get the error message…

error while loading shared libraries: libwayland-client.so.0: cannot open shared object file: No such file or directory

#850

one question: what is the latest test build that works out of the box with the Nvidia Shield Portable?

#851

RetroArch-2014-11-14 OpenElec-x86_64: Updated: RetroArch[188265f], Mupen64plus[a33ea43]

NOTE: UME 2014 based on MAME-SVN r33370

#852

@AndresSM/Radius, thanks for the info that was exactly what was wrong, I recompiled bSNES using gcc 4.9.2_SEH and it works correctly now. It’s a big shame about MAME though as that it is another one of those cores that would really benefit from SEH.

@7rtype, I tested out your latest test version of Hatari 1.8 and it compiled just fine with MinGW-w64 gcc 4.9.2_SEH and I played around with a few games with no issue other that the Hatari core still want’s tos.img in the same folder as the retroarch executable instead of the system folder.

@OpenElec users, I added more dependencies, if it is still crashing with a dependency error, do this from a terminal

ldd /storage/.xbmc/addons/emulator.retroarch/bin/retroarch >  /storage/radeps.log

and post here the contents of radeps.log so I can see what else is missing with OpenElec.

@Android users, I haven’t unpacked my PS3 yet so I will as soon as I can so I can bluetooth the control to my phone and see what I can as we will need more info before posting an issue to the devs on git hub. The only big change I can think off is that I had started to include the autoconfig files for RA. I don’t have any of these types of issues with the Win64 nor the Linux-x86_64 port.

#853

Yeah sadly I have no idea on how to fix that… I managed to get it to build and work with SEH by forcing FIBER for libco but I don’t know if that’s good, FIBER is the MSVC exception handling model. I think a better solution would be if someone updated libco to support SEH.

EDIT: Or maybe you could give that SEH experiment a shot, just replace libco.c in libretro-sdk/libco/ with the contents of fiber.c and see if you have better performance, I got that to work but I didn’t do extensive benchmarking

#854

Ok im getting the error message

“error while loading shared libraries: libXxf86vm.so.1: cannot open shared object file: No such file or directory”

now.

Heres the log file as you requested…

http://pastebin.com/sZQL3jXr

#855

[quote=“BlockABoots”]

Ok im getting the error message

“error while loading shared libraries: libXxf86vm.so.1: cannot open shared object file: No such file or directory”

now.

Heres the log file as you requested (had to zip it up as i cant attach a log file)[/quote]

I’m thinking you might get better luck building on your own than resolving all those missing dependencies, and in the process you could provide an openelec package…

Just saying though…

EDIT: nevermind that, it seems to be quite a hassle to build stuff for openelec… to get fully working packages without dependency hell would mean to build a complete openelec image…

After reading this I see little benefit of using OpenElec over XBMCbuntu. With XBMCbuntu you can install steam, use home streaming, play linux games, play wine games, probably you can use netflix and other silverlight based stuff. I’m finding this Openelec thing quite limiting

#856

Im rather new to linux based media system, but it seemed when i was looking at what variation of xbmc OS to install, veryone seems to recommend OpenElec, seems to have minor install footprint, super fast boot time (like 3-5 seconds) be the best supported and with a large community…

http://openelec.tv/forum

The only down side as you pointed out was its a bugger to complie stuff for

But zaggash complied a build for openelec, http://sourceforge.net/projects/zaggxbm … urce=files

Only problem is its a few months old now, and alot of the new features/shaders/options are not supported

#857

Hello again, Lordashram, amazing job - so close just a few missing here now :slight_smile:

Output of ldd /storage/.xbmc/addons/emulator.retroarch/bin/retroarch > /storage/radeps.log here: http://pastebin.com/raw.php?i=6uetqqfn

Thanks!

#858

Yeah sadly I have no idea on how to fix that… I managed to get it to build and work with SEH by forcing FIBER for libco but I don’t know if that’s good, FIBER is the MSVC exception handling model. I think a better solution would be if someone updated libco to support SEH.

EDIT: Or maybe you could give that SEH experiment a shot, just replace libco.c in libretro-sdk/libco/ with the contents of fiber.c and see if you have better performance, I got that to work but I didn’t do extensive benchmarking[/quote]

for what i know , and read from byuu’s , fibers is 40% slowers than X86 asm one . so not sure it will be faster than the 20% slower of sjlj toolchain.

but agree it will be cool if we can get ride of the sjlj requirement in mame.

@Lordashram Ok thanks for reporting , i haven’t build 1.8 in windows. so good to here it works, the normal behavior is to try to load conf (hatari.cfg) from system directory first then load tos.img in current dir.

i will try to solve the load from tos.img in system directory first not current dir. for now trying to fix some android segfault.

#859

Are you using OpenElec as well magnoliafan?? Just that in my log file i have the following missing but in your log file they are not listed as missing…

libXxf86vm.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libXxf86vm.so.1 (0x00007f7e0a937000) libXv.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libXv.so.1 (0x00007f7e0a479000) libxcb.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libxcb.so.1 (0x00007f7e08037000) libsndfile.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libsndfile.so.1 (0x00007f7e07fdf000)

but then you have a bunch of other entries that i dont have in my list at all?

I dont know much about Openelec and the compling process of RetroArch but why are there differences for both of us if were both using OpenElec…is it down to the difference hardware we have?? (im using a Gigabyte Brix device)

#860

Are you using OpenElec as well magnoliafan?? Just that in my log file i have the following missing but in your log file they are not listed as missing…

libXxf86vm.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libXxf86vm.so.1 (0x00007f7e0a937000) libXv.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libXv.so.1 (0x00007f7e0a479000) libxcb.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libxcb.so.1 (0x00007f7e08037000) libsndfile.so.1 => /storage/.xbmc/addons/emulator.retroarch/lib/libsndfile.so.1 (0x00007f7e07fdf000)

but then you have a bunch of other entries that i dont have in my list at all?

I dont know much about Openelec and the compling process of RetroArch but why are there differences for both of us if were both using OpenElec…is it down to the difference hardware we have?? (im using a Gigabyte Brix device)[/quote]

Hi Blockab,

(nice to see communicate with you here as well)

I’m using OpenElec Stable Version: 4.2.1 // Generic x86_64
You are completely right in your observation, the reason I have some of those libraries is that I’ve never cleaned out that directory (emulator.retroarch/lib/) across all my various retroarch installations and experiments - so some libs are old remnants. Ergo, LordAshram should really rely on your output to include the dependencies. I have no idea why your log does not show the last 6 lines that mine shows, I’m thinking maybe yours was truncated?

(notably messing from blockaboots log) libXau.so.6 => /storage/.xbmc/addons/emulator.retroarch/lib/libXau.so.6 (0x00007f7e07bc4000) libXdmcp.so.6 => /storage/.xbmc/addons/emulator.retroarch/lib/libXdmcp.so.6 (0x00007f7e079bf000) libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007f7e07998000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f7e078e6000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f7e078bf000) libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f7e078b8000)