Beta Testing Has Begun!

[max.esparza]

hey paul how are you doing? i installed mupen64 2 weeks ago and evereything was perfect but now when i choose a game it doesn't open and then i have that io error , i hope you can help me.

[littleguy]

Max - Try running the latest release candidate here, and if you have bugs, post them on that thread or here.

[Paul]

I published the donation version on Google Play.  Due to some changes with the preferences files, it is difficult to change the app package name, and requires some tedious testing since numerous source files must be changed.  Because of this, I didn't have time to get the free version published, or the SlideMe version updated.  I'll work on publishing those during the next couple of days.  The APK is also posted in the first post of this thread, for anyone who doesn't use Google's store.

[littleguy]

Did the little index bugfix make it in?  Just want to be sure I tag the right one.

What are the package names for the two published versions?  Just curious...

[Paul]

Sorry, forgot to update the OP last night.  Yes the published app is from commit f886f16bac with the bugfix.  Only difference is the app version string (changed it to 2.0.0) and the package name (changed it to paulscode.android.mupen64plus).  The free version, which I'll try and publish tonight, uses the package name paulscode.android.mupen64plus.free.  I'll send Trev a PM to see if he'll unpublish his branch, so folks don't get confused by all the apps with the same name.

[littleguy]

Cool.  Was thinking we could make a tiny branch from tag 1.9.2, update it to 1.9.3 and add an immediate popup in MainActivity that says "new version available" with the market link to 2.0.0.  Or something to that effect.  Not sure what your workflow is with trev, how hard that would be to do.  My main concern is people not finding the new version, or not even being aware that it exists.  I'm thinking of the user that installed 1.9.2 months ago and kind of put it aside since it didn't have some feature that it now has (like analog , device, or game support).  Imagining that person seeing an update notification for 1.9.3 and thinking "hey maybe they fixed it!" and rush to try it out.  Then they see the 2.0 version and they live happily ever after. 

BTW when I search "mupen" on google play, I don't get the new version, just trev's.  If I search "mupen64" I get both.

[littleguy]

I'll make a commit to update the string to 2.0.0 and tag that, just so that the tag accurately reflects the market version.  If that screws you up, feel free to roll it back with git push -f origin HEAD^:master

Regarding the package name change, is that a one-off thing you do every time you publish, or do you intend to change it permanently in the repo?

[Paul]

That should be fine.  I'll update the OP to point to your commit with the version string fix.

I didn't even try to commit the changes I made due to the massive package renaming that had to be done first in order to publish.  Thankfully, I came up with a single command-line call that turns every instance of "mupen64plusae" into "mupen64plus" recursively.  Going from "mupen64plusae" to "mupen64plus.free" or "mupen64plus_free" depending on the context will be a bit trickier.  I'm going to see if I can write a semi-intelligent script to do the work for me.

Getting an update published to Trev's branch is not currently possible, due to his digital signature being on my computer in storage (he's not a developer himself, so I was building and signing the app for him to publish on his account)  I should be moving into our new home in a week or two though, so when I do, I can have Trev re-publish for a few weeks with an updated "1.9.3" version with a popup message like you said.  Hell, we could even publish 2.x with a popup, for that matter (although not upgrading might entice folks to switch sooner )  In the mean time, I think it will be best to unpublish his branch until we are able to push the message out to folks, just to avoid confusion.

[Paul]

Regarding the package name change, is that a one-off thing you do every time you publish, or do you intend to change it permanently in the repo?

I won't change it in the repo, since honestly I could be taken down from the market again tomorrow.  I'll just write scripts to make the renaming a simple process, and keep the repo as it is.

[littleguy]

Yeah, that's what I gathered.  Nice thing is I can have the market versions installed alongside my dev builds.  Handy for testing fixes.

[Paul]

Going from "mupen64plusae" to "mupen64plus.free" or "mupen64plus_free" depending on the context will be a bit trickier.

Come to think of it, this is really simple as well.  I should be able to do this in three steps:

1) Convert ".mupen64plusae" to ".mupen64plus.free" recursively
2) Convert "_mupen64plusae" to "_mupen64plus_free" recursively
2) Convert "/mupen64plusae" to "/mupen64plus/free" recursively

[Skidrash]

Sorry for the incredibly late reply but I've been out of town for a while. I got to try the latest version and I'm still having some problems with Nyko controller. I tried littleguys sugestion to waggle the analog sticks before running the application but it still has trouble... What I'm seeing is all of the discrete buttons work fine but as soon as I touch any of the analog sticks the -Y is stuck on.  As soon as I touch a discrete button again the -Y disappears. I checked the controller Diagnostics page and it shows all of the analog sticks actuating properly through they're full spectrum. They don't get stuck at all on the diagnostics page, and all fully return to 0. But when I'm in the controller map page it always sticks with a -Y.

Again, sorry about the late response. I'd be happy to try something else or give more detail if you would like.

[littleguy]

I got my hands on one of these controllers today.  I know how to fix it, it's mostly just a UI issue.  The smaller Playpad is pretty vanilla actually.  The Playpad Pro has a quirk that might require a little extra finesse.  But the main issue is just trying to support so many different controller quirks without making the user go through a major setup process... which is also a PITA for devs to maintain as more controllers hit the market.  The main issue I'm running against is the xbox controllers and ps3 wired controllers, which each bias their analog triggers to -1, which really screws things up.  I would probably let it go if it weren't for the fact that a very large fraction of users will be be using one of those controllers.  I'll probably have something in the next week, I just want to step carefully so I can keep as clean a solution as possible, for both the user and the devs.  I'm open to any suggestions.

[Infinite Jest]

Hey guys!  I downloaded the donation version from the Play store today after having no emulators on my phone for a while (been between phones; Verizon 'certified like-new' my ass).  I recently switched from the Galaxy S3 to the HTC Droid DNA and noticed that it doesn't run particularly well on my DNA (2.0).  A bit too choppy in most games compared to the S3 (US version) and the sound likes to skip a lot.  Just thought I;d report in.  Otherwise, the GUI improvements and under-the-hood enhancements are looking great!  Hopefully I can get it smoothed out on my DNA.

[Skidrash]

I imagine it can be quite a nightmare trying to support everything... But I think I'm safe in saying that we all appreciate your hard work!

As for suggestions, I thought the calibration button worked pretty well in the earlier versions. Beyond that, I got nothing...