Author Topic: 3.0 Alpha Testing  (Read 289852 times)

Offline rafar

  • int
  • **
  • Posts: 67
    • View Profile
Re: 3.0 Alpha Testing
« Reply #435 on: January 18, 2015, 02:01:30 AM »
amazing the new refresh option  ;D

Offline scorpio16v

  • long
  • ***
  • Posts: 203
    • View Profile
Re: 3.0 Alpha Testing
« Reply #436 on: January 18, 2015, 02:44:40 AM »
Scanning for ROMs causes an emulator crash.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #437 on: January 18, 2015, 06:08:05 AM »
Thanks much scorpio.  Did this happen once, or does it happen every time?  Which build was this from?  Could you please post the text file from mupen64plusae-v3-alpha/CrashLogs as well (even if it doesn't contain much).  The crash log has extra info and it would be good to see if it picked up the same logcat messages.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #438 on: January 18, 2015, 06:28:27 AM »
Alpha 16 posted.  See OP for changelog and download link.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline scorpio16v

  • long
  • ***
  • Posts: 203
    • View Profile
Re: 3.0 Alpha Testing
« Reply #439 on: January 18, 2015, 07:08:27 AM »
Here is the Crash.log, you asked for.
Is's the last auto-build version number "201501172301" (AKA Alpha 16)

Yes, it happened always in the last builds, if I enable scan for zip ROMs.
« Last Edit: January 18, 2015, 07:55:12 AM by littleguy »

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #440 on: January 18, 2015, 07:59:14 AM »
Thanks @scorpio16v :D

The crash log is useful because it is easier to read, and it tells us you are running on an x86 device (though I doubt that has anything to do with this crash).

Any dev want to take a stab at this?  Should be a pretty straightforward drill-down to fix it.  I'd like to keep working on the new front-end features.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #441 on: January 18, 2015, 08:03:57 AM »
Just wanted to announce that I updated the OP with a lot of useful info about what has changed between each Alpha release.  Just open the spoiler area on previous Alphas.  This should provide some needed clarity on where and when Gilles' fixes got into the alphas (and there are more to come), when we synced with upstream, etc.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3495
  • Developer
    • View Profile
    • PaulsCode.Com
Re: 3.0 Alpha Testing
« Reply #442 on: January 18, 2015, 08:52:17 AM »
Here is the Crash.log, you asked for.
Is's the last auto-build version number "201501172301" (AKA Alpha 16)

Any dev want to take a stab at this?  Should be a pretty straightforward drill-down to fix it.  I'd like to keep working on the new front-end features.

I took a quick look, and it doesn't seem to be a problem with ZIP files in general (it gets through several successfully).  Problem seems to happen for a specific file: Resident+Evil+2.zip.  It recognizes it as a ZIP file, but throws an Exception internally to the ZipFile class upon instantiation.

My initial thought is there may be a corruption/ incompatibility with the ZipFile utility class, but I'll need the actual file that is causing the problem to diagnose it.  If that is the problem, I'll make sure the CacheRomInfoTask class handles the exception gracefully.

@scorpio16v, does the scan work if you move that one file out of the search path?  If not, please post another report after moving the file out.  If the scan does work with that file out of the way, could you PM me info on the source of the file so I can acquire it for testing?
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline d3n3

  • byte
  • *
  • Posts: 15
    • View Profile
Re: 3.0 Alpha Testing
« Reply #443 on: January 18, 2015, 09:47:28 AM »
Not sure if this is helpful or not but I figured I would report it.

On Alpha 15 and 16, Mario Kart with Gln64-Fast appears to be sped up by default. (say 105%).  When I reduce the speed down to 99-92 I don't see any actual change.  When I put the speed down to 91 then it actually slows down (although unplayable).

I haven't seen this using Glide64-Fast however due to frame drops/lag I cannot use that video plugin for long. 

Hardware: Amazon Fire TV Stick  (Broadcom Capri 28155, dual-core 2xARM A9 up to 1 Ghz)
Alpha Version: 16 (Mupen64PlusAE_master_201501172301_cbf2e50)

I tired this on the Google Play Version and it suffers from the same frame drops/lag as Glide64-Fast.



Offline rafar

  • int
  • **
  • Posts: 67
    • View Profile
Re: 3.0 Alpha Testing
« Reply #444 on: January 18, 2015, 10:05:33 AM »
glide64 fast, goes slower on my g2 than glide64 accurate, did you try with this plugin?

Offline d3n3

  • byte
  • *
  • Posts: 15
    • View Profile
Re: 3.0 Alpha Testing
« Reply #445 on: January 18, 2015, 10:42:44 AM »
glide64 fast, goes slower on my g2 than glide64 accurate, did you try with this plugin?

Tired Glide64-Accurate and it has the same issues as Glide64-Fast.

Gln64-Accurate does fix the speed issue I saw on Gln64-Fast but the audio is pretty bad.  (though not entirely unplayable).  The audio is dy-synced on all my tests.

Offline scorpio16v

  • long
  • ***
  • Posts: 203
    • View Profile
Re: 3.0 Alpha Testing
« Reply #446 on: January 18, 2015, 11:21:42 AM »
@scorpio16v, does the scan work if you move that one file out of the search path?  If not, please post another report after moving the file out.  If the scan does work with that file out of the way, could you PM me info on the source of the file so I can acquire it for testing?
Yes, it seems, that the contained .z64 ROM is broken or maybe contains malware ?
I'll PM you a DL link for testing in a few minutes.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #447 on: January 18, 2015, 12:07:15 PM »
Is there another file in the zip besides the z64 file?
It may be "that one text file" included in it causing issues if there is such a file.

Just tested Banjo-Tooie with polygon/flicker disabled and Rice has the paths going through the Jinjo houses as if I had it enabled and on an imbalanced number. (my most stable number is -0.10 on Banjo-Tooie)

I am curious...
What do the other emulators like PJ64 and 1964 do to achieve proper visuals with Banjo-Tooie using Rice?
Is the visual trouble of Mupen64Plus only an issue for Android,or does it happen in both of them with that setting available in all platforms?
« Last Edit: January 18, 2015, 01:07:51 PM by retroben »

Offline Paul

  • Administrator
  • double
  • *****
  • Posts: 3495
  • Developer
    • View Profile
    • PaulsCode.Com
Re: 3.0 Alpha Testing
« Reply #448 on: January 18, 2015, 01:40:35 PM »
Is there another file in the zip besides the z64 file?
It may be "that one text file" included in it causing issues if there is such a file.

Seems to be a problem with the zip file itself that makes it incompatible with the ZipFile class.  The crash happens at the call to "new ZipFile( file )", which is before doing anything mupen64plus-ae specific to look at the contents to find N64 ROMs.

Just tested Banjo-Tooie with polygon/flicker disabled and Rice has the paths going through the Jinjo houses as if I had it enabled and on an imbalanced number. (my most stable number is -0.10 on Banjo-Tooie)

I am curious...
What do the other emulators like PJ64 and 1964 do to achieve proper visuals with Banjo-Tooie using Rice?
Is the visual trouble of Mupen64Plus only an issue for Android,or does it happen in both of them with that setting available in all platforms?

The "polygon offset" / "flicker reduction" issue is specific to GLES.  The problem is that the offset is dependant on the hardware, so there isn't any one number that can be used that will fit all devices (and from what xperia64 has noticed, not even one number that works for every game on just one device..)  The other emulators you mentioned are using vanilla OpenGL, so that is why they don't exhibit this issue.
Device: Samsung Galaxy Nexus i515
CPU: TI OMAP4460, 1.2 GHz (dual core, ARM Cortex-A9)
GPU: PowerVR SGX540, 307 MHz
RAM: 1 GB
Resolution: 720 x 1280
Rom: omni-4.4.4-20141014-toro-FML KitKat 4.4.4, rooted

Device: Eee PC 1015PEM
CPU: Intel Atom N550, 1.5 GHz (dual core, x86)
GPU: Intel GMA 3150, 200 MHz (dual core)
RAM: 2GB
Resolution: 1024 x 600
Rom: android-x86-4.3-20130725 Jelly Bean 4.3, rooted

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #449 on: January 18, 2015, 01:56:05 PM »
So tweaking the GLES related code is the only way to get rid of the requirement of specific offsets for each game on Android.
What makes that more difficult is the GLES differences between GPU brands.