A new version is going to be released this Friday.
I’m pretty confident based on what markezine told me earlier that the ANR issues should be fixed now. It was once again a Google screwup - and by god do they screw up their code a lot.
BTW - sorry to you people on outdated phones with little internal storage but the next release will be even bigger - from 42MB to 48MB (and that is even without the MAME core so expect that size to be even bigger). Desmume / Stella / QuickNES / SNES9x (non-next) and Picodrive are all going in - so that explains the size increase.
If you don’t like this - take the official APKs - delete whatever cores you don’t want - then save the apk - dunno if that could be done but the only way it’s going to get smaller at this point is by you removing cores you don’t want/need.
In my opinion - it is better that extra space is going towards stuff that actually is part of the program and useful (such as new cores) rather than waste it on stupid HD art assets or something like that.
Square, I was talking with hunterk on the irc channel, isn’t possible to give an option to move the cores to SD card , maybe even giving the option to only download the cores the user is going to use? I think for most people on old devices this can be useful. I don’t know C, but I can help on the java side with this.
None of this code should be done in the C backend code (ie. RetroArch itself), but rather done in the Java frontend.
I think for now if you could just come up with patches to the Java frontend so that you can delete cores at will that could be a good starting point.
Hosting these cores ourselves on some server is going to be impractical I believe from a maintainability perspective (plus server hosting costs).
right… I will research a little more, but I think the way it is right now isn’t possible to delete the cores that are already bundled in the apk. Maybe by making the cores available on the app store as separate modules (just like astro file manager do with the smb and bluetooth modules ) and the retroarch app would redirect the user to the store to download the selected core when a user tries to use that core for the first time.
How is the pc version distributed right now ? Isn’t it hosted ?
We are simply not prepared for a userbase the size of Android’s - no way am I even going to consider distributing Android libretro cores on our servers.
And it’s futile to do this anyway - this is what the Play Store is for - so that it is Google’s problem to host the binaries.
Really, people just need to accept the fact that this app is going to grow as time goes on to be honest - with 16GB of internal storage a 50MB app won’t kill you anyway.
Squarepusher, I checked here, it’s really impossible to delete files inside the app once it’s installed. An easy alternative that I tried is to add android:installLocation=“preferExternal” to the android manifest declaration. This way, all the cores and overlays are installed directly on the external sd card(if the user has one, if not, it’s installed on the internal storage). It’s still possible to the user to move files from the external to the external and vice-versa. Using this, retroarch takes only 750kb of the internal storage. I think this will help a lot the users with outdated devices such as nexus one, and even some new low end that have little internal storage. I don’t know why the version I compiled here is 103mb, maybe I have duplicated my cores accidentaly, but here are the screenshots of the app properties screen with the files on internal and external storage (mine got installed on my external usb hard drive)
EDIT: Found a bug, when you move from a place to another after running the first time the can’t start. I will check if there some var in config that stores with this info.
Sorry if this has been answered a million times, but are L2 and R2 mapped to anything using an Xperia Play on autodetect? I’ve tried mapping them manually but then the menu button stops functioning (despite not mapping the menu button to anything).
I have a new Nexus 7… I’ve run FBA Neo Geo and SNES and so far it runs flawlessly, except whenever I try and enable any shader ( I’m just trying to get scanlines running) I get a black screen… Sound continues… Maybe I’m doing something wrong… but anyways, no audio pops and no frame skip that I’ve seen. If I can get scanlines working, I can probably use RetroArch exclusively.
hello, i have a minor problem with retroarch in all emulator, is impossible for me to play with 2 player ( i have the x-arcade),the touch it’s ok in the input but in game the other player don’t run
Waitin’ for it…only two questions:
- Are you late with the release or in your country is still friday? (No irony, only asking)
- Have you added analog simulation and/or per-core config?
We have added analog support - the Nvidia Shield is the first to support it.
The reason I have delayed it is -
- I want to make sure this leaves a good impression on Shield owners from the word go. So I’ll be looking at some of the issues as they stand right now and trying to figure them out. If it takes too long I’ll just go ahead and release Anyway, next release date (I know I shouldn’t be making these but whatever) will be Wednesday.
- I would like to add analog support for some of the other pads as well - such as PS3 and Xbox 360. So it’d be nice if that could be in 0.9.9.4 as well.
There is no per-core config stuff in yet - however, the threaded video option is much improved. It now has adaptive jittering so the ‘jittering/tearing’ experienced previously with that mode should be nearly unnoticeable now. This mode should give you no audio crackles at all and I think it can compete against whatever autoframeskip method the others use without going the autoframeskip route necessarily.
Also - there are some big improvements such as the ideal samplerate being picked which can lead to increased audio performance - so overall, a lot of significant changes for Android.
I can say that seeing RetroArch running on Shield has left me feeling a bit better about Android and RetroArch’s presence on it - it looks like this thing is at least halfway fixable given another year maybe. However, Google must not slack off and really push forward because it’s still not anywhere way near iOS. So keeping up the pressure on them so that they’ll deliver is the best course of action here. Fortunately, guys like Carmack are now getting the word out as well.
Are shaders working on Android in the next release?
Yeah - in fact, they should already work.
But yeah, they run and on Shield they run great in fact and look great.
If they don’t work on your end it could be that we’re hitting a driver bug somewhere to do with GLSL. Perhaps state which device you’re using.
Awesome… Shaders aren’t working for me on the new Nexus 7, just a black screen with audio, so hopefully they’ll work now… As a 13 year emulator user, I am beyond impressed at how well RetroArch works and performs; I just found out about it and I’m floored. Looking forward to all that is coming… Keep up the excellent work!
Hmm, problem is that we don’t have a Nexus 7 2013 and that this one is running Android 4.3 with GLES3 support, so who knows what all changed under the hood GL-wise.
The Shield is running 4.2.1 and the GPU is GLES2-class with extensions, so that’s why it probably works fine and the same issue doesn’t happen over here. Anyway, this is all speculation.
If it helps, shaders don’t work on my Nexus 4 either…
Well, hopefully you can sort it out soon.
Hi Squarepusher,
Whenever I’m playing a game on my Nexus 4 with RetroArch (so far I’ve only tried the Genesis Plus GX core) it plays perfectly, with no lag or anything, but if I stop playing and don’t touch the screen or any of the buttons, about 7 seconds later the audio and video will become choppy and slow. It’s as if the device is trying to save energy by assuming I’m not using it because I haven’t given it any input in the last few seconds, and decreases performance or something. If I tap the screen once, the game plays great again - for the next 7 seconds or so.
I know this is obviously an issue with Android - I’m running 4.3, but I was wondering if you knew of any fixes for this. If I turn on the threaded video driver option in settings the problem seems to disappear, but the game doesn’t run quite as perfectly as it does with this off. Forgive me if this is already a known issue, or has previously been solved, I did try lurking first! But maybe not hard enough.
Either way, I downloaded this last night, and I’m loving it!
The shader issue appears to be device/gpu-specific, rather than Android or RetroArch version-specific. I dug out my old phone (Samsung Galaxy S, PowerVR SGX 540 GPU), which had an older version of RetroArch installed (0.9.8.4) and shaders ran fine on it. They also ran fine when I updated it to the latest version from the Play store (while I was there, I noticed that we’ve passed the 100k downloads mark, with a star rating of ~4.5, so kudos all around). On my HTC One (adreno 320 GPU), shaders didn’t work with the latest version, so I tracked down a v0.9.8.4 apk and shaders were broken there, as well.
Both phones are running CM10.1 (Android 4.2), so I don’t suspect it’s directly Android’s fault for once.
So, the good news is that there hasn’t been any sort of regression or anything, AFAICT. The bad news is that there seems to be a device/gpu/driver-specific bug lurking that will likely be difficult to track down.
Well unfortunately I can’t test on a Nexus 4 so I can’t really tell you what is going on there. Sounds like a case of over-aggressive and wrongheaded power management policies if I had to guess.
We will require more hardware support to be able to get to the bottom of all these issues. Nvidia was generous enough to gift this Shield device - let’s hope other parties will follow in their wake so that we can start ironing out all the numerous issues on [insert random device here]. Over 80% of the work of Android development seems to be nailing down all these device-specific issues.