Version 2.0 Release Candidates

[Paul]

Posted Release Candidate 5.  The main reason I posted another build so quickly, is because I built the OUYA components into this one and I want to make sure that doesn't break the app for anyone (hoping not to need a separate branch in the repository for the OUYA port).  There shouldn't be any effect except to be a slightly larger APK file.  Littleguy fixed up the cheats menu in this build as well, so be sure to test that part out too.

[chery2k]

Hi I have the xperia play and I have a problem with the touchpads (enabled). The issues is when either the left or right side of the touchpad is programmed to take control of the c-button (yellow buttons) it would become unstable. ( Mupen64 was emulating the c-button perfectly after the 5 mins after that it went kaput). Meaning If I were to play Starfox with the c-buttons on either side of the touchpad it would force my ship to use boost or use the brakes repeatedly and it keeps on going. (I no longer have control of the c-buttons on the touchpad it wont allow me to do anything else). But for some reason when I was using the opposite touchpad to move the joystick it is very accurate and responsive to move my ship around. (No hiccups). Note* I used both of the touchpads on the test above.

I noticed during my testing if I just use c-button touchpad (no joystick this time) the same situation happens above even with a fresh install of mupen64.

[zack]

Just pushed in some Makefile CFlags optimisations.
From testing it seems to have resulted in a small speed improvement.

[littleguy]

Hi I have the xperia play and I have a problem with the touchpads (enabled). The issues is when either the left or right side of the touchpad is programmed to take control of the c-button (yellow buttons) it would become unstable. ( Mupen64 was emulating the c-button perfectly after the 5 mins after that it went kaput). Meaning If I were to play Starfox with the c-buttons on either side of the touchpad it would force my ship to use boost or use the brakes repeatedly and it keeps on going. (I no longer have control of the c-buttons on the touchpad it wont allow me to do anything else). But for some reason when I was using the opposite touchpad to move the joystick it is very accurate and responsive to move my ship around. (No hiccups). Note* I used both of the touchpads on the test above.

I noticed during my testing if I just use c-button touchpad (no joystick this time) the same situation happens above even with a fresh install of mupen64.

I can't seem to replicate this behavior on my stock Verizon Xperia PLAY.  Just to clarify, you tried both layouts for the touchpad?  So when the c-buttons were on the left pad they were unusable, and when the c-buttons were on the right pad they were also unusable?  Or is it your right pad that is messed up, whether it's the c-buttons or the analog stick mapped to the right pad?

Not sure what you mean in your second paragraph.

[chery2k]

Correct. I am using stock 2.3.4 R800i gingerbread firmware. Yes I tried both layouts for the touchpads. When the c-buttons were setup either left or right touchpads they become unusable after 5 minutes. The emulator correctly emulated the c-buttons before that 5 minute time period. Idk know if this maybe an issue but I am using a Sandisk class 6 sd card there might be a lag or response time between the xperia play and the sd card in terms of communication. Which might explain my sudden slow up or boost in Starfox.

The touchpad that was emulating the n64 joystick is working 100% either side it was emulated on the touchpad.

[littleguy]

Ok, thanks, now I understand what you're saying.  I wonder if it's a Starfox issue or if it's a Mupen issue.  Do you get the same problem when you run a different game?

[chery2k]

Update: Just as I feared it seems the tests I did above my perception has changed. I remapped the c-buttons (all 4) to my xperia play physicals buttons: triangle, square, x, and circle. I get the same result above on starfox never ending braking and sudden acceleration. I guess Mupen has problems emulating the c-buttons alone proving my touchpad problem is farce.

[maalox]

So my Sixaxis Controllers are not behaving well anymore. In the previous test builds, they were both mapable and usable, but now there's a problem on Release Candidate 5 (not sure when the problem first started):

I have 2 controllers connected via the Sixaxis Controller app.
If I enable only player 1's controller in Mupen, then that controller works just fine. However, the second controller still works as a duplicate of the first controller (i.e. both controllers control player 1).

If I enable player 1 AND player 2's controllers in MuPen, I am able to use either controller to map buttons in the settings page. Also note that the controllers are recognized differently in the multiplayer mapping page under the Play menu (one of them is identified as "Device 11 (Gamepad 0)", and the other is identified as "Device 12 (Gamepad 1)". HOWEVER, neither controller works while playing a game. This is true whether I map none, one, or both controllers in the Multiplayer mapping page prior to starting the game.

[littleguy]

So my Sixaxis Controllers are not behaving well anymore. In the previous test builds, they were both mapable and usable, but now there's a problem on Release Candidate 5 (not sure when the problem first started):
...
HOWEVER, neither controller works while playing a game. This is true whether I map none, one, or both controllers in the Multiplayer mapping page prior to starting the game.

This one sounds just like what I observed a few posts back.

Argh.  I'm implementing the option to allow multiple players to share a single keyboard/controller (issue 24, an easy fix) and suddenly realized multiplayer isn't working properly.  Doing a git-bisect right now to fix it.

Edit: Nevermind.  Another case of needed-to-clean-before-build.

Paul - Is it possible that RC5 wasn't cleaned fully before it was built?  All these controller issues are bewildering me after weeks of stability.

Edit: Just installed the binary from the link above.  Indeed it appears to be a build issue with RC5 since I observe the same issue others have reported.  When I clean build the same commit from source, the problem disappears.

[littleguy]

Update: Just as I feared it seems the tests I did above my perception has changed. I remapped the c-buttons (all 4) to my xperia play physicals buttons: triangle, square, x, and circle. I get the same result above on starfox never ending braking and sudden acceleration. I guess Mupen has problems emulating the c-buttons alone proving my touchpad problem is farce.

There's still a possibility that the problem is with Starfox itself.  Do you observe the same problem when you play a different ROM, say Mario 64?  Just trying to rule out other explanations.

[littleguy]

However, the second controller still works as a duplicate of the first controller (i.e. both controllers control player 1).

If I enable player 1 AND player 2's controllers in MuPen, I am able to use either controller to map buttons in the settings page.

These behaviors are both by design.  In single player mode, controller differentiation is turned off so that you don't need to go through the hassle of assigning gamepads to players in the Play menu.  In the button mapping screen, controller differentiation is turned off for the same reason.  I know that's a little different that what you might find on a PC game, but the Android SDK has a few quirks that we're trying our best to work around.

[Paul]

Indeed it appears to be a build issue with RC5 since I observe the same issue others have reported.  When I clean build the same commit from source, the problem disappears.

Wow, sorry..  I thought I had done a clean build, but I will post another clean build (after doing an ant clean, ndk-build clean, and deleting the libs, obj, gen, and bin folders just to be sure).  Unfortunately I have to stay at work late today to work on a project that's due by the end of the week, so I probably won't be able to post it until later, unless I can find some free time today at some point to build it.

[littleguy]

I reset to RC5 commit and did a clean from android and when I built I got the same problem.  Something more to it than a vanilla clean.  I manually deleted gen/R and am trying it now.

Edit. That didn't do it.  Looking into some other things now.  If the next couple things I try don't fix it, I'll look at the compiler settings that got changed a few RCs ago.  Maybe something got lost.

[littleguy]

Ok Paul, here's what you need to do for the next release to get input back on track.

1. Hard reset to RC 2.a.0 (stash/commit local changes first if necessary)
2. Clean the project and manually delete gen/../R.java just to be safe
3. Build and run
4. Hard reset back to the latest commit (or 2.a.5), clean project, and manually delete R.java again
5. Build and run

That fixes the problem for me, so it's probably something to do with the .cproject changes I made right after RC0.  I'll take a fine tooth comb to that and push a fix today.

In the meantime might be wise to post a notice or something on the first post.

[Paul]

Thanks for tracking that down.  Sorry to sound like a newb, but do you happen to know the command-line git commands to do the stash/commit, hard reset, hard reset, then get my changes back from step 1?  I remember you are using a GUI, so you might not know off hand.  I'll probably have to do a little googling to make sure I don't mess something up.  I really should research a good git GUI for Linux.  I tried one from the Ubuntu software repository (called something like git gui I think), but couldn't do much with it except push pull and commit, which are easy from the command line anyway.