PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: Paul on January 07, 2013, 09:50:14 PM

Title: Version 2.0 Release Candidates
Post by: Paul on January 07, 2013, 09:50:14 PM
Release Candidate stress testing has begun!

Most of what we wanted to get hooked up before publishing has been done.  Some things may have been broken along the way, so we need everyone to do stress tests to identify everything that has been broken.  Once everything major has been fixed, I'll publish the update on Google Play!


APK Links:

Release Candidate 6 (http://www.paulscode.com/source/Mupen64Plus-AE/14JAN2013/Mupen64Plus.apk) (commit #00380eb2a5) (https://github.com/paulscode/mupen64plus-ae/commit/00380eb2a5694a5cddda1cd53b228778fe74420e)


Notes:

Testers can help by:
1) Reporting bugs here (https://github.com/paulscode/mupen64plus-ae/issues?sort=created&state=open) (accessible from the Help menu on the main screen)
2) Enabling crash reporting in the Advanced menu

For controller issues, testers should
1) Use the diagnostics screen in the Advanced menu
2) Report their observations in a bug report

If any of you have one of the snapshot builds installed, you MUST:
1) Reset to the default settings after updating
2) Rename the gamesave folder to 'mupen64plus' (if you've been using the default)
    (or update the gamesave location in the Advanced menu as necessary)


If you know a second language, we need translators!

Please register a translator account and submit translations at the Transifex project (https://www.transifex.com/projects/p/mupen64plus-ae/).
Current translation progress (click your browser's "refresh" button to update):





Functions from version 1.9.2 not yet hooked up in 2.0

- Frame Advance function
- Gameshark button


Identified Broken Functionality to Look at Before Publishing:

Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 07, 2013, 09:53:26 PM
Change Log:
Version number can be found in the app's About menu

2.a.6
 + Bugfixes
    - Fixed the broken multi-player bug introduced in 2.a.2
    - Fixed various crashes discovered by the crash report system
 + Enhancements
    - Cheats can be disabled entirely to speed up menu load time
    - Translations updated
    - Flicker-reduction optimizations for Henag Lazer
    - A few compiler optimizations, might have improved speed a bit
 + Changes
    - Temporarily removed Gameshark and Frame Advance buttons until those features are ready

2.a.5
 + Enhancements
    - All cheat options are now persistent
 + Changes
    - Added OUYA-specific components

2.a.4
 + Enhancements
    - Added option to share controller between multiple players (needed for N64-USB adapter)
    - Added option to manually specify the flicker-reduction profile in the Video menu

2.a.3
 + Bugfixes
    - Fixed force-close bug on launch for Xperia PLAY
    - Multiplayer setup dialog retains state on rotation

2.a.2
 + Bugfixes
    - Fixed bug where game would close on launch if cheats database weren't finished building
    - Cheats menu refreshes properly and slightly faster
    - Boolean (on/off) cheat settings are persistent
       (persistent multi-choice cheat settings coming soon)
 + Enhancements
    - Portuguese translation
    - Tweaks to touchscreen transparency slider behavior
 + Changes
    - Updated link to Credits in the About dialog
    - Removed Hide buttons option in Touchscreen menu (redundant)

2.a.1
 + Bugfixes
    - Fixed RSP-related loading issues on certain devices
    - Video menu refreshes properly after plugin is changed
 + Enhancements
    - Translations for Croatian, French, German*, Russian*, Spanish
       (* partial)
    - Transparency option for touchscreen overlays
 + Changes
    - Changed some compiler settings; might fix some FC issues on certain devices
    - Corrected name to Mupen64Plus AE
    - Removed some obsolete data files
    - Added link to this change log in the About menu

2.a.0
Initial release candidate.  Changes from final snapshot build:
 + Bugfixes
    - Hooked up most of the missing special functions
    - Multiplayer works even if Player 1 uses touchscreen but no controller
 + Enhancements
    - Overhauled multi-player control mapping, now in the Play menu
    - Added confirmation dialog before resetting from Play menu
    - Added in-game menu item for changing IME on the fly
    - Added option to hide touchscreen overlay buttons
    - Added menu item to migrate slot saves from version 1.9.2 to 2.x
        (you can have both installed at once)
    - Added diagnostics screen to help debug controller issues
    - Updated the Help and About menus, more informative now
    - Integrated new crash reporting back-end for greater manageability
 + Changes
    - Moved default save directory to <sdcard>/mupen64plus
    - Removed reset function from in-game menu (now redundant)
    - Internally reorganized a lot of string resources to improve maintenance/translation
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 07, 2013, 10:47:47 PM
Posted link to Release Candidate 0.  I know there have been pieces identified as broken during the snapshot build series.  Please identify all of these problems here.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 07, 2013, 11:20:40 PM
I need to write the credits page, and link the app's credits button to it.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 07, 2013, 11:24:08 PM
Changing video plugin has stopped resetting the video settings page.
Title: Re: Version 2.0 Release Candidates
Post by: k0en on January 08, 2013, 03:39:26 AM
i'v just writting a news here : http://www.open-consoles-news.com/2013/01/la-version-20-rc-de-mupen64plus-ae-est.html for the french Open-consoles community.

Title: Re: Version 2.0 Release Candidates
Post by: DarkMatterCore on January 08, 2013, 11:41:50 AM
I'd like to help translating this project to Spanish. I already requested access in the Transifex page.

I'm from Venezuela.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 08, 2013, 11:42:37 AM
I approved you.  Thanks for the help!
Title: Re: Version 2.0 Release Candidates
Post by: arrtoodeetoo on January 08, 2013, 01:30:20 PM
Very cool!

Do you have a list of things that were changed since the Jan 3 build? That would help in knowing what to look for while testing.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 08, 2013, 02:01:20 PM
Good idea.  I'll add it to the changelog in the second post
Title: Re: Version 2.0 Release Candidates
Post by: DarkMatterCore on January 08, 2013, 02:02:51 PM
Almost done. :)

I just have a little question I hope you can answer, before submitting the whole 263 entries. Do the "Sinc" resampling modes stand for "Synchronous"? I want to translate that as accurately as possible.
Title: Re: Version 2.0 Release Candidates
Post by: xperia64 on January 08, 2013, 02:07:35 PM
Tested on an original motorola droid and it works pretty well @800MHz. One issue, if you change the video plugin from gles2rice to gles2n64, the options for gles2n64 don't appear until the app is restarted.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 08, 2013, 02:27:40 PM
Almost done. :)

I just have a little question I hope you can answer, before submitting the whole 263 entries. Do the "Sinc" resampling modes stand for "Synchronous"? I want to translate that as accurately as possible.

Awesome!  I believe it stands for the mathematical sinc function (http://en.wikipedia.org/wiki/Sinc_function), so it shouldn't be translated.

A note to all translators: If you're ever in doubt, look at the Japanese translation and see if the word was translated there.  Lioncash created the Japanese translation and has been maintaining it for many months now.  In case you didn't know, he's also one of the devs and has been intimately involved with the project for a long time.  (He in fact created the string you mention.)

Tested on an original motorola droid and it works pretty well @800MHz. One issue, if you change the video plugin from gles2rice to gles2n64, the options for gles2n64 don't appear until the app is restarted.

Yep, you can also fix it by rotating your screen once and back.  It's already fixed for the next RC.
Title: Re: Version 2.0 Release Candidates
Post by: DarkMatterCore on January 08, 2013, 02:54:25 PM
Awesome!  I believe it stands for the mathematical sinc function (http://en.wikipedia.org/wiki/Sinc_function), so it shouldn't be translated.

A note to all translators: If you're ever in doubt, look at the Japanese translation and see if the word was translated there.  Lioncash created the Japanese translation and has been maintaining it for many months now.  In case you didn't know, he's also one of the devs and has been intimately involved with the project for a long time.  (He in fact created the string you mention.)

Done! Thanks for the help.

I'll check this forum regularly in case there is any update to the language strings. Hope you like this small contribution.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 08, 2013, 02:58:37 PM
Thank YOU!

This is the first time we've used Transifex, but there might be a way for it to automatically notify you when the English strings change.  I think you can click on the English "resource" on their website and click "watch" or something.  That might help...
Title: Re: Version 2.0 Release Candidates
Post by: Sowden on January 08, 2013, 04:07:58 PM
The N64 adapter works guys, thank you so much!  First player works great with it, so I thought a video of it working wasn't necessary ;-)  I only have one bug that I will post on the github cause I think its a problem that can be fixed later on.  Thanks again, later.
Title: Re: Version 2.0 Release Candidates
Post by: MaXiMu on January 08, 2013, 04:54:56 PM

Rsp-hle.so unable to load is broken for now?
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 08, 2013, 04:57:40 PM

Rsp-hle.so unable to load is broken for now?

I have that problem with the Kindle Fire HD.  I thought it was related to it being non-vanilla Android, but I better bump up the priority on that if there are other devices affected.  Does rsp-hle-nosound.so work?
Title: Re: Version 2.0 Release Candidates
Post by: MaXiMu on January 08, 2013, 05:10:38 PM


I have that problem with the Kindle Fire HD.  I thought it was related to it being non-vanilla Android, but I better bump up the priority on that if there are other devices affected.  Does rsp-hle-nosound.so work?

rsp-hle-nosound.so load wihout error present only problem with rsp-hle.so .

For more information device problem Samsung galaxy tab 2 with ics 4.0.3.

Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 08, 2013, 05:14:08 PM
Yep, some change from upstream caused a problem on Android.  Sven didn't update rsp-hle-nosound, so that's why it works.
Title: Re: Version 2.0 Release Candidates
Post by: xperia64 on January 08, 2013, 05:20:48 PM
Just tried Banjo-Tooie yet again on my xperia play and I have to say it is *this* close to being perfect. It went through over 10 scene changes (more than ever) before it finally crashed. The new savestate menu is much faster as well allowing me to save often to ensure I don't lose my progress.
Gfx Plugin:
gles2rice
Frameskip Enabled
Fast CRC Enabled
Fast Texture Enabled
No HiRes textures.
Title: Re: Version 2.0 Release Candidates
Post by: RogerSmith on January 08, 2013, 11:38:46 PM
Upon starting the new 2.0 candidate build, the default ROM path is set as /mnt/SD/ROMS/n64, which is internal memory. mnt/SD/external1 is considered the actual SD card itself. So anyway I plugged into PC and set M64 there and now it loads and plays like normal. I'm too scared to attempt to load a rom from the actual external SD card for fear of mupen not loading like it did to me before.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 08, 2013, 11:46:33 PM
We are using standard Android calls to get the so-called "external" storage directory.
http://developer.android.com/reference/android/os/Environment.html#getExternalStorageDirectory%28%29

This seems to be recommended practice for Android development, so the app isn't doing anything unusual.  We do understand that people have different needs, which is why we include the option to change the directory.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 08, 2013, 11:55:12 PM
I wish I knew why it had that problem in the first place, but glad to hear it is working finally for whatever reason  :o
Title: Re: Version 2.0 Release Candidates
Post by: RogerSmith on January 09, 2013, 12:07:42 AM
I wish I knew as well. Other emulators didn't have that problem. The SNES and Genesis emulators are able to read ROMS from the external SD card. And the craziest part is that mupen started having issues reading folder locations just out of the blue.
Title: Re: Version 2.0 Release Candidates
Post by: Sarkie on January 09, 2013, 04:44:34 AM
You have a Xoom?

http://code.google.com/p/android/issues/detail?id=18501

Can you not just change the path in the app to point to /mnt/external1 ?

Do you have a /removable or /mnt/removable path?

Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 09, 2013, 05:47:35 AM
@RogerSmith - I may have misinterpreted your post.  Are you asking a question, or identifying a bug?  Did this just appear with the RC or was it in the snapshot builds as well?
Title: Re: Version 2.0 Release Candidates
Post by: Skidrash on January 09, 2013, 06:24:01 AM
I checked the Nyko controller on the RC and it is looking promising.  I am seeing an AXIS, instead of an AXIS_HAT with the analoge stick.  However, as soon as I hit any of the analoge sticks or buttons I get a constant AXIS_Y(-) from that time forward (with the exception of down on the left stick... That gives a momentary AXIS_X(-)  Eveyrthing else stays AXIS_Y(-) until I hit a discrete button). 

I'm thinking I need to calibrate the analoge controls, but I can't seem to find the Calibration button anymore...? Any thoughts?
Title: Re: Version 2.0 Release Candidates
Post by: shuy3n on January 09, 2013, 06:40:36 AM
Think i found a bug I cant recreate it until i get home though,

I set my roms path within the app - mnt/EXtsdcard/Roms
Decided to wipe my sdcard which deleted the folder it was pointing to
then couldnt go back up a level from with the file browser

maybe just a one off ,but is there any way it can detect folder no longer exists and fall back to the root
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 09, 2013, 07:18:38 AM
maybe just a one off ,but is there any way it can detect folder no longer exists and fall back to the root
Actually that's exactly what it's supposed to do.  Let me look into that piece of code to see if something changed.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 09, 2013, 07:27:39 AM
I checked the Nyko controller on the RC and it is looking promising.  I am seeing an AXIS, instead of an AXIS_HAT with the analoge stick.  However, as soon as I hit any of the analoge sticks or buttons I get a constant AXIS_Y(-) from that time forward (with the exception of down on the left stick... That gives a momentary AXIS_X(-)  Eveyrthing else stays AXIS_Y(-) until I hit a discrete button). 

I'm thinking I need to calibrate the analoge controls, but I can't seem to find the Calibration button anymore...? Any thoughts?

Thanks for the update.  The calibrate button was removed since it was a band-aid for something else that is now addressed differently (though perhaps not perfectly).

I have a couple suggestions, please let me know what you observe.
 1. Quit the app, wiggle all the analog sticks, buttons, and triggers, then start the app again.  Then when you get to the mapping screen, use slow movements when mapping any analog axes.  Let me know if that fixes the stuck y-
 2. Open the controller diagnostics screen under the advanced menu.  Experiment with the different buttons and sticks and report what you observe. In particular, see if the y-axis gets stuck on that screen.
Title: Re: Version 2.0 Release Candidates
Post by: RogerSmith on January 09, 2013, 03:51:29 PM
@RogerSmith - I may have misinterpreted your post.  Are you asking a question, or identifying a bug?  Did this just appear with the RC or was it in the snapshot builds as well?

I was referring to the earlier issue I had with the last snapshot build. Like I said, placing the roms in the predestined folder is working at the moment.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 09, 2013, 11:00:39 PM
Uploaded Release Candidate 1.  Most of the items on the list of broken functionality have been fixed.  Littleguy is improving the cheats menu (should be fixed in the next release candidate), and I'll work on the credits page.

There will probably be only one or two more release candidates to test the cheats menu before I publish this weekend or early next week, so be sure to post any serious problems that need to be addressed first.  If anyone is working on a translation, be sure to finish it up before Saturday if you want it to appear in the published version and have your name in the credits when we go live.  I'll likely be publishing some quick follow-on updates throughout the following weeks to address any problems that make it through, so if your translation doesn't make it in Beta 2.0, I'll just include it in a follow-on update.
Title: Re: Version 2.0 Release Candidates
Post by: Catherine on January 10, 2013, 03:34:27 AM
Yep, some change from upstream caused a problem on Android.  Sven didn't update rsp-hle-nosound, so that's why it works.

Ehrm, I think your statement cannot be trusted. Just checked using "git diff 2.a.0:jni/rsp-hle 2.a.0:jni/rsp-hle-nosound" and this is the difference

Code: [Select]
diff --git a/Android.mk b/Android.mk
index 7058769..a79aeb5 100644
--- a/Android.mk
+++ b/Android.mk
@@ -2,7 +2,7 @@ LOCAL_PATH := $(call my-dir)
 
 include $(CLEAR_VARS)
 
-LOCAL_MODULE := rsp-hle
+LOCAL_MODULE := rsp-hle-nosound
 #LOCAL_ARM_MODE := arm
 SRCDIR := $(shell readlink $(LOCAL_PATH)/src)src
 
diff --git a/src/main.c b/src/main.c
index 651ac30..62ec5ff 100644
--- a/src/main.c
+++ b/src/main.c
@@ -146,6 +146,9 @@ static int audio_ucode(OSTask_t *task)
     unsigned int i;
     u32 inst1_idx;
 
+    /* TODO mupen64plus-ae specific hack */
+    return 0;
+
     switch(audio_ucode_detect(task))
     {
     case 1: // mario ucode
Title: Re: Version 2.0 Release Candidates
Post by: BHTGO on January 10, 2013, 04:18:29 AM
There will probably be only one or two more release candidates to test the cheats menu before I publish this weekend or early next week (...) If anyone is working on a translation, be sure to finish it up before Saturday if you want it to appear in the published version and have your name in the credits when we go live.

Please, let us know of this version's final presentation text/credit page/FAQ before you publish so we can go live with a coherent translation experience for the users. :)

Also tested on TF700T with dock/X360 wired pad and no bug/fail to report (both analogs & triggers work just fine!)
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 10, 2013, 06:25:56 AM
Hi, i made a translation to portuguese brazil, i want to upload it and made registration and a language request on transinfex. Never used this site before... How i can upload my translation? It will be included in the emulator?

Sorry for my bad english.  ;D
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 07:24:01 AM
Ehrm, I think your statement cannot be trusted.

That was of course a wild guess as to the cause of the problem before I actually investigated it.  Since the problem started after that commit you referenced, and because it affected rsp-hle only but NOT rsp-hle-nosound (which is different by only a single line of code), that was a perfectly logical conclusion for a starting point for debugging.  Obviously I then looked at the diff and saw that in fact the same changes were made to both and that it was only external unused stuff that was changed.  I clarified this this in both chat and in this thread (http://www.paulscode.com/forum/index.php?topic=769.0), so you're taking something I wrote out of context here a little, aren't you?
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 07:28:44 AM
Please, let us know of this version's final presentation text/credit page/FAQ before you publish so we can go live with a coherent translation experience for the users. :)

These will be threads here on the forum, rather than frames within the app like last time.  The reason for this is because they change too often and it is far to easy to fall out of sync.  The initial post for each of these two threads will be in English, and anyone who wants to translate can just reply with a translation.  I'll have these up this evening (it's next on my to-do list)
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 07:30:06 AM
Hi, i made a translation to portuguese brazil, i want to upload it and made registration and a language request on transinfex. Never used this site before... How i can upload my translation? It will be included in the emulator?

I approved the Portuguese translation team.  You should be able to input your translations now.  Let me know if you have trouble figuring out Transifex.
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 10, 2013, 07:38:07 AM
Hi, i made a translation to portuguese brazil, i want to upload it and made registration and a language request on transinfex. Never used this site before... How i can upload my translation? It will be included in the emulator?

I approved the Portuguese translation team.  You should be able to input your translations now.  Let me know if you have trouble figuring out Transifex.
Thanks, i tried to upload my translation, but i get this error message:
"Upload codec can't decode byte 0xe3 in position 1954"  :(

Edit: Just replaced the line with the original english string, now the file uploaded successfully. The string was: "<string name="toast_sdInaccessible">"  ;D
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 07:46:29 AM
You might have to enter them through the web interface rather than uploading all at once.  I suspect it is sensitive to anything not encoded in UTF 8.
Title: Re: Version 2.0 Release Candidates
Post by: karl_87 on January 10, 2013, 11:08:01 AM
Hi Paul

Emulator works great on my Archos Gamepad, and the buttons seem to map well - good job! but for some reason when I play Zelda - Ocarina of Time, it suffers from massive black flickering backgrounds, if i change the video plugin to the other one, the problems seem to stop but the framerate is so low its unplayable, not sure if this is specific to my device or i haven't got something setup correctly? any ideas? cheers for the work so far
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 10, 2013, 11:36:26 AM
i tested zelda oot today, have some glitches too, the walking path keep flickering in black, tested with both plugins. Also, the sound is choppy  :(

Found a bug, the first time you open the emulator, can't select a Rom. You need to close the emulator and open again, but only first time after you install. I have a Motorola Xoom 2, with 1.2ghz dual core.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 12:07:30 PM
Emulator works great on my Archos Gamepad, and the buttons seem to map well - good job! but for some reason when I play Zelda - Ocarina of Time, it suffers from massive black flickering backgrounds, if i change the video plugin to the other one, the problems seem to stop but the framerate is so low its unplayable, not sure if this is specific to my device or i haven't got something setup correctly? any ideas? cheers for the work so far

I know of a couple settings that can cause flickering in Zelda.  One is Tribuffer Opt, which is currently hardcoded so you can't turn it off at the moment.  The other is Hack Z.  I think it shows up in the gles2n64 video settings as "Depth Test" or something.  You could try checking/ unchecking that option to see if it helps gles2n64.

For gles2rice, you could try enabling Auto Frameskip to help speed it up (generally works for Zelda OOT, but not a lot of other games -- will crash some devices).

Some folks have also reported that using the "Exactly" Frameskip options (gles2n64 video settings), for example "Exactly 1", can greatly improve speed.  Might be worth a try.  Also, it has been reported for some devices that enabling Stretch Screen (both video plug-ins) improves speed a little.  Also see if there is any difference using the framelimiter setting (both plug-ins).  You could really tinker around with all the settings though to see what helps on your particular device.  If you find a good profile of settings, please post them here for other users with similar devices to try.

i tested zelda oot today, have some glitches too, the walking path keep flickering in black, tested with both plugins.
Could you also try the Hack Z setting (called "Depth Test in" in the menu I believe)?  Could you also test Mario 64 and see if the shadows are missing, flickery, or floating way far off the ground?  That could indicate a problem with polygon offset, which can also cause flickering.

Also, the sound is choppy  :(
Choppy sound means slow emulation (for many devices this happens most noticeably during the cutsceens, in the forest with all the fairies, and in the large open-field).   Could you try playing with the settings as well (in particular the Frame Skip options), and report what settings you used if you are able to improve performance?
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 10, 2013, 12:47:45 PM
Ok so i'm getting a crash upon pressing "play".

Game tested Mario 64.
Devices tested on: Xperia Play, Samsung Galaxy S2.

Code: [Select]
e.android.mupen64plusae/error.log, error message: /mnt/sdcard/Android/data/paulscode.android.mupen64plusae/error.log (No such file or directory)
W/dalvikvm(  937): threadid=11: thread exiting with uncaught exception (group=0x2aac8578)
E/ACRA    (  937): ACRA caught a NullPointerException exception for paulscode.android.mupen64plusae. Building report.
D/CustomizationProvider(  850): openFile -- START uri=content://com.sonyericsson.provider.customization/settings/com.sonyericsson.textinput.uxp
I/CustomizationProvider(  850): No configuration file: /system/etc/customization/settings/com/sonyericsson/textinput/uxp/custom_settings.xml
D/dalvikvm(  937): GC_CONCURRENT freed 1716K, 55% free 3460K/7559K, external 4678K/5428K, paused 7ms+13ms
I/ACRA    (  937): READ_LOGS not allowed. ACRA will not include LogCat and DropBox data.
D/ACRA    (  937): Writing crash report file 1357843249000.stacktrace.
D/ACRA    (  937): About to start ReportSenderWorker from #handleException
D/ACRA    (  937): Mark all pending reports as approved.

Sent a crash report also, hopefully it sent :)

This is both on Rc0 and building from source with the latest from github..
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 12:57:51 PM
Game tested Mario 64.
Devices tested on: Xperia Play, Samsung Galaxy S2.

Code: [Select]
e.android.mupen64plusae/error.log, error message: /mnt/sdcard/Android/data/paulscode.android.mupen64plusae/error.log (No such file or directory)
W/dalvikvm(  937): threadid=11: thread exiting with uncaught exception (group=0x2aac8578)
E/ACRA    (  937): ACRA caught a NullPointerException exception for paulscode.android.mupen64plusae. Building report.
D/CustomizationProvider(  850): openFile -- START uri=content://com.sonyericsson.provider.customization/settings/com.sonyericsson.textinput.uxp
I/CustomizationProvider(  850): No configuration file: /system/etc/customization/settings/com/sonyericsson/textinput/uxp/custom_settings.xml
D/dalvikvm(  937): GC_CONCURRENT freed 1716K, 55% free 3460K/7559K, external 4678K/5428K, paused 7ms+13ms
I/ACRA    (  937): READ_LOGS not allowed. ACRA will not include LogCat and DropBox data.
D/ACRA    (  937): Writing crash report file 1357843249000.stacktrace.
D/ACRA    (  937): About to start ReportSenderWorker from #handleException
D/ACRA    (  937): Mark all pending reports as approved.

A couple interesting things about that crash.  Firstly, the obvious error is that error.log doesn't exist.  That should be a simple fix, I would think, unless there is something weird going on with the paths.  Secondly, there is the question of why it was trying to access the error log.  This Probably means there was another problem that it was trying to log but wasn't able to.  We'll most likely have to fix the first problem before we'll be able to solve the second one.

Does the problem happen when the cheats options have been loaded into the menu, or before (or both?)
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 10, 2013, 01:19:13 PM
Yup, odd.

I am not setting any cheats so unless mupen is imposing some I guess not :)
I haven't had chance to dig into the code much yet, had a look at rice today and I believe I fixed some graphical issues. Of course I can't be certain until I can run it again ;)
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 01:24:56 PM
Excellent!  Been wanting to work on Rice, but tend to get swamped with other things.  Really greatful for the help!
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 10, 2013, 01:33:52 PM
Your welcome :)

Let me know when you are ready for me to test again and we will see if we can nail this issue.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 02:34:57 PM
Ok, I did a little digging, and the only place I can find that would print a message like the one in the first line of your log (which is cut off, by the way  :P), is in persistent/ConfigFile.java, in the save() method:

Code: [Select]
    public boolean save()
    {
        // No filename was specified.
        if( TextUtils.isEmpty( mFilename ) )
        {
            Log.e( "ConfigFile", "Filename not specified in method save()" );
            return false;   // Quit
        }
       
        // No config data to save.
        if( mConfigList == null )
        {
            Log.e( "ConfigFile", "No config data to save in method save()" );
            return false;   // Quit
        }
       
        File f = new File( mFilename );
       
        // Delete it if it already exists.
        if( f.exists() )
        {
            // Some problem deleting the file.
            if( !f.delete() )
            {
                Log.e( "ConfigFile", "Error deleting file " + mFilename );
                return false;   // Quit
            }
        }
       
        try
        {
            FileWriter fw = new FileWriter( mFilename );  // For writing to the config file

            // Loop through the sections
            for ( ConfigSection section : mConfigList )
            {
                if( section != null )
                    section.save( fw );
            }

            fw.flush();
            fw.close();
        }
        catch( IOException ioe )
        {
            Log.e( "ConfigFile", "IOException creating file " + mFilename + ", error message: " + ioe.getMessage() );
            return false;  // Some problem creating the file.. quit
        }
       
        // Success
        return true;
    }

It seems that an IOException was thrown and it returned false.  This was not handled properly from wherever it was called, resulting in a NullPointerException, which caused the crash.

Anyway, actually looking at the code, I'm not sure why this code doesn't work for you.  Notice that we delete the file:

Code: [Select]
        if( f.exists() )
        {
            // Some problem deleting the file.
            if( !f.delete() )
            {
                Log.e( "ConfigFile", "Error deleting file " + mFilename );
                return false;   // Quit
            }
        }

Then we point a new FileWriter to it (which should recreate the file since it no longer exists):
Code: [Select]
            FileWriter fw = new FileWriter( mFilename );  // For writing to the config file

            // Loop through the sections
            for ( ConfigSection section : mConfigList )
            {
                if( section != null )
                    section.save( fw );
            }

Only a couple of things I can think of that would cause this.  Either your device doesn't follow normal Java behavior to create the file with FileWriter if it doesn't exist, or there is something wrong with the path to the file.  Since you are building from source, you can check if the former is the case pretty easily.  Just add the following line before FileWriter fw = new FileWriter( mFilename );
Code: [Select]
new File( mFilename ).createNewFile();
If that doesn't fix the problem, check the logcat again to see if the error message changed at all.  To check if paths are the problem, make sure /mnt/sdcard/Android/data/paulscode.android.mupen64plusae/ actually exists on your device.
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 10, 2013, 03:53:16 PM
Tried that, didn't get me any further.

However I did get a better output from adb for you this time.
A lot of errors going on, seems like it's not loading any of the libs and is crashing on trying to read the game header.

Just an fyi.

Xperia play is on stock 2.3 firmware.
Galaxy S3 is on 4.0.3 Custom.

The public version of mupen 64 plus ae works fine on both devices.

Crash log (forum wouldn't let me post it even though it is only 80ish lines :P )

Code: [Select]
http://pastebin.com/MHFbqWvW

EDIT: If you have no joy with this I can start digging on saturday. You will naturally be able to track it down faster than I will right now as your a lot more familiar with the source. So i'm hoping you beat me to it ;) . I want to push in some rice stuff on sunday so working this out is a high priority :)

Thanks Paul
Title: Re: Version 2.0 Release Candidates
Post by: karl_87 on January 10, 2013, 05:00:57 PM
Emulator works great on my Archos Gamepad, and the buttons seem to map well - good job! but for some reason when I play Zelda - Ocarina of Time, it suffers from massive black flickering backgrounds, if i change the video plugin to the other one, the problems seem to stop but the framerate is so low its unplayable, not sure if this is specific to my device or i haven't got something setup correctly? any ideas? cheers for the work so far

I know of a couple settings that can cause flickering in Zelda.  One is Tribuffer Opt, which is currently hardcoded so you can't turn it off at the moment.  The other is Hack Z.  I think it shows up in the gles2n64 video settings as "Depth Test" or something.  You could try checking/ unchecking that option to see if it helps gles2n64.

For gles2rice, you could try enabling Auto Frameskip to help speed it up (generally works for Zelda OOT, but not a lot of other games -- will crash some devices).

Some folks have also reported that using the "Exactly" Frameskip options (gles2n64 video settings), for example "Exactly 1", can greatly improve speed.  Might be worth a try.  Also, it has been reported for some devices that enabling Stretch Screen (both video plug-ins) improves speed a little.  Also see if there is any difference using the framelimiter setting (both plug-ins).  You could really tinker around with all the settings though to see what helps on your particular device.  If you find a good profile of settings, please post them here for other users with similar devices to try.

i tested zelda oot today, have some glitches too, the walking path keep flickering in black, tested with both plugins.
Could you also try the Hack Z setting (called "Depth Test in" in the menu I believe)?  Could you also test Mario 64 and see if the shadows are missing, flickery, or floating way far off the ground?  That could indicate a problem with polygon offset, which can also cause flickering.

Also, the sound is choppy  :(
Choppy sound means slow emulation (for many devices this happens most noticeably during the cutsceens, in the forest with all the fairies, and in the large open-field).   Could you try playing with the settings as well (in particular the Frame Skip options), and report what settings you used if you are able to improve performance?

Hi Paul, got gles2rice working at good speed by turning on autoskip like you said, but the graphics are now flickering just on the floor like the other guys. Went through every option including what you said, nothing seems to improve for this game :(
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 08:27:01 PM
A lot of errors going on, seems like it's not loading any of the libs and is crashing on trying to read the game header.

Is that the APK you built, or the one from here on the forum?  I was thinking if it was yours, you might not have built the native libraries before building the APK.  If it's the one from here, I have no clue why it would be unable to load any of the libraries.  Same type of error log on both your devices, or just the GS3?
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 10, 2013, 10:47:15 PM
Posted Release Candidate 2.  This one is looking pretty good..
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 10, 2013, 11:21:00 PM
I also had force close issues on my xplay, but only with touchpad enabled.  Report logged on bugsense.  Issue was the dreaded failure to load lib again.  In this case the xplay lib.
Title: Re: Version 2.0 Release Candidates
Post by: jack111 on January 11, 2013, 01:28:16 AM
When can we expect a change log between the market version and the upcoming one
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 11, 2013, 06:14:07 AM
Hey Paul.

I was indeed forgetting to run ndk-build. Egg on my face. However the issue remains.

With the RC2 you posted I get a force close when it starts to build/list the available cheats.

New crash log (via pastebin below):

http://pastebin.com/Kcp9vvas
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 06:25:36 AM
Same deal? (unable to load the libraries?) This sounds like a pretty serious problem, so I think I'll delay publishing for a couple days until we track it down just to be safe.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 06:28:26 AM
When can we expect a change log between the market version and the upcoming one

I'll post one on the Beta Testing has Begun thread when I publish the app (probably early next week), and the changlog link will point to it.
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 11, 2013, 06:29:59 AM
It's a different story this time.

http://pastebin.com/Kcp9vvas

Seems to be related to the xperia touchpad library (same thing littleguy reported) this time.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 06:38:38 AM
Unfortunately I don't have an Xperia Play for testing on so might take me a while to figure out.  Littleguy will probably have better luck tracking this one down if he is experiencing the problem too.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 11, 2013, 06:45:22 AM
I'll start looking into it.  Not sure how much progress I can make since it involves the core and isn't something easy like an npe.
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 11, 2013, 06:46:01 AM
The good news is that it works on my Samsung Galaxy S2 now. So I can test my rice changes at last :)


PS: I think we should consider moving the "Z" button from the top left corner to next to the B/A buttons.
Have any of you tried to play goldeneye? It's impossible with the "Z" button in that top left corner :p
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 07:43:48 AM
I'll start looking into it.  Not sure how much progress I can make since it involves the core and isn't something easy like an npe.
Seemed like an issue with JNI, though I didn't see the full log cat before the acra report.  Another possibility is it could be a similar problem as the rsp-hle bug, needing to build in arm mode instead of thumb.  Should be able to put in some logging to check if the file libxperia-touchpad.so exists, and what error message is in the Exception thrown of you call System.load on it.

--EDIT--
This is assuming your problem is the same one as zack posted.  The following from zack's crash is what gives me the impression it is probably a JNI issue:

Code: [Select]
E/AndroidRuntime( 4986): FATAL EXCEPTION: main
E/AndroidRuntime( 4986): java.lang.RuntimeException: Unable to start activity ComponentInfo{paulscode.android.mupen64plusae/paulscode.android.mupen64plusae.GameActivityXperiaPlay}: java.lang.IllegalArgumentException: Unable to load native library: /data/data/paulscode.android.mupen64plusae/lib/libxperia-touchpad.so
E/AndroidRuntime( 4986):        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1659)
E/AndroidRuntime( 4986):        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1675)
E/AndroidRuntime( 4986):        at android.app.ActivityThread.access$1500(ActivityThread.java:121)
E/AndroidRuntime( 4986):        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:943)
E/AndroidRuntime( 4986):        at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 4986):        at android.os.Looper.loop(Looper.java:130)
E/AndroidRuntime( 4986):        at android.app.ActivityThread.main(ActivityThread.java:3701)
E/AndroidRuntime( 4986):        at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 4986):        at java.lang.reflect.Method.invoke(Method.java:507)
E/AndroidRuntime( 4986):        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866)
E/AndroidRuntime( 4986):        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:624)
E/AndroidRuntime( 4986):        at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime( 4986): Caused by: java.lang.IllegalArgumentException: Unable to load native library: /data/data/paulscode.android.mupen64plusae/lib/libxperia-touchpad.so
E/AndroidRuntime( 4986):        at android.app.NativeActivity.onCreate(NativeActivity.java:199)
E/AndroidRuntime( 4986):        at paulscode.android.mupen64plusae.GameActivityXperiaPlay.onCreate(GameActivityXperiaPlay.java:61)
E/AndroidRuntime( 4986):        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
E/AndroidRuntime( 4986):        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1623)
E/AndroidRuntime( 4986):        ... 11 more
--END EDIT--

PS: I think we should consider moving the "Z" button from the top left corner to next to the B/A buttons.
Have any of you tried to play goldeneye? It's impossible with the "Z" button in that top left corner :p

That's more an application for a custom gamepad layout than for the default.  Most games would be difficult if z required lifting the right thumb (fast jump in Mario 64, for example).  Top-right corner most closely matches the N64 controller on multi-touch devices, because you can trigger z with the side of your left index finger while using analog with your left thumb and A/ B with your right thumb, and R with the side of your right index finger.  Same fingers as used on the controller (albeit a bit more awkward)
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 11, 2013, 08:33:55 AM
paul, i tried with glesn64 plugin, disabled and enabled depth test, no changes. The path still flickering , sometimes it just disappear. The fps count is strange, when i play the game seems fullspeed, but counter show 17 fps  :o Only in cutscenes the sound is choppy, during gameplay is ok.

Tested with Super Mario 64. With depth test off, the shadow flicker a lot, disappear some times, show cut. With depth test on, don't flicker anymore, but shadow still cut and disappear some times.

Here some nice pics:
Spoiler: show

Depth test on
(http://s9.postimage.org/amv5a4ucv/Screenshot_2013_01_11_11_21_58.png)
Depth test off
(http://s13.postimage.org/luz9x222v/Screenshot_2013_01_11_11_22_41.png)
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 11, 2013, 09:46:00 AM
With depth test on, don't flicker anymore, but shadow still cut and disappear some times.

Paul - I can add a preference for manually selecting the polygon-offset profile in the Video menu.  Might solve some of these problems.  The only question is what to write in the UI list.  I'll use the following for now, unless you can think of something better:

Default
OMAP
OMAP (alternate)
IMAP
Qualcomm
Tegra
Auto detect*

* Default setting on install
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 11, 2013, 09:50:32 AM
It's a different story this time.

http://pastebin.com/Kcp9vvas

Seems to be related to the xperia touchpad library (same thing littleguy reported) this time.

Bug fixed in the source by Sven.  Makefile-related bug, introduced just a few days ago.

Now I'm wondering if it's a similar story for all the other missing library exceptions.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 09:53:14 AM
That seems best, from a human-readable perspective, vs. displaying the numbers.  Those names were originally just meant for me to distinguish the profiles, and don't really have a 1-to-1 relation with the devices that fit into them.  I can foresee having to explain that to folks a few times when they wonder why their random ARMv6 device fits into the Tegra category, for example, but oh well!
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 09:57:20 AM
paul, i tried with glesn64 plugin, disabled and enabled depth test, no changes. The path still flickering , sometimes it just disappear.
I have a feeling this is related to Tribuffer Opt.  Could you post a screenshot? (the Tribuffer Opt bug has an easily recognizable look to it)
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 11, 2013, 10:00:06 AM
Might be able to add an extra popup with info on that particular menu item.

The question to me is whether you'd ever have, say, an OMAP device whose best setting was, say, Tegra.  That would be really confusing.
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 11, 2013, 02:48:45 PM
Here more screenshots from zelda oot:
http://img22.imageshack.us/img22/8206/screenshot2013011117271.png (http://img22.imageshack.us/img22/8206/screenshot2013011117271.png)
http://img405.imageshack.us/img405/8206/screenshot2013011117271.png (http://img405.imageshack.us/img405/8206/screenshot2013011117271.png)
http://img845.imageshack.us/img845/6789/screenshot2013011117272.png (http://img845.imageshack.us/img845/6789/screenshot2013011117272.png)
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 03:49:55 PM
Here more screenshots from zelda oot:
That's not Tribuffer Opt - definitely a polygon offset issue there.  Should be able to fix Mario and OOT for your device at once if we're lucky.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 03:51:28 PM
The question to me is whether you'd ever have, say, an OMAP device whose best setting was, say, Tegra.
That's a good point.  It might be better to just list the numbers, or maybe "Profile A", "Profile B", etc.  It is an advanced setting anyway, so don't have to make it understandable by everyone.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 11, 2013, 04:13:19 PM
Alright.  I could just use cryptic codes to make it easy for devs and hard-core users, while still encouraging the general population to try all of them if they're having problems.

Title: Hardware profile (affects texture/shadow flicker)
Summary: [selected value]
Entries:
  Auto-detect*
  Standard
  O1
  O2
  Q
  T

Remind me again - is this specific to one of the video plugins, or does it affect them both?
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 04:36:02 PM
It affects both
Title: Re: Version 2.0 Release Candidates
Post by: daddyfredregill on January 11, 2013, 05:10:54 PM
Not sure if this goes here but Conkers bad fur day is running a lot better with this version. In the video settings I have all the options checked and it is very fast and playable. The audio is even better, only cuts out a little now and then. Playing on nexus 7. If you need any specific tests that need to be tested on a higher end device I would be willing to help you out. Thanks for your hard work you have put into this emulator.
Title: Re: Version 2.0 Release Candidates
Post by: cory on January 11, 2013, 05:35:41 PM
Hey paul could you take me off of being release candidate number 1?my phone won't let me run the app for me to test.if it did i would be testing it right now
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 06:02:18 PM
Sorry I don't know what you mean ???
Title: Re: Version 2.0 Release Candidates
Post by: xperia64 on January 11, 2013, 06:04:12 PM
I think he means how to completely uninstall it and install RC2. It isn't neccessary but first uninstall the apk, then go into /sdcard/Android/data and delete the paulscode mupen .cfg file. Then install RC2
Title: Re: Version 2.0 Release Candidates
Post by: cory on January 11, 2013, 06:05:25 PM
I mean i can't be a candidate
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 11, 2013, 06:11:11 PM
The word "candidate" refers to the app, not the users.
Title: Re: Version 2.0 Release Candidates
Post by: arrtoodeetoo on January 12, 2013, 08:23:08 AM
Bummer. There are still issues with Mario Kart.  >:(

The split screen issue is still there, and some tracks run way too fast, like DK Jungle, and Moo Moo farm on 3/4 player split screen.

I'm able to fix the split screen stretch issue by opening up the. Apk file and moving over the rice plugin files from the Dec. 3 built, then re-signing the .apk and installing.

I'm on a Nexus 10 now (was on a XOOM) and everything runs much smoother, plus HDMI out just works like it should, whereas it gave me fits on the XOOM.

Also, I see that the multiplayer setup has been moved outside of the game. The way it was before, the buttons would have to be reset every time the game was exited. Is the new way a more permanent solution? Will I have to set it up each time I start the app?
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 12, 2013, 09:46:58 AM
Take a look at the changelog on the second post, it will be the first to say when a major bug is fixed.  Save you some trouble if that's all you want to know.

If you want to ensure all the devs know about a bug, please post here (https://github.com/paulscode/mupen64plus-ae/issues?sort=created&state=open) (also accessible from the in-game help menu).  Not all devs have the time to sift through all the forum posts.

Multiplayer setup is hopefully a much better experience now.  It will remember your settings between sessions and games.  However, a limitation of Android is that you'll still have to go through the setup process after you've rebooted or unplugged/replugged your controller.  This is because Android changes the device ID in those cases, and the device ID is all we can use to differentiate controllers.  There may be some solution buried deep inside the native code, but I've yet to discover it.  Because of this requirement, multi-player setup is moved to the play submenu, since you may need to access it right before launching a game.  Been working on this for several months now and this is the best I've been able to come up with.

Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 12, 2013, 10:58:18 AM
I posted Release Candidate 3.  I might just be overly cautious, but I've decided to delay publishing a couple more days, just to give some more time for any serious problems to be identified and fixed.  I also forgot to drop in the latest translations from Transifex into this build, but I'll definitely grab them before publishing.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 12, 2013, 11:02:16 AM
Re: translations.  A day or two before the release, I suggest we follow this process:
 - manually import the source strings into transifex (don't wait for cron to do it at 3am)
 - there should be a transifex option to "freeze strings" so that no more source strings change
 - set a translation deadline in transifex
 - make an announcement on the translations page in case some translators missed the freeze/deadline notices.
 - pull translations after the deadline and publish :)
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 12, 2013, 11:26:43 AM
Argh.  I'm implementing the option to allow multiple players to share a single keyboard/controller (issue 24 (https://github.com/paulscode/mupen64plus-ae/issues/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.
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 12, 2013, 12:19:58 PM
Hey Paul, I found some problems that I missed in my translation, I've fixed it in Transifex  :) The option to select profiles will also be added to translate?
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 12, 2013, 12:44:22 PM
Profile selection is next on my todo.  The strings for that aren't in transifex yet.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 12, 2013, 02:27:29 PM
Flicker-reduction profile implemented.  Will be in next RC.  I just posted the updated strings to Transifex.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 12, 2013, 06:02:57 PM
I went ahead and posted this update as Release Candidate 4, so we can hopefully get a few more devices into the profiler before we publish.  I'm posting a thread in Tester's Corner to call for folks to figure out what profile works for their device, and to post their device info so we can add them to the profiler.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 13, 2013, 12:27:36 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: chery2k on January 13, 2013, 01:52:56 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: zack on January 13, 2013, 09:45:57 AM
Just pushed in some Makefile CFlags optimisations.
From testing it seems to have resulted in a small speed improvement.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 13, 2013, 01:36:28 PM
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.
Title: Re: Version 2.0 Release Candidates
Post by: chery2k on January 13, 2013, 09:15:54 PM
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.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 13, 2013, 09:20:15 PM
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?
Title: Re: Version 2.0 Release Candidates
Post by: chery2k on January 14, 2013, 12:57:59 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: maalox on January 14, 2013, 05:09:15 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 05:41:54 AM
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 (https://github.com/paulscode/mupen64plus-ae/issues/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.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 05:44:13 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 05:49:27 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 08:04:32 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 08:07:20 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 08:35:45 AM
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 (https://github.com/paulscode/mupen64plus-ae/commit/4b3a25b43eca22f0b1f0c6eac9e5b486bf983b9e) (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.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 08:45:46 AM
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.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 08:55:06 AM
As a git newb myself I'd be pretty lost without a gui.  I actually use two:

- I started with TortoiseGit and still use it because for simple push/pull/commit, as I like its simple windows explorer integration (the icon overlays that show git status are a must-have IMO).  I also like its "Fetch & Rebase" option inside the "Sync..." screen.  Super handy.  BUT IIRC it's only for windows though.

- I use GitExtensions whenever I'm doing something more complex, and I simply love it for browsing the repository.  Very nice graphical depiction of branches, and it's what makes it so easy in my mind to manage 10 branches at once.  (I have a lot of dead-end developments that I put onto local branches so that I can refer back or cherry pick them.)  It looks to be available in Linux here:

http://code.google.com/p/gitextensions/downloads/list

- I still use the command line for special things, like removing a commit from github (http://stackoverflow.com/questions/448919/how-can-i-remove-a-commit-on-github).


Hopefully I'll solve the root of the problem before your next build, then all that won't be necessary.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 09:13:27 AM
Perfect, thanks I'll take a look at GitExtensions.
Title: Re: Version 2.0 Release Candidates
Post by: jonjon on January 14, 2013, 09:39:24 AM
Overall, RC5 is great on nexus 7.


2 small things

'Main menu' option no longer actually takes you to the main menu. Perhaps it could be renamed to 'play menu' or actually have it point to the main menu (my personal preference because the play menu is only good for cheats and resetting roms).

The lag from loading the cheats list in the 'play menu' has been reduced but its still very noticeable - especially when having to go backwards and forwards to test games and debug settings frequently.


Great stuff!
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 10:16:30 AM
Littleguy mentioned this on github ... we should probably add an option to enable/ disable cheat options (I think disabled by default.. what are everyone's thoughts on that?)

My only concern with this is if someone exits a game with cheats enabled, then disables cheat options, then returns to the Play menu and hits resume, the game will resume with some of the previous cheats still enabled.  This is because save-state and load-state do not play nice with cheats, unfortunately.  I can foresee users complaining that they disabled cheats in the menu but still had cheats when they resumed the game.  Of course the simple answer to them would be to restart instead of resume  ;D  It gets even more tricky when you consider in-game saves with certain cheat options enabled.  This is actually still a problem even with the current implementation (thus the reason for the warning under the resume option).  We'll probably just have to accept this inconsistency until we implement an in-game cheats menu to replace the current cheats-on-start implementation (which would allow disabling all cheats before auto-save on exit).

Re: Main Menu:  Maybe we should just change it to say "Menu" (would also improve space restrictions in the action bar a bit)
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 10:20:42 AM
Sure, will change the string to "Menu".

I'll put in an option right above the cheats category to show/hide cheats.  So it's not buried deep down in some other menu.  When unchecked, we'll forego the whole cheats menu buildup, should save some loadup time.  I still like having a Play screen (even without cheats shown) because it's a good place to put the multi-player setup and restart items.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 10:35:00 AM
Excellent, that keeps the other menus less cluttered too, but having everything cheats related in one place
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 10:48:25 AM
Hmmm. Reverting the eclipse settings made no difference.  Now looking into the settings persistence stuff.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 11:50:44 AM
Got it.  Tracked down the input bug.  Problem had to do with preference data files.  In earlier RCs the player map was persisted to the default file.  After I refactored the cheats I decided to put cheats options in a separate data file, partly so that I didn't screw up the regular preferences.  So the multiplayer map was accidentally being persisted there instead.  At game time, UserPrefs.java looked in the old location for the player map.  If the user hadn't done a clean reinstall, there was still a persisted value in the old stale location so they didn't get a fail.  Once you do a clean reinstall, the stale file is refreshed and no longer contains the player mapping.

I think I'll just keep it simple and persist the cheats to the default file along with all the others.  Makes for a simpler development model, and I have enough confidence now in the way I refactored the cheats menu.

I'll make the fix and  push.  A one-line fix.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 11:57:18 AM
Sounds good.  I'll post another build during lunch in a few minutes (should have some time to pull and do a build)
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 11:58:18 AM
I can probably squeeze in the cheats checkbox in the next half hour.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 11:58:54 AM
Sure, I'll wait until the end of lunch hour then.  I'm hungry anyway ;D
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 12:23:58 PM
Just realized I don't have my digital signature here at work anyway, but at least I could post a debug build until I get home this evening.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 12:33:28 PM
Ok, well it's there anyhow.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 12:48:53 PM
Thanks.  Hope you didn't skip lunch for it  :o
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 01:19:10 PM
Ok, here's the debug build with those fixes in place.  Due to a digital signature conflict, it will require uninstalling RC5 before you'll be able to install this one, so if anyone wants to avoid that, just wait until this evening when I post RC6.  As a debug build, this one may run some games a little slower, but it should be good for testing the Input fixes and cheats option.

Debug Build (http://www.paulscode.com/source/Mupen64Plus-AE/14JAN2013/Mupen64Plus-debug.apk)  (uninstall previous version first, or wait until RC6 this evening)
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 14, 2013, 04:14:50 PM
I will wait rc6... Why don't use a expand menu to show cheats?  Like a button show/hide cheats on play menu
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 04:39:42 PM
Already done.  Will be in RC6
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 04:55:19 PM
I think I'll shoot for publishing tomorrow evening.  That will give RC6 (which I'll post this evening) a day to be tested, and if anything else serious surfaces I can push it back a while longer.  I'm not in any rush to publish, just like to have a plan for things.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 05:08:01 PM
Cool.  There are a few missing translations at the moment, maybe we say no more changes to the source strings now, unless there's anything you wish to change/add/cleanup.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 05:09:42 PM
There's one last option I can think to add, and that would be an override to enable/disable input unbiasing and normalizing.  Maybe turn those off by default, and tell Xbox users to enable it.

Edit: come to think of it, maybe we just leave things as they are on that topic.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 05:13:38 PM
Looks pretty good to me when I did a quick look-through earlier.  Only things I noticed were "Main Menu" and "Depth test", but those are minor points.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 05:45:17 PM
Oops, you're right.  Any ideas what to call depth test?  Currently, checked means normal, unchecked means it does some rescaling and offset in the depth coordinate.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 06:50:50 PM
Have you refreshed the translations yet? If not I'll do it real fast.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 07:45:03 PM
Thanks, I pulled from 00380eb2a5 when I build Release Candidate 6.  Hopefully that's everything.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 07:46:10 PM
Yup.  I'm done for the night.  Didn't fix the Main Menu or Depth Test strings though.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 14, 2013, 07:47:46 PM
No problem.  Thanks for all the help today.  I'm going to play around with the OUYA now.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 14, 2013, 07:51:00 PM
Cool.  Check out your OUYA thread, I posted a bunch of stuff that should hopefully help you sort out what's going on.
Title: Re: Version 2.0 Release Candidates
Post by: xavouine on January 14, 2013, 09:48:29 PM
Just tried RC6 on my TF300 (JB 4.1) and it is super smooth.
The only issue I've come up with is that you can't use the "share controller" with the on-screen input. In turn-based games for example, it would be nice to be able to both use the controls on-screen for those who don't have an external controller. ( Like I thought I was part of until I remembered my keyboard) .
I'm not a pro at programming but I was wondering if it was perhaps possible to integrate a "switch controller" in the in-game mini-menu.
Title: Re: Version 2.0 Release Candidates
Post by: chery2k on January 15, 2013, 12:34:51 AM
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.

I just got back from playing Mario 64 (latest mupen64 candidate) the c-buttons is played out perfectly on my xperia play (played the whole level without hiccups) Ok heres another game with c:button trouble it is also on Star Wars Episode 1 Pod Racer (No control over cbutton behavior). My pod racer always stays tilted during a race from start to finish. The pod racer can't center itself.
Title: Re: Version 2.0 Release Candidates
Post by: chery2k on January 15, 2013, 01:16:20 AM
Any chance to port the cbutton code from Mupen64 Version 1.9 (6 May 2012) towards the latest candidate? Something changed on the source code for the c:buttons not to be emulated perfectly on the touchpad or gamepad.  For some reason when I use that version I posted above I have no problems or limitations with the c:buttons being used on the touchpad or hard keys.
Title: Re: Version 2.0 Release Candidates
Post by: maalox on January 15, 2013, 03:25:53 AM
Multiplayer is working for me again as of rc6, and the whole build feels very smooth and polished. Great work! The only issue which affects me right now is multiplayer Mario Kart. As stated before, the first video plugin does not work correctly (bottom half of the screen is black when there are 2 players), and the rice plugin shows weirdly stretched video for both players.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 15, 2013, 08:28:57 AM
Any chance to port the cbutton code from Mupen64 Version 1.9 (6 May 2012) towards the latest candidate? Something changed on the source code for the c:buttons not to be emulated perfectly on the touchpad or gamepad.  For some reason when I use that version I posted above I have no problems or limitations with the c:buttons being used on the touchpad or hard keys.

I haven't been able to replicate your problem yet, but I'll keep trying.  Just a few questions:
 - What model xperia play are you using (or what carrier)?
 - What Android version?
 - Are you running a custom ROM?
Title: Re: Version 2.0 Release Candidates
Post by: chery2k on January 15, 2013, 08:32:17 AM
- R800i (t-mobile usa)
- 2.3.4
- Dixperia custom rom but based off stock
Title: Re: Version 2.0 Release Candidates
Post by: jonjon on January 15, 2013, 09:29:28 AM
Rc6 feels amazingly polished. Very excellent work and thanks for listening to my suggestions!.. That made me very ☺

Would you consider publishing directly to the f-droid repository? Mupen64ae is one of the best android Foss projects so the two should go hand in hand... No possible dcma issues there either!

Cheers everyone
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 15, 2013, 09:31:49 AM
Would you consider publishing directly to the f-droid repository?
Sure, I'll take a look at it, maybe this weekend.
Title: Re: Version 2.0 Release Candidates
Post by: turtleparadise on January 15, 2013, 09:44:09 AM
I just tried both RC5 and RC6 and had the same issue on three different wrestling games. The game play was good for the first minute or two, but then a phantom button press would happen. It is usually a direction on the D pad or the A button. Once the phantom button press happens it does not stop.
This problem happened on the following games:
WWF No Mercy
WWF Wrestlemania 2000
Virtual Pro Wrestling 2

I am using an EVO LTE running Cyanogenmod 10 (4.1.2).
Title: Re: Version 2.0 Release Candidates
Post by: jonjon on January 15, 2013, 09:54:45 AM
Cool, they already have v1.82 built from source but haven't updated in a while.... They are waiting on version 2.0 I believe.

I found mupen64ae through f-droid and along with mupen64ae it's one of the best android applications available. They will probably build an updated version eventually but I thought you might be interested to be part of the publication process, they are also pretty cool and knowledgeable dudes!

The main topic regarding m64ae on their forums:
http://f-droid.org/forums/topic/mupen64plus-android-edition/#post-1894

Mupen 64 gets a recent mention here:
http://f-droid.org/forums/topic/where-can-i-report-some-apps-that-are-dated/#post-5459
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 15, 2013, 11:21:53 AM
I just tried both RC5 and RC6 and had the same issue on three different wrestling games. The game play was good for the first minute or two, but then a phantom button press would happen. It is usually a direction on the D pad or the A button. Once the phantom button press happens it does not stop.
This problem happened on the following games:
WWF No Mercy
WWF Wrestlemania 2000
Virtual Pro Wrestling 2

I am using an EVO LTE running Cyanogenmod 10 (4.1.2).

Were you using the touchscreen controls by any chance?
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 15, 2013, 11:29:59 AM
Just tried RC6 on my TF300 (JB 4.1) and it is super smooth.
The only issue I've come up with is that you can't use the "share controller" with the on-screen input. In turn-based games for example, it would be nice to be able to both use the controls on-screen for those who don't have an external controller. ( Like I thought I was part of until I remembered my keyboard) .
I'm not a pro at programming but I was wondering if it was perhaps possible to integrate a "switch controller" in the in-game mini-menu.

Hmm, maybe the wording needs to be more clear.  The "share controller" option is to share input devices, like a ps3 controller or a keyboard.  It doesn't refer to sharing the touchscreen controls.  I hadn't thought of a use case for that until this post.  I'll list it as an enhancement on the issue tracker at github.

The "share controller" option is mostly a workaround for a few controllers on the market where several gamepads are seen by the OS as a single device.  A good example are some of the N64-USB adapters, where two controllers are plugged into the adapter, which plugs into a single usb port (and hence looks like a single device to the OS).
Title: Re: Version 2.0 Release Candidates
Post by: turtleparadise on January 15, 2013, 12:02:24 PM
I just tried both RC5 and RC6 and had the same issue on three different wrestling games. The game play was good for the first minute or two, but then a phantom button press would happen. It is usually a direction on the D pad or the A button. Once the phantom button press happens it does not stop.
This problem happened on the following games:
WWF No Mercy
WWF Wrestlemania 2000
Virtual Pro Wrestling 2

I am using an EVO LTE running Cyanogenmod 10 (4.1.2).

Were you using the touchscreen controls by any chance?

Yes I am using the onscreen controls.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 15, 2013, 12:21:43 PM
It's sounding like there's a bug in the code that handles the touchscreen/touchpad controls.  I played SW Episode I Racer for about 10 minutes and was finally able to get the c-button stuck once.  Not sure if that's the same thing you are experiencing, but this would suggest that the app didn't get the message that a finger was lifted from the pad/screen.  The bug doesn't show up in Mario because nothing changes if you continue to hold down the c button, whereas in ep 1 racer, the pod will stay rotated as long as you continue to hold the button.

I'll compare the code between RC6 and 1.9.2 and try to locate any differences.  That code was reorganized but not fundamentally changed, so my guess is that it's an easily fixable bug that doesn't require major rewrite.  The trick will just be to find the difference between the two.

Thanks for the feedback.
Title: Re: Version 2.0 Release Candidates
Post by: chery2k on January 15, 2013, 12:37:26 PM
Yes thats exactly what I was experienceing the cbuttons get stuck once i lifted my finger off the touchpad. I did that alot on starfox rotating between the c button and the a button to fire.
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 15, 2013, 12:37:38 PM
I know one difference between the two implementations was that I tested control presses based on pointer movements as well as up and down events.  Using just the up and down events is certainly more efficient, but I would look to the logic there as a potential source for the problem.

One thing that pops to mind, it might be good to see what happens when two PIDs were registered as going down on the same button.  Also, look at the logic behind ACTION_DOWN/ ACTION_UP along with ACTION_POINTER_DOWN/ ACTION_POINTER_UP (annoying that Android uses all four, when just the latter two would be sufficient IMO).  Also check the corner cases such as where two pointer ids get close enough that they could be interpreted as one pointer (what happens to the id's when you then slide them apart from each other?)
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 15, 2013, 12:56:46 PM
Actually I stand corrected - motion events also press controlls in the new implementation it seems.  My misstatement did lead me to an easy way to replicate the problem though.  Start Mario64, press the z-button, slide your finger to the r-button, and release.  Mario will stay crouching as if the z button were still pressed.
Title: Re: Version 2.0 Release Candidates
Post by: littleguy on January 15, 2013, 01:04:09 PM
Great! Excellent suggestions, and a known method to replicate the problem.  I'll take a look tonight.  Or you can try to beat me to it ;)
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 15, 2013, 03:08:15 PM
Great! Excellent suggestions, and a known method to replicate the problem.  I'll take a look tonight.  Or you can try to beat me to it ;)

Pushed a fix, but need to test it a little more thoroughly to make sure it didn't break anything, and that the problem is fully resolved.
Title: Re: Version 2.0 Release Candidates
Post by: gdark100 on January 15, 2013, 05:28:06 PM
the final 2.0 version will be released today? I made some fixes on my translation, please update again ;D
This last RC is excellent!
Title: Re: Version 2.0 Release Candidates
Post by: Paul on January 15, 2013, 05:42:29 PM
-- TOPIC CLOSED --