PaulsCode Forum

Mupen64Plus AE => General Discussion => Topic started by: Paul on December 06, 2014, 02:42:17 PM

Title: 3.0 Alpha Testing
Post by: Paul on December 06, 2014, 02:42:17 PM
Current Alpha Release:

Alpha 21 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201506161103_14f135d.apk)
14f135d (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/14f135d)

Upstream changes:
 - Fix regression in Conker's Bad Fur Day (crash on start)


Alpha 20
0488d08 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/0488d08)

Upstream changes:
 - All new GLideN64 video plugin by gonetz (Sergey Lipskiy)
    - Aims to be most accurate of all video plugins
    - Variants for GLES 3.1, 3.0, 2.0 devices
    - Greatest accuracy/speed with newer GLES 3.1 devices
    - High-resolution texture support
    - Still under active development; expect some bugs
    - Front-end config will be polished for usability in next alpha release
 - All new SLES-based audio plugin by Gillou68310
    - Aims to be leaner and more accurate than old audio plugin
    - New default audio plugin, old plugin still available
 - core: Fix GameShark cheat codes not sticking
 - SDL2: Fix some thread key deletion issues in SDL 2.0.0
 - Upstream Mupen64Plus version is now 2.5

Front-end changes:
 - All new gallery screen by BonzaiThePenguin
    - Grid view with cover art
    - Recently played section
    - Search bar
    - Navigation drawers
    - Long-click gallery item to instantly resume game
    - Some reorganization of settings menus
 - Material Design look and feel in almost all areas of UI
 - More consistent look and feel across all Android versions
 - Lots of internal refactoring to facilitate UI overhaul
 - Fix launching from external app (e.g. file manager app)
 - Updated translations


Previous Builds:

Spoiler: "Previous Alpha Releases" • show

Alpha 1 (http://www.paulscode.com/source/Mupen64Plus-AE/06DEC2014/Mupen64Plus_debug.apk)
54dc749 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/54dc749)
 - Major refresh of front-end
 - See here (http://www.paulscode.com/forum/index.php?topic=1130.0) for design discussion

Alpha 2 (http://www.paulscode.com/source/Mupen64Plus-AE/07DEC2014/Mupen64Plus_debug.apk)
4f373fa (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/4f373fa)
 - Fix crashing when rebuilding the games list

Alpha 3 (http://www.paulscode.com/source/Mupen64Plus-AE/07DEC2014/Mupen64Plus_debug_a3.apk)
d26ab43 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/d26ab43)
 - Fix some games not selectable from gallery

Alpha 4 (http://www.paulscode.com/source/Mupen64Plus-AE/07DEC2014/Mupen64Plus_debug_a4.apk)
02c3da3 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/02c3da3)
 - Rename some things in ROM info cache to avoid confusion

Alpha 5 (http://www.paulscode.com/source/Mupen64Plus-AE/09DEC2014/Mupen64Plus_debug_a5.apk)
3e8dc4c (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/3e8dc4c)
 - Aggressively sync most diffs with upstream video-glide64mk2
 - Implement crash handler to save crash reports to disk
 - Update ACRA to more recent dev build
 - Add menu item in gallery for peeking at logcat

Alpha 6 (http://www.paulscode.com/source/Mupen64Plus-AE/10DEC2014/Mupen64Plus_debug_a6.apk)
10988f5 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/10988f5)
 - Show toast when saving screenshot
 - Add in-game menu item to save screenshots
 - Override new glide defaults in Alpha 5 (vsync, wrpAnisotropic, fb_read_always)

Alpha 7 (http://www.paulscode.com/source/Mupen64Plus-AE/11DEC2014/Mupen64Plus_debug_a7.apk)
fa36871 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/fa36871)
 - Toast diagnostic info if core fails to launch
 - Revert aggressive glide syncs from Alpha 5
 - Resync only benign diffs with upstream video-glide64mk2

Alpha 8
 (http://www.paulscode.com/source/Mupen64Plus-AE/23DEC2014/Mupen64Plus_debug_a8.apk) f012c42 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/f012c42)
 - Allow user to reset per-game settings to their defaults
 - Rename game-specific directories using immutable header info
 - Use a separate mupen64plus.cfg for each game (allow expert settings per-game)
 - Robustify ROM meta-info lookup
 - Add support for Android TV launcher
 - Change default vertical position from "center" to "top"

Alpha 9 (http://www.paulscode.com/source/Mupen64Plus-AE/23DEC2014/Mupen64Plus_debug_a9.apk)
225d958 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/225d958)
 - Core dynarec fix #1 (https://github.com/mupen64plus/mupen64plus-core/commit/77b0327)
 - Core dynarec fix #2 (https://github.com/mupen64plus/mupen64plus-core/commit/5c1c8cc)
 - Using vanilla upstream rsp-hle (https://github.com/mupen64plus/mupen64plus-rsp-hle/commit/5c86640)
 - Using vanilla upstream video-rice (https://github.com/mupen64plus/mupen64plus-video-rice/commit/a066f9e)
 - Partially sync other upstream modules

Alpha 10 (http://www.paulscode.com/source/Mupen64Plus-AE/23DEC2014/Mupen64Plus_debug_a10.apk)
652dd31 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/652dd31)
 - Simplify glide frameskipper implementation a bit
 - A bit more aggressive syncs with glide upstream

Alpha 11 (http://www.paulscode.com/source/Mupen64Plus-AE/01JAN2015/Mupen64Plus_debug_a11.apk)
e66efb3 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/e66efb3)
 - Update translations
 - Add Finnish (Suomi) language option
 - Rename emulation profiles and make Glide-Fast the default
 - Fix touchscreen not being disabled
 - Cancel ROM search if app goes to background
 - Core dynarec fix #3 (https://github.com/mupen64plus/mupen64plus-core/commit/751848a)
 - Core dynarec fix #4 (https://github.com/mupen64plus/mupen64plus-core/commit/e95f807)
 - Sync core fixes: Zelda (subscreen delay, end credits), Pokemon Snap (pass level 1, controller fix, picture selectable)
 - Using vanilla upstream core (https://github.com/mupen64plus/mupen64plus-core/commit/addef5f)

Alpha 12 (http://www.paulscode.com/source/Mupen64Plus-AE/01JAN2015/Mupen64Plus_debug_a12.apk)
762b18e (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/762b18e)
 - Remove most gl cache functions in glide (regressions expected)
 - Use upstream audio-resampling implementation
 - Using vanilla upstream audio-sdl (https://github.com/mupen64plus/mupen64plus-audio-sdl/commit/8cf8f17)

Alpha 13 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501031150_3beac96.apk)
3beac96 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/3beac96)
 - Add Fuhu Nabi 2 to hardware profiler
 - Remove all gl cache functions in glide (regressions expected)

Alpha 14 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501060902_6c2cc67.apk)
6c2cc67 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/6c2cc67)
 - Revert gl caching changes made to glide in Alphas 12 and 13

Alpha 15 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501101002_c7fb2b3.apk)
c7fb2b3 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/c7fb2b3)
Front-end changes:
 - Fix bug in MD5 calculation -> better ROM lookups
 - Use better ROM meta-info defaults if ROM not found

Alpha 16 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501172301_cbf2e50.apk)
cbf2e50 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/cbf2e50)
Front-end changes:
 - Add .nomedia files to exclude cover art, skins from Android photo gallery
 - Enable polygon offset hack to be disabled
 - Flatten global settings menu
 - Update game wiki URL to new site
 - Better detection/rejection of ROM files when searching
 - Fix bug in cheatfile merging on (re)install
 - Implement ROM extraction from zip archives
 - Separate directories holding cover art and unzipped ROMs
 - Rename directory GalleryData -> GalleryCache
 - Show ROM search/extraction progress in much greater detail
 - Provide easy cancellation of ROM search/extraction
 - Provide options to search zips, download art, and clear gallery when scanning ROMS
Upstream changes:
 - video-glide64mk2: ceabea7 correct N64 ROM header analysis for the regional PAL indication
 - core: Major refactoring (code cleanup) by bsmiles32 (no performance change expected)
 - Using vanilla upstream ui-console (https://github.com/mupen64plus/mupen64plus-ui-console/commit/3ddfb4d)
 - Using vanilla upstream video-glide64mk2 (https://github.com/mupen64plus/mupen64plus-video-glide64mk2/commit/1b96dbf)
Other notes:
 - Using vanilla upstream for all modules (http://www.paulscode.com/forum/index.php?topic=1861.0)

Alpha 17 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501282201_9c0c381.apk)
9c0c381 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/9c0c381)
Front-end changes:
 - Fix crash caused by corrupt zip files
 - Fix mapping issues with Amazon Fire controller
 - Add more logging during core startup and shutdown
 - Remove ACRA bug reporting system
 - Simplify global settings a bit
Upstream changes:
 - video-rice: Fix most regressions since 2.4.4
 - core: Fix audio latency

Alpha 18 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201502120902_02025b3.apk)
02025b3 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/02025b3)
Front-end changes:
 - Update translations
 - Add Arabic (Saudi Arabia) language option
Upstream changes:
 - core: Major refactoring and cleanup, no performance change expected

Alpha 19 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201503020802_99ce095.apk)
99ce095 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/99ce095)
Upstream changes:
 - core: Major refactoring and cleanup, no performance change expected
 - new_dynarec: Implement recompiled DMULT/DMULTU instruction on ARM
Front-end changes:
 - Fix auto-hold for touchscreen controls*
 - Fix Xperia Play touchpad skin (c-pad)
 - Fix editing/adding cheats with options
 - Simplify some under-the-hood JNI/thread stuff
 - Fix loading the auto-hold button images*
 - Add drag and drop touchscreen layout editing*
* Thanks to new contributor BonzaiThePenguin :)

Alpha 20 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201506072103_0488d08.apk)
0488d08 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/0488d08)
Upstream changes:
 - All new GLideN64 video plugin by gonetz (Sergey Lipskiy)
    - Aims to be most accurate of all video plugins
    - Variants for GLES 3.1, 3.0, 2.0 devices
    - Greatest accuracy/speed with newer GLES 3.1 devices
    - High-resolution texture support
    - Still under active development; expect some bugs
    - Front-end config will be polished for usability in next alpha release
 - All new SLES-based audio plugin by Gillou68310
    - Aims to be leaner and more accurate than old audio plugin
    - New default audio plugin, old plugin still available
 - core: Fix GameShark cheat codes not sticking
 - SDL2: Fix some thread key deletion issues in SDL 2.0.0
 - Upstream Mupen64Plus version is now 2.5
Front-end changes:
 - All new gallery screen by BonzaiThePenguin
    - Grid view with cover art
    - Recently played section
    - Search bar
    - Navigation drawers
    - Long-click gallery item to instantly resume game
    - Some reorganization of settings menus
 - Material Design look and feel in almost all areas of UI
 - More consistent look and feel across all Android versions
 - Lots of internal refactoring to facilitate UI overhaul
 - Fix launching from external app (e.g. file manager app)
 - Updated translations

Spoiler: "Diagnostic Test Builds" • show


Alpha 5b (http://www.paulscode.com/source/Mupen64Plus-AE/10DEC2014/Mupen64Plus_debug_a5b.apk) (Glide64 no rotation comparison) 4fe367f (https://github.com/paulscode/mupen64plus-ae/commit/4fe367fb77a14ea6152c63b9fcf6c40d68497b62)




Testing Guidelines:

Bugs in Rice video should only be compared to version 2.4.4 on the Play store.  Do not bother using or comparing Rice in Alphas 1-16.

Important note to all testers: [Starting from] Alpha 5 [the app] saves diagnostic crash logs to your SD card, which should help us track bugs down a lot faster.  They are timestamped and placed in <sdcard>/mupen64plusae-v3-alpha/CrashReports/.  If you observe a crash, please post the contents of a crash log here.

Rest assured that we will add an option to disable/clear crash logs in a future release.  For now testers will have to clear them manually (each one is a only few kB).

For those who are new to software development, a regression is a bug that did not exist in a previous build, but now exists in a new build.  In other words, a regression is a new bug.

It would help tremendously if testers could provide very specific information:
 1. What new bug are you seeing
 2. What is the first alpha version that displays the bug
 3. What is the last version that does not display the bug
 4. The exact ROM name as shown at the top of the play menu or in the gallery
 5. A savestate so that we can easily reproduce the problem
 6. Ideally, two screenshots of the same scene: one with the bug and one without the bug

Please try your best to answer all six items above, so that we don't have to keep asking more questions.  You can take savestates -- and now screenshots -- very easily using the in-game menu.
 - Savestates are saved to mupen64plusae-v3-alpha/GameData/<ROMname>/UserSaves
 - Screenshots are saved to mupen64plusae-v3-alpha/GameData/<ROMname>/Screenshots

If you find a bug that is (to the best of your knowledge) in all Alpha versions, please describe it in similar detail, and say it's a general bug that exists in all the Alphas.


Upgrade Notes:

testers will have to manually "Reload App Resources" when going from Alpha4 (or earlier) to Alpha5, and vice versa.  This is located in
    Global Settings->Data->Reload App Resources
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 06, 2014, 02:44:42 PM
Devs, anything that needs testing in preparation for 3.0.0, please post here (I will maintain the initial post with current links).  If the build is from a branch other than master (or from a personal fork), please include information for the other developers to find the source (fork, branch name, commit number, etc.. whatever is useful).
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 06, 2014, 09:59:09 PM
This is the first Alpha Test.  It is using a temporary grid view gallery that Littleguy developed until I get my UI integrated.

Alpha 1 (http://www.paulscode.com/source/Mupen64Plus-AE/06DEC2014/Mupen64Plus_debug.apk)

Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 06, 2014, 10:34:48 PM
Crashes when trying to load the GridView:
http://pastebin.com/7t997dWP

My n64 roms folder contains some zip files if that makes any difference.

Also question: are we targeting lollipop yet? If so, I'd recommend building against Java 1.7 instead of 1.6 if we aren't already.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 06, 2014, 10:56:15 PM
Looks like I implemented the comparator wrong (doesn't satisfy transitivity contract (a<b)&(b<c) implies (a<c)).  I'll push a fix in a minute.

We are indeed targeting Lollipop.  I didn't realize we could use Java 1.7.  What's the biggest benefit you see?
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 06, 2014, 11:24:05 PM
It's nicer for me because it means I only need JDK7 installed as I develop non android java stuff that uses 1.7 features.
I didn't notice too much different, but I think it's good to target the newer version.

Lint will yell at you after the initial switch, but it's pretty smooth after that.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 06, 2014, 11:34:22 PM
Crash fixed and posted.  Sorry for crashing right out of the gate.  :-[
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 12:22:02 AM
Oh! So I must have grabbed it just after you fixed it. LOL

On the alpha,there is a regression in Rice,it is a minor one luckily.
The cutscene borders in Banjo-Tooie are no longer clearing properly,leaving the previous frame in its place instead.
The top half has weird film reel for some odd reason.

Cool thing about Rice now is that it appears to run even faster,thanks!
I noticed the eight OpenGL settings on the ini changed to three.

Edit:Smash bros. on Rice has the level model positioning fixed,but is still cluttered with buffer garbage and horrendously slow.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 02:46:45 AM
Forgot to mention the alpha crashes into the applist when exiting from games enough times.
It happenned when testing Smash Bros. with Rice on my FireTV.
Title: Re: 3.0 Alpha Testing
Post by: Questwizard on December 07, 2014, 06:14:59 AM
Just tested on my Nexus 4 running CM10.1 and I can't seem to get a game to load. Set the rom folder, SM64 (only game i have) showed up, but tapping it, long pressing, and everything else I try results in no response whatsoever. The rom is not zipped.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 08:02:17 AM
Latest build:

Alpha 2 (http://www.paulscode.com/source/Mupen64Plus-AE/07DEC2014/Mupen64Plus_debug.apk)

This one fixes the problem where the app crashes when refreshing the games list.

It still has the issue where some games (like SM64 and DK64 in my case) do nothing when you press them.  Questwizard mentioned having the same problem in the previous post.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 07, 2014, 08:28:32 AM
All of my goodset [!] Roms can be loaded except for SM64 rumble edition. I'll have to check the hash on that one. The .n64 Roms that come from a certain site that converts all of them into the same format in terms of byteswapping do not load.

@littleguy This is a case where the game config selector would be used
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 08:52:08 AM
Which format are they converted to?  I know I have changed the extension on several of my own ROMs so that it probably doesn't match the actual format (it is typically simple to detect the format from the data itself, not the extension -- certainly the core does this or it wouldn't be able to load them)
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 08:59:19 AM
https://github.com/mupen64plus-ae/mupen64plus-ae/blob/master/jni/mupen64plus-core/src/main/rom.c#L94

Which is translated to Java here:

https://github.com/mupen64plus-ae/mupen64plus-ae/blob/master/src/paulscode/android/mupen64plusae/util/RomHeader.java#L139

How does changing the format come into play here?  Guess I don't understand the problem yet..
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 09:00:36 AM
Can anyone check the logcat when they tap a game that doesn't load?  There may be some diagnostic messages there.

xperia64 - Yes, I understand what you meant by a selector if the game isn't in the core's list.  I added it as a todo.  This is the current logic for dealing with a rom that's not in the list:
https://github.com/mupen64plus-ae/mupen64plus-ae/blob/4f373fa529fdf4f9538010c585bbf05d9b8ba423/src/paulscode/android/mupen64plusae/PlayMenuActivity.java#L131
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 09:04:04 AM
Why am I the only one without any crashing in that scenario?
All of my files are in the .z64 file extension and the cover art is downloaded.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 09:04:46 AM
This is the current logic for dealing with a rom that's not in the list:
https://github.com/mupen64plus-ae/mupen64plus-ae/blob/4f373fa529fdf4f9538010c585bbf05d9b8ba423/src/paulscode/android/mupen64plusae/PlayMenuActivity.java#L131

This looks to fallback to looking up by CRC.  https://github.com/mupen64plus-ae/mupen64plus-ae/blob/4f373fa529fdf4f9538010c585bbf05d9b8ba423/src/paulscode/android/mupen64plusae/PlayMenuActivity.java#L136

So in the case of the particularly formatted ROMs, does the CRC also get loaded wrong?  I'll have to investigate this more closely I guess to understand the problem better.

--EDIT-- Also, it correctly loads the cover art for the two ROMs in question, so at some point the logic does recognize it.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 09:10:06 AM
Just found that a romhack with capatilized "Z64" on the extension fails to open when touched.
Not sure if the romhack is the issue or if it is the file format casing.

Edit:It must be a CRC issue because none of my romhacks open their settings. :(
Has anyone tried renaming a game that opens,to a higher case Z64,V64,or N64 respectively on the extension?
How about if yours are already like that,try changing them to lower case extensions.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 09:12:19 AM
That leads me to believe that somewhere in the logic, a string compare is being done against the extension (versus determining the format based on the header data).  I'll see if changing the extension of my problem ROMs has any affect (I'm pretty sure the .n64 extension is wrong -- changed it way back when the app was in its infancy and I had to hard-code the filename)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 09:16:53 AM
The accepted formats are n64,v64,and the most widely used z64 format.
I edited my previous post.

Edit:If it matters,the other versions load all my romhacks just fine because it must be ignoring their improper CRCs
Edit2:...and/or MD5 as well probably.

It is a bad method for romhack enthusiasts like myself.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 09:18:52 AM
Logcats?

As I pointed to in the code, here's what currently happens
 - Tries to lookup by MD5
 - If it fails, it looks up by CRC, which can produce 0, 1, or many matches
 - If it finds many matches, it just selects the first (in the future will popup to give user choice)
 - If it finds no matches, it parses the filename to guess goodname and art path
    - that's why unknown roms can still show cover art; the rom filename alone contains enough information
    - if this last fallback is used, the gallery displays the filename (with extension) rather than the true "good name"
    - i.e. you can tell by inspection in the gallery activity which roms are unknown to the core
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 09:22:53 AM
Thanks, confirmed that extension has nothing to do with the logic (just to put that to rest).  Changed the filename to all possible extensions, and also changed some of the working ones.  Working ones still worked, and the other two still don't open.  All three formats are supported, so it is not related to one of the three formats not being supported either.

So I understand the logic path there.. CRC can produce many matches to MD5.  But it is CRC that should be unique to the game, correct? (for things like cheats, etc).  Guess I'm still lacking the last piece of the puzzle -- what specifically in the process causes it to not open anything when you press the game (is it assuming I must have a specific MD5 match?)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 09:25:05 AM
Look At The Logcats!  I put stuff in there for a reason.  We could have avoided this long-winded discussion
Code: [Select]
12-07 10:23:56.949: E/GalleryActivity(23882): No ROM detail available
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 09:27:50 AM
Sorry, I am just trying to understand the process.  A logcat message like that makes assumptions that I understand why no ROM data available prevents the menu from opening.  I'll just look at the code, no need to continue the conversation (this is mainly due to my being out of the loop for several months.. I'm sure this is old news for you and xperia)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 09:33:00 AM
The master dictionary used by the core is mupen64plus.ini.  MD5 is guaranteed to be unique to a ROM, so it is used as the unique identifying key.  Multiple entries in the dictionary can have the same CRC (just look at the entries for some popular roms).  I.e. different quality rips of the same game.  When the app loads, it loads the game data into a java dictionary object, keyed by md5.  It also constructs a second dictionary, keyed by CRC.  The second dictionary's elements are themselves lists (i.e. one crc keys to a list of candidate roms).  Then RomDetail.java uses those dictionaries when the GalleryActivity queries them.

There's only one place where the file extension matters, and that's before the gallery is refreshed.  It uses a non-case-sensitive filter to locate potential roms on the user's disk.  After that it uses only the RomDetail and RomHeader class to get all rom meta-info.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 09:36:59 AM
For problem games and romhacks to load,it needs to be forced to unknown and the filename instead of completely refusing to load them at all.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 09:38:41 AM
I found the problem.  It's a refactoring bug.  I'll push a fix soon.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 09:39:20 AM
When the app loads, it loads the game data into a java dictionary object, keyed by md5.  It also constructs a second dictionary, keyed by CRC.  The second dictionary's elements are themselves lists (i.e. one crc keys to a list of candidate roms).  Then RomDetail.java uses those dictionaries when the GalleryActivity queries them.

Ok, so if I understand this correctly, in the case where a game does not load, then the second dictionary found no matches by CRC?
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 09:45:48 AM
I found the problem.  It's a refactoring bug.  I'll push a fix soon.

Oh, cool..  I was all geared up to argue when you answered "yes" to my previous question.  Feeling ornery today  ;D
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 10:03:55 AM
For problem games and romhacks to load,it needs to be forced to unknown and the filename instead of completely refusing to load them at all.

In the case where MD5 and CRC were not recognized, I would agree with that.  In the case where there are multiple MD5s for the CRC, I would default to the "refMD5" (I think that is unique, but will have to analyze the ini data to verify) and then we give them a menu for changing it if they like.  I'll take this on, unless someone else already has started on something similar.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 10:12:32 AM
I pushed the fix.

RefMD5 is already taken care of in RomDetail.  See the comments in the code.  A truly unknown game is one without any MD5 or CRC reference anywhere in mupen64plus.ini.  So there's basically nothing that can be inferred about the game other than its filename and its header.

If lookupByMd5 returns null and lookupByCrc returns multiple entries, that means that the MD5 cannot be found anywhere in the ini file (neither the md5 key nor the refMd5 field).
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 07, 2014, 10:47:53 AM
Good, also, can you create a .no media file in the GalleryData folder? Don't want the covers in my pictures
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 10:57:23 AM
Good idea, never knew about that.  Should we keep save-related screenshots out as well?  What about user-generated screenshots (manual screenshots)?

http://android2know.blogspot.com/2013/01/create-nomedia-file.html
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 11:11:55 AM
If lookupByMd5 returns null and lookupByCrc returns multiple entries, that means that the MD5 cannot be found anywhere in the ini file (neither the md5 key nor the refMd5 field).

Ok, I have been looking through this part of the code to get better familiar with the process.  Just to follow the logic through a make-believe scenareo (to make sure I understand it correctly -- point out if I get things wrong)

1) I hack a small piece of my Mario64 ROM, so that the MD5 changes from 20B854B239203BAF6C961B850A4A51A2 to something else I'll refer to as [XXX..], but CRC remains the same: 635A2BFF 8B022326.  (other scenarios this could might happen is if some unusual procedure is applied to alter the data of an otherwise-recognizable ROM, as xperia64 mentioned, or if I pick up some extra junk data when I am dumping my ROM, as currently is the case of my other project)

2) The new MD5 [XXX..] is now nowhere in the ini file, but the CRC is in the ini file 5 times under various other MD5s for Mario64 ROMs, all of which have the RefMD5 of 20B854B239203BAF6C961B850A4A51A2.

3) The app finds the ROM file, and lookupByMd5 fails because [XXX..] is unique and unrecognized.

4) The app then runs lookupByCrc, and finds 5 matches.   Logic uses the "assumed MD5" from RefMD5 of the first match, which in this case is 20B854B239203BAF6C961B850A4A51A2



So if I am on the right page, there are a couple scenarios left to resolve:

1) If there are more than one match on CRC and the first match doesn't have a RefMd5, then the logic doesn't know which section to use.

2) If neither the MD5 nor the CRC are recognized, then the logic doesn't know which section to use.



One possible solution (let me know if this jives with the process or not), would be to create a second ini file (I'm pretty sure I recall reading about this on here a while back, so not trying to sound like I came up with that idea myself).  Process would work something like this:


1) Try to find the ROM by MD5 in the default ini file first

2) If not found, try finding the ROM by MD5 in the second ini file

3) If still not found, try finding the ROM by CRC in the default ini file

4a) If found and has only one match, create a new entry in the second ini file with the new MD5 and values cloned from the match.

4b) If found, and has a RefMd5, create a new entry in the second ini file with the new MD5 and values cloned from the RefMD5 entry.

4c) If found, and does not have a RefMd5, create a new entry in the second ini file for the new MD5 and some default values

4d) If not found period, create a new entry in the second ini file for the new MD5 some default values
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 11:26:31 AM
Let me read through this carefully and respond after lunch.  But I want to point out one quick thing.

refMD5 in mupen64plus.ini is not important; it's just an internal mechanism used by the core to keep the ini file smaller and easier to maintain.  That's why it's not even stored as a field in RomDetail (see the comments in the constructor).  It is theoretically possible that two entries in mupen64plus.ini have the same CRC and neither contains a refMD5 field that refers to the other.  The true, calculated MD5 of the ROM is the unique key that matters.

Edit: Please pull the latest.  I renamed something in the front's rom info cache to avoid confusion.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 11:29:37 AM
Latest build:

Alpha 3 (http://www.paulscode.com/source/Mupen64Plus-AE/07DEC2014/Mupen64Plus_debug_a3.apk) (Fix some games not selectable from gallery)


refMD5 in mupen64plus.ini is not important; it's just an internal mechanism used by the core to keep the ini file smaller and easier to maintain.  That's why it's not even stored as a field in RomDetail (see the comments in the constructor).  It is theoretically possible that two entries in mupen64plus.ini have the same CRC and neither contains a refMD5 field that refers to the other.  The true, calculated MD5 of the ROM is the unique key that matters.

Agreed, which is one argument for always creating a new entry (in a second ini file for example) when an unrecognized MD5 is encountered.  The RefMD5 would only be used for guessing initial values (we would need to provide a UI for the user to change them, since the assumption could be wrong).
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 11:43:09 AM
Please pull the latest.  I renamed something in the front's rom info cache to avoid confusion.

Alpha 4 (http://www.paulscode.com/source/Mupen64Plus-AE/07DEC2014/Mupen64Plus_debug_a4.apk) (Rename some things in ROM info cache to avoid confusion)
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 11:53:20 AM
refMD5 in mupen64plus.ini is not important; it's just an internal mechanism used by the core to keep the ini file smaller and easier to maintain.


Ah, yes, I see.  Basically says "use all the settings from that section, plus these here in this section".  In that case, I would change my above recommended process a tad:


1) Try finding the ROM by MD5 in the second ini file first (checking this first would allow us to eventually provide an option to override default settings and easily "undo" them)

2) If not found, try to find the ROM by MD5 in the default ini file second

3) If still not found, try finding the ROM by CRC in the default ini

4a) If found and has only one match, create a new entry in the second ini file with the new MD5 and values cloned from the match.  If the one match has a RefMD5, use combined settings from both -- do not add a RefMD5 to the new entry (will allow user to customize all the settings)

4b) If found and has multiple matches, create a new entry in the second ini file with the new MD5 and values cloned from the first match, combined with settings from RefMD5 section if present -- do not add a RefMD5 to the new entry (will allow user to customize all the settings).

4c) If not found period, create a new entry in the second ini file for the new MD5 and some default values




-- EDIT--

BTW, the reason I recommend making a "best guess" about which section to use and allowing the user to change it later, is because most of the time, the best guess will be enough to get the average user up and playing (and not requiring them to make a selection they probably won't understand anyway).  Advanced users will be smart enough to select what they want later.  Any problems created for average users due to incorrect "best guess", they will come here and we can assist them in selecting the right settings.

-- EDIT 2 --

Also, to save time when launching the game, we really wouldn't need to merge the two ini files.  Instead, we could just output a small ini file with only the one entry for the game being launched.  This could also be applied to cheats.  We know what game is about to be launched, so no need to pass the core huge files with data for all possible games.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on December 07, 2014, 11:56:10 AM
Alpha 4

exiting game crashes everything

Roms in Zip files "load" now, but doesn't play...

Thank you.

Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 12:33:49 PM
On my FireTV,a romhack titled "Super Irishly Drunk Giant Waluigi 64" opens and runs properly.

Also,a Zelda Debug romhack called Voyager runs,but still freezes on exiting the pause menu when using Rice.
It does not freeze in Glide normally,maybe the original debug rom also freezes in the same way.
Garbage data in the pause menu background is similar to Smash Bros. also seen with Rice.
Again,Rice is running faster when it can,but now struggles more with lag in heavy rendering views.

Glide64 is suffering with black texture spots with characters from character select on Super Smash Bros. via the Alpha.
It does not happen on Gillou's latest build since last time I checked. (going to check again brb)

Edit:Crash after game exit again with Smash Bros. on latest alpha,about to check Glide64 now.

Edit2:No black texture,but it got the bright flashing glitch with Super Smash Bros. this time.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 12:54:52 PM
DP

Glide64 is also horrendously slow on the alpha with Super Smash Bros.,even with "read every frame" disabled,which is a major issue.

My Intel tablet did not get a crash with Super Smash Bros. when exiting it this time.
FireTV crashed every single time when exiting that game.

Edit:It must like my Intel because it is not lagging on it in that way.
First run had invisible elements like it usually does when switching plugins,but secondary run in different session looks fine.

Something was botched for ARM since it lags on my FireTV compared to Gillou's build not lagging.

Edit2:It is now letting me hit the device's back button to get out of the game settings after exiting a game.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 07, 2014, 01:52:52 PM
Alpha 4:

All games load just to a black screen, regardless of core selected.

DK64 has .zip at the end of the name. (only rom that does this)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 02:47:50 PM
The zip extraction needs to be re-inserted IIRC.  Xperia64 had implemented that on a separate branch; it should be cherry pickable.  See my fork of mupen64plus-ae.

@Zaneris - What do you mean "all games load to black screen" and "dk64 is only rom that does this"?
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 07, 2014, 02:57:01 PM
The .zip DK64 title. http://i.imgur.com/0WRgDOL.png

And black screen on loading games. http://i.imgur.com/EgyXuwdh.jpg
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 03:10:22 PM
Note to testers A LOT HAS CHANGED IN THE FRONT-END for the alpha version.  Most settings are now encapsulated into "profiles".  This allows you to "set and forget" settings for a game, and they will always be used regardless of the settings for a different game.

If you were using frameskip before, you should use one of the "Speed" emulation profiles.

Also, in case of crashes, try Restart (not Resume) from the Play menu.  This is especially important when updating to a different alpha release.

We need to get this "Gilles' build" on the forum, along with the commit reference to the source code.  Continual comparisons to something I don't have is completely unhelpful.

BTW hyperboles like "botched" and "horrendous" are loaded with emotion that is easy to misinterpret.  Better to simply say "broken", "crashes", "black screen", "slower than [some other build]", etc.  Keep it factual please.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 04:09:28 PM
@Paul - You hit it pretty much on the head.  I'll just clarify a few subtleties as I was imagining it:

Ah, yes, I see.  Basically says "use all the settings from that section, plus these here in this section".  In that case, I would change my above recommended process a tad:

1) Try finding the ROM by MD5 in the second ini file first (checking this first would allow us to eventually provide an option to override default settings and easily "undo" them)

2) If not found, try to find the ROM by MD5 in the default ini file second

3) If still not found, try finding the ROM by CRC in both ini files (possibly some from the first and some from the second)

4a) If found and has only one match, create a new entry in the second ini file with the new MD5 (i.e. the actual computed MD5) and values cloned from the match.  Populate the entry as a principal entry (i.e. all fields filled except refMD5, just like the default file does).

4b) If found and has multiple matches, select the first one (or prompt the user to select one) and then do 4a)

4c) If not found period, create a new entry in the second ini file for the new MD5 and some default values (rumble=true, players=4, goodname generated from filename)


For 4c (and possibly 4a and 4b) we may want to popup a pre-filled form to allow the user to modify the info.  For 4a and 4b we might want to tweak the goodname so that the user can distinguish versions.

Instead, we could just output a small ini file with only the one entry for the game being launched.  This could also be applied to cheats.

Great idea!
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 07, 2014, 04:16:51 PM
So yeah, my bad on not noticing zip support had been removed, searching for bugs now. (Games run fine when extracted).

I'm also in favor of removing options from the user. Having it default to best core for the game is more than good enough, and hide away the advanced settings to make it less intimidating. Might I also suggest a first run type popup or equivalent for them to locate where their Roms are located?

Edit: Also some haptic/visual feedback on selection of a rom or a loading wheel of some sort due to the slightly longer load time for the resume/restart menu. And on that note, have you considered removing that menu entirely and just auto resume?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 04:30:04 PM
Might I also suggest a first run type popup or equivalent for them to locate where their Roms are located?

Yeah, I was thinking we could have a popup on launch whenever the "found ROM" count is zero.  Or the gallery would have a tile called "Refresh Roms" that is obvious on first launch

Having it default to best core for the game is more than good enough, and hide away the advanced settings to make it less intimidating.

We're still a ways from being able to do that, but indeed that is one of the reasons we reworked the whole front-end settings systems.  When we're ready to do that it will be relatively easy to add a master file that lists default profiles for each game.  Another feature of the new system is that people can share their profiles just by sending their config files from mupen64plusae-v3-alpha/Profiles.

Also some haptic/visual feedback on selection of a rom or a loading wheel of some sort due to the slightly longer load time for the resume/restart menu.

Yes, there would be something like that in the carousel front-end Paul is creating.  Remember, the gallery screen in these first alphas is just a simple stand-in and is intentionally barebones.

And on that note, have you considered removing that menu entirely and just auto resume?

Yes, the real gallery will allow you to jump directly from the gallery to the game if you select certain tiles, or go to the Play menu if you select other tiles.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 07, 2014, 04:32:09 PM
Noticed the filenames for save files are a bit whacky at the moment, not sure if it's just a placeholder or not.

http://i.imgur.com/1Vp3P9w.png
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 04:35:48 PM
Also some haptic/visual feedback on selection of a rom or a loading wheel of some sort due to the slightly longer load time for the resume/restart menu. And on that note, have you considered removing that menu entirely and just auto resume?

Resume and restart will no longer be menu options, but instead you will have a "Resume Playing" carousel for resuming, and the main carousel with the ROMS+cover art for restarting (clicking on the latter will probably give a dialog to ask the user if they want to resume or restart, though.. so not sure we will have reduced the clicks much there)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 04:38:24 PM
Noticed the filenames for save files are a bit whacky at the moment, not sure if it's just a placeholder or not.

http://i.imgur.com/1Vp3P9w.png

Yes, placeholder.  Right now we are just using the same old auto-save system but eventually we will have multiple auto-saves in case the last one is screwed up.  They might be time-stamped for clarity and uniqueness.  That was what I was conveying to the other devs in that name.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 07, 2014, 04:48:07 PM
US version of Zelda Ocarina of Time id'd as Japanese (not sure what can be done about this)
http://i.imgur.com/36Ookhr.jpg
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 05:11:12 PM
For 4a and 4b we might want to tweak the goodname so that the user can distinguish versions.

As long as they can edit it, they can give it whatever good name they like.  If they don't like having two games in their list with the same name, they can just rename one of them.

The way I'm imagining, user can long-press a game to go to its settings, where (among the other settings, cheats, and so on) they can find options for changing the various fields from the INI (rename should probably not be considered an "Advanced" feature though, IMO).

If we do a prompt for the match selection, we could make the good name editable from there as well.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 05:16:36 PM
Haha Zaneris just showed exactly why we should let the user select the most appropriate rom when there are multiple matches :D
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 05:17:33 PM
Haha Zaneris just showed exactly why we should let the user select the most appropriate rom when there are multiple matches :D

Yes!
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 05:26:10 PM
Resume and restart will no longer be menu options, but instead you will have a "Resume Playing" carousel for resuming, and the main carousel with the ROMS+cover art for restarting (clicking on the latter will probably give a dialog to ask the user if they want to resume or restart, though.. so not sure we will have reduced the clicks much there)

Perhaps clicking from the "Resume Playing" row jumps straight to GameActivity, whereas clicking from the "All Roms" (or whatever we're calling it, with the cover art) jump to the PlayMenuActivity, just like it does now.  That would keep it simple and would make it obvious when first launching a ROM that there are settings associated with each game.  So basically like it is now, with the top row being shortcuts that bypass PlayMenuActivity and save the user a click.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 05:36:15 PM
I was thinking of making the top view in the vertical adapter a text view.  A simple single-line that says "Long-press a game for more options".  I would like to keep the PlayMenuActivity out of the picture until the user is comfortable enough with the app to start messing around.  Maybe we can try it both ways and have the users vote which way they prefer.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 05:43:15 PM
Along the same "dumbing it down" lines, I was thinking of using the same line of text (or possibly a link in the popup if we initially start with a dialog for searching for ROMs) that says something like "How do I get games?"(linking them to information about what a ROM is and where they come from).
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 05:52:31 PM
I would like to keep the PlayMenuActivity out of the picture until the user is comfortable enough with the app to start messing around.

The other idea might be to dumb down and "prettify" the PlayMenuActivity itself to look like a typical profile page for some app:

(http://blog.mhcache.com/en/wp-content/uploads/2013/01/iPhone_edit-info3.jpg)

( that was the first image I googled, ignore the fact that it has two screens or that it is an iPhone ;D )

In other words, basic stuff that everyone can understand at the top (changing the name, changing the picture, playing, resuming) and more advanced stuff down further (and possibly collapsed into accordions).
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 05:59:54 PM
You know.. eye candy.  Rounded bubbles, different font weights and sizes, nice bitmaps, and so on.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 06:03:09 PM
In other words, basic stuff that everyone can understand at the top (changing the name, changing the picture, playing, resuming) and more advanced stuff down further (and possibly collapsed into accordions).

So basically what it already is, with a few new options at the top?   ???
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 06:04:55 PM
Right now it is a settings menu.  I'm talking about making it into a profile page like for a social network type of app.  I'll play around with it and post some mock-ups.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 06:13:54 PM
I'm talking as drastic a face-lift as it is going to be coming from this in 2.x:

(http://www.paulscode.com/source/Mupen64Plus-AE/screenshots/mupen64plus_2.x_menu.png)

To something like this in 3.x:

(http://www.paulscode.com/source/Mupen64Plus-AE/misc/mockup_ui.png)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 06:21:26 PM
As long as it doesn't delay the Gallery I say go nuts on it  ;D
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 07, 2014, 06:24:42 PM
No, I'll do the gallery first.  Then I'll take on the PlayMenuActivity challenge  8)
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 07, 2014, 07:07:32 PM
Someone on reddit did an interesting material design  inspired emulator mockup as well which looks not half bad.

http://imgur.com/a/h6bqO
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 07:31:41 PM
That looks awesome.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 07, 2014, 07:48:24 PM
Hope you don't drop the dark theme completely,I always play in the dark to avoid screen glare which gets worse when fingerprint smearings are all over my touchscreen.

Or why not go nuts with custom themes!
To cut down on RAM usage,you could publish a seperate app just for customizing the theme.

Or simply add a color editor for each individual element.
Title: Re: 3.0 Alpha Testing
Post by: Sowden on December 07, 2014, 08:34:22 PM
Hey guys.  Glad to see you guys working on this program again, the Alpha looks great.  Got a couple of things about it though.  First is the most important.  I love the game selection screen with the downloaded game images.  I use my N64 (using the raphnet adapter) to control the emulator and to a greater extent, my tablet.  I can move through the selections of games, but there is no highlight for the one the cursor is on.  I can guess if I hit down, then count up 2, for example, to select the game I want.  But I have no other indication that it is highlighted.  If I could ask for some highlight option, that would be awesome.  Also I have been having some random crashes when I leave games to go back to the menu.  I haven't pinpointed where that error occurs, but if I can reproduce it, I'll post a logcat.  Anyway, thanks for your work guys, later.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 07, 2014, 09:11:34 PM
Thanks Sowden.  Good to see you back. :)  The current interface is just temporary while the real one gets built.  It's meant to be minimally functional, just enough to let alpha testers put the real app (the core!) through its paces.
Title: Re: 3.0 Alpha Testing
Post by: Sowden on December 07, 2014, 10:46:16 PM
 :) Gotcha.  And hey, I guess it slipped right by me.  But both James Bond and Perfect Dark work with two players!  ;D  However, Goldeneye only lets me assign one controller.  For other multiplayer games that let you assign what controller does what, Goldeneye only has a selection for one controller.  Is there a bug or am I doing something wrong?  Thanks guys.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 08, 2014, 11:13:03 AM
One other issue,using fastforward on the alpha causes immense slowdown when I used it in Smash Bros. on a four DK match in Hyrule.
It does not have this issue in Gillou's build,it normally just tries to go faster without causing additional lagging.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 08, 2014, 11:15:25 AM
WHERE IS GILLOU'S BUILD

We can't fix what we can't compare.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 08, 2014, 12:18:43 PM
WHERE IS GILLOU'S BUILD

We can't fix what we can't compare.

Lol, don't worry, your frustration is shared.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 08, 2014, 12:23:25 PM
Seriously?  :o

His dropbox folder with SplashActivity.apk in it on the first post IS Gillou's build.

http://www.paulscode.com/forum/index.php?topic=1797.msg13298#msg13298

Edit:You should probably hurry up and grab it before he overwrites it again.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on December 08, 2014, 12:34:36 PM
Too late I removed it to avoid confusion ;)
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 08, 2014, 01:36:18 PM
Too late I removed it to avoid confusion ;)
Classic Gillou.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 08, 2014, 02:17:19 PM
Gilles - do you have a commit reference at least, so devs can track down these performance differences retroben keeps discussing?
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 08, 2014, 02:44:02 PM
Noticed another issue with it,input gets disabled briefly when using fastforward,even for a few seconds.
I think it is because the short pause was replaced by a brief slowdown to keep the game going when fastforward was released.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on December 09, 2014, 12:15:17 AM
Gilles - do you have a commit reference at least, so devs can track down these performance differences retroben keeps discussing?

This is probably caused by the framelimiter:
https://github.com/Gillou68310/mupen64plus-ae/commit/b9d115774b6bb80e8c1d40c55594e2e2961fad1c (https://github.com/Gillou68310/mupen64plus-ae/commit/b9d115774b6bb80e8c1d40c55594e2e2961fad1c)
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 09, 2014, 05:48:40 AM
Posting the latest build:

Alpha 5 (http://www.paulscode.com/source/Mupen64Plus-AE/09DEC2014/Mupen64Plus_debug_a5.apk) (Sync glide64, crash reporting)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 06:50:50 AM
Important note to all testers: Alpha 5 saves diagnostic crash logs to your SD card, which should help us track bugs down a lot faster.  They are timestamped and placed in <sdcard>/mupen64plusae-v3-alpha/CrashReports/.  If you observe a crash, please post the contents of a crash log here.

Rest assured that we will add an option to disable/clear crash logs in a future release.  For now testers will have to clear them manually (each one is a only few kB).
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 09, 2014, 07:18:55 AM
Thanks, littleguy, I quoted you in the OP as well.
Title: Re: 3.0 Alpha Testing
Post by: gdark100 on December 09, 2014, 09:40:52 AM
Very good to see Paul is back, and the project is progressing again! Tested the Alpha 3 yesterday, and the only problem I noticed was the lack of compressed roms support, also the cover art for zipped roms doesn't appear, but they are recognized and added to the list. Also Conker's Bad Fur Day still slow as ever here :P

Also would be good to add the new strings to Transifex, so we can start working on translation, and it would be already done in the release date.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 09, 2014, 10:30:46 AM
Important note to all testers: Alpha 5 saves diagnostic crash logs to your SD card, which should help us track bugs down a lot faster.  They are timestamped and placed in <sdcard>/mupen64plusae-v3-alpha/CrashReports/.  If you observe a crash, please post the contents of a crash log here.

Rest assured that we will add an option to disable/clear crash logs in a future release.  For now testers will have to clear them manually (each one is a only few kB).

Did you take into consideration that kit kat doesn't have write access to the SD card?
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2014, 10:37:34 AM
How is that the case when save files are on my Intel x86 KitKat 4.4.4 tablet and all other essential files as well?
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 09, 2014, 10:39:56 AM
That just threw me for a loop... why would access to the SD card have been removed?  What good is the SD card at that point?  I'll have to do some googling on the subject sounds like.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2014, 10:58:30 AM
Alpha 5:No graphical hiccups with Glide64 on Majora's Mask so far on my Intel x86 tablet. :)
Edit:I am now back.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 09, 2014, 11:30:27 AM
That just threw me for a loop... why would access to the SD card have been removed?  What good is the SD card at that point?  I'll have to do some googling on the subject sounds like.

No idea, but it's one of the main reasons I rooted my S5, to gain write access to my own SD card. Supposedly a better solution has been implemented in lollipop though.

Edit: I'll clarify further, apps have write access to their own android/data folder on extSdCard but are unable to write anywhere else without changing the permissions via root.
Limited exclusively to kit kat.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 09, 2014, 12:15:42 PM
Aha, so the idea is that I can write to the SD card, but only to my own folder on it (idea was to prevent modifying data from other apps, presumably).
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 12:39:05 PM
I'd need to do some reading to confirm this, but I'm guessing that there are no issues with the current implementation on unrooted KitKat.  First, because I haven't heard a single complaint, and second because we use the default storage directory that the Android API itself promotes.
Code: [Select]
storageDir = Environment.getExternalStorageDirectory().getAbsolutePath();
I think the confusion lies in the original nomenclature Android used for storage.  For devices without SD cards (e.g. 2012 Nexus 7), the "external" storage area is actually just a directory in internal memory (/storage/emulated/0).  IIRC when it was first released that drive was named /storage/sdcard/0 or something.  On the other hand, my Jellybean phone has an sdcard, and the "external" storage area referenced by the above method is actually a directory in internal memory (/storage/sdcard0).   Then the true external sd card is mapped to /storage/extSdCard.  Confused yet?  Me too.

Bottom line, by default we use the "safe" recommended location for saving user data, by calling the Environment method.  So we have nothing to worry about.  If an unrooted KitKat user chooses to move their data to a non-default location on an actual removable SD card, I suspect that the app would crash or behave abnormally.  I suspect they would be getting similar crashes with other apps, and maybe (just maybe) they would google it to see what was going on.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 12:52:10 PM
From the official docs (http://developer.android.com/reference/android/os/Environment.html#getExternalStorageDirectory()) on "external storage directory" that we write to:

Quote
Note: don't be confused by the word "external" here. This directory can better be thought as media/shared storage. It is a filesystem that can hold a relatively large amount of data and that is shared across all applications (does not enforce permissions). Traditionally this is an SD card, but it may also be implemented as built-in storage in a device that is distinct from the protected internal storage and can be mounted as a filesystem on a computer.

Writing to this directory requires manifest permissions to be declared, which we have already been doing for years now.

Also, don't be confused by this discussion:

Quote
Applications should not directly use this top-level directory, in order to avoid polluting the user's root namespace. Any files that are private to the application should be placed in a directory returned by Context.getExternalFilesDir, which the system will take care of deleting if the application is uninstalled.

<snip>

Starting in KITKAT, if your application only needs to store internal data, consider using getExternalFilesDir(String) or getExternalCacheDir(), which require no permissions to read or write.

We do NOT want to save user data to the value returned by Context.getExternalFilesDir because it gets completely wiped on uninstall.  The only thing we put in that directory is stuff that we actually DO want to be wiped on uninstall, which are the read-only assets that are always extracted on reinstall.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2014, 01:19:09 PM
Terrible news for my Fire TV test.
It is now immensely lagging with Glide64 on Super smash bros. at a sluggish 30fps with four DKs on Hyrule.
Regularly,it would be 50fps-60fps.
It even lags more immensely on character select.
Hate how I can't compare anymore with Gillou's creation,but it does run smash bros. much faster.

Also,here is a crash log from exiting the game.

http://www.2shared.com/document/z7arV0jl/Crash_2014-12-09_11-13-22_411.html

I also get frequent audio crackling,even when full speed on the menu.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 01:35:00 PM
Thanks for the crash report.  Is the device rooted?  The logcat didn't get recorded.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2014, 01:47:42 PM
Strange,I have root access on my FireTV.

Forgot to mention that SM64 and Zelda floors are shaking on my Intel tablet,not yet sure for FireTV.
Just minor shaking when at certain camera angles,so it is no longer as bad.

Zelda OOT has painful lagging in fastforward on FireTV and can barely maintain 60fps on the save file menu.
I think the fast forward method needs to be reverted if that is what cripples the performance,as Gillou's version runs insanely fast on Zelda OOT with the original fastforward method working seamlessly.
Hopefully Gillou at least left the source code of his version available to look at in comparison of fastforward and Glide64.

It could partially be a major Glide64 regression though.
Also forgot to mention a few other things.

On both of my devices using Glide64,Link's pause model is funnily missing his torso,and the beginning logo in SSB has the left half missing.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2014, 02:19:47 PM
Hate to say it,but Glide64 is having the big problems.
It was to be expected.

Banjo-Tooie even has some missing elements (some egg icons missing) and part of the jigsaw effect is glitching out.
The previously mentioned Link's pause model torso also caused by it.

This always happens,you fix one thing,and something else gets messed up.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 09, 2014, 02:30:55 PM
This is how SD card write access works on Lollipop: https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT_TREE

Still a bad solution in my opinion since all the old apps that have been abandoned can't write.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 03:10:40 PM
This is how SD card write access works on Lollipop: https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT_TREE

Still a bad solution in my opinion since all the old apps that have been abandoned can't write.

In any case, I still don't think the SD card issues have any relevance to mupen64plus-ae.

Terrible news for my Fire TV test.
It is now immensely lagging with Glide64 on Super smash bros. at a sluggish 30fps with four DKs on Hyrule.
Regularly,it would be 50fps-60fps.
It even lags more immensely on character select.
Hate how I can't compare anymore with Gillou's creation,but it does run smash bros. much faster.

The way frameskipping works, it only takes a little bit of slowdown to jump from 60 fps to 30 fps.  If it takes even a millisecond longer than 1/60th of a second to render a frame, the next frame is skipped entirely and you jump all the way down to 30 fps.  By the way, most games only ran at 30fps on the original console anyway, so 30fps is perfection in my book.

Please stop referring to "the Gillou build".  We will be picking apart the differences, which seem to be related to a framelimiter mod.  Rest assured they will get into the alpha soon.  We are all on the same team.  Continued comparisons don't serve any purpose.

Your use of negative hyperbole ("terrible", "horrible", "painful", "cripple", "immensely", "hate") continues to drive me nuts.  Not sure what type of persona you're trying to project, but the fact is you sound like a spoiled brat with an entitlement complex.  Just saying.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 09, 2014, 04:08:27 PM
This is how SD card write access works on Lollipop: https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT_TREE

Still a bad solution in my opinion since all the old apps that have been abandoned can't write.
Thanks for the share.

@littleguy good to hear we don't have to worry about it. Thinking about it though, I might commit a check for write access when the user selects a save directory of their own on extSdCard. Just to avoid problems.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2014, 05:16:49 PM
Quote
Your use of negative hyperbole ("terrible", "horrible", "painful", "cripple", "immensely", "hate") continues to drive me nuts.  Not sure what type of persona you're trying to project, but the fact is you sound like a spoiled brat with an entitlement complex.  Just saying.

YEESH!!! Who installed malware on YOUR computer?!? :o
It's not like I am saying directly HATEful and mean things now,I am simply describing the regressions as they actually are negative.  :(
The default framerate for Super Smash Bros. has always been 60fps and Zelda's save menu runs at 60 before the change back to 20fps in-game.  8)
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 09, 2014, 05:34:41 PM
Md5 related crash on exit http://pastebin.com/a6jFNqGd
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 05:40:33 PM
Thanks xperia64.  Could you please post the crash log from mupen64plusae-v3-alpha/CrashLogs ?  It puts the stack trace right at the top and (I think) filters out non-mupen stuff from the logcat.

Edit: I actually don't see anything related to mupen in your paste..
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 09, 2014, 06:06:00 PM
I guess the paste was too big. Anyway the latest glide changes make the banjo kazooie intro a bit derpy with the circle transition.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 06:17:31 PM
Thanks.  Looks like the config file is null, but I don't see how that's possible if you've already been through the gallery during your session.  Is there another crash log with virtually the same timestamp?
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 09, 2014, 06:21:28 PM
It's the only one in the folder.
I load a game and exit, and it crashes.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 06:23:23 PM
Is crash reporting enabled in the global settings?  If so, disable it.  There might be an interaction with ACRA bug reporting.   :-\

Edit: does this occur for all three video plugins, or just one?
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 09, 2014, 06:53:22 PM
ACRA wasn't enabled.
It crashes with all 3 video plugins, but the glitchy circle intro in BK only occurs with glide.

The only thing that can be null is sConfigFile. All crashes occur on line 96 of ROMDetail, which is where the unknown game crash in previous versions happened.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 09, 2014, 07:24:19 PM
Ah, the stack trace is a red herring.  Thank goodness for the logcat.  The real problem is the hard crash during unloading the libraries in ae-bridge:

Code: [Select]
[ 12-09 19:03:49.456 18032:18407 D/Core     ]
Rom closed.

[ 12-09 19:03:49.461 18032:18032 I/ae-bridge ]
Unloading native libraries

[ 12-09 19:03:49.475 18032:18407 F/libc     ]
Fatal signal 11 (SIGSEGV) at 0x77e85d34 (code=1), thread 18407 (CoreThread)

[ 12-09 19:03:50.147 18443:18443 D/dalvikvm ]
Late-enabling CheckJNI

I remember Gilles (or was it you?) did some fixes to the ae-bridge unloading.  I'll take a look and we can see if that fixes it.

The red herring is caused by the app restart, which clears the static java variables but doesn't re-run the SplashActivity where sConfigFile is instantiated.  So I need to fix that too.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2014, 11:40:24 PM
Just ran DK64 on default "read every frame" with Alpha 5 and it surprisingly only runs at 2fps! X_X
What is going on?!?

Glide64 definitely needs to have some stuff reverted,and you already know about the fastforward regression.

I changed the "read every frame" option back to -1 and that is what occurred.
It ran decently with the option on zero,but fade effects don't work when set to that.

In the "his" version (the only other one for DK64 with the option inside the config),it does not disable the fade effect and when defaulted -1 on "his" version,it runs phenominally better at 30/30fps
with "read every frame" set to -1 for default.
Then again,it also has the original fastforward.

Also,littleguy...Please stop flaming me about being negative and about mentioning the build that Gillou made.
It is the only other one (the original one to accomplish DK64) besides the first Alpha that can run DK64 properly with collisions on Recompiler.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 06:07:29 AM
The problem with making comparisons to it is that it isn't available here to compare.. so it is basically unverifiable anecdotal information at this point.  Wait for some of the various components to make it into the Alpha testing builds, and then such comparisons will be relevant.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on December 10, 2014, 07:07:56 AM
I may have found a regression in Rice plugin, see here:
https://github.com/mupen64plus/mupen64plus-video-rice/issues/24 (https://github.com/mupen64plus/mupen64plus-video-rice/issues/24)

Could someone else test this?
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 10, 2014, 07:37:25 AM
Just ran DK64 on default "read every frame" with Alpha 5 and it surprisingly only runs at 2fps! X_X
What is going on?!?

Glide64 definitely needs to have some stuff reverted,and you already know about the fastforward regression.

I changed the "read every frame" option back to -1 and that is what occurred.
It ran decently with the option on zero,but fade effects don't work when set to that.

In the "his" version (the only other one for DK64 with the option inside the config),it does not disable the fade effect and when defaulted -1 on "his" version,it runs phenominally better at 30/30fps
with "read every frame" set to -1 for default.
Then again,it also has the original fastforward.

Also,littleguy...Please stop flaming me about being negative and about mentioning the build that Gillou made.
It is the only other one (the original one to accomplish DK64) besides the first Alpha that can run DK64 properly with collisions on Recompiler.
It sounds like you're running under interpreter, with the new profiles, balanced is the highest setting for the dynarec, interpreter mode will always give really low fps.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 08:17:52 AM
Just ran DK64 on default "read every frame" with Alpha 5 and it surprisingly only runs at 2fps! X_X
What is going on?!?

Is that option even configurable in the front-end yet?  DK64 runs fine with Glide64 and frameskip no more than 5. (basically what was default for Glide64 on 2.x).  In 3.x alphas, the "Balanced-glide64" profile is slower than default settings for glide64 in 2.x because it has frameskip set to never skip frames.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 09:43:06 AM
Please stop referring to "the Gillou build".  We will be picking apart the differences, which seem to be related to a framelimiter mod.  Rest assured they will get into the alpha soon.  We are all on the same team.

In the "his" version
on "his" version

You missed littleguy's point entirely.  He wasn't telling you to censor out the reference to Gilles.  He was saying stop comparing the alphas to a build that Gilles posted which contained mods that have not yet filtered into the main repository.  Whether you intend to intentionally or not, you continue to add to a perception that there is some sort of schism in the AE development team when there isn't.  Gilles is a critical part of the team at this point, with the skills needed to keep this project from stagnating.  We all have a huge respect for him.

The point I am trying to bring across is that these comparisons are almost as useless as constantly comparing the app to N64oid or Project64, since the referenced build contained several unrelated mods and was not a direct ancestor to the posted Alpha tests.  It therefore negates the usual comparison techniques like git bisecting.  Comparisons will become useful as the various mods added by Gilles are merged into future Alpha tests and we can determine which ones specifically are beneficial in which ways.  Otherwise we are just comparing apples to oranges.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 10:01:05 AM
Gilles is a critical part of the team at this point, with the skills needed to keep this project from stagnating.  We all have a huge respect for him.

Well said!! Totally agree.  ;D ;D ;D

Otherwise we are just comparing apples to oranges.

At this point, it is *very* helpful to make comparisons with other alpha versions or to the published version.  Please take extra care when comparing to the published version, to be sure you are using the same settings.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2014, 11:21:28 AM
Okay then,sorry.

By default I meant just the "read every frame" setting in the config file from the folder.
I normally had it set to "0" so games run faster with no major graphic loss.
My selected profile is a custom one named "guilt" with Dynarec,Glide64,and never skip frames.
Other games run slow,but I have never seen DK64 run so slow as 2fps before.

I may even try recording a video with my tablet showing the molasses party that is DK64 now.
And YES,I might also show the other one for more proof.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 11:27:29 AM
Thanks.  Just tell us when the regression occurred.  I.e. between which two alpha releases did things change?
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2014, 11:51:16 AM
Just immediately noticed major speed increase on DK64 when installing Alpha 4 again.
The fastforward regression is in this one as well.
Also sorry,the name changed to something like "read always" in the config file.
I had it set to -1 still,and I get very good performance.

So it is even more obvious that it is caused by the Glide64 changes that removed Link's torso and various other graphical elements while glitching others.
Hope this can be fixed easily enough.

I also am really eager about GlideN64's hopefully inevitable release,but only Android because my PC is useless for lack of required features.
Hey Gonetz,the CEN64 developer cares about everyone stuck with outdated PCs by setting the minimum requirement to SSE2 (waiting for update so I can try it),why can't ya do that for GlideN64 as well?
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 11:56:25 AM
SSE2 became obsolete in 2004.  If you have a computer older than that, you should expect a lot of programs not to work  :P
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2014, 12:03:01 PM
I can run Dolphin emulator half decently and PJ64 2.x runs amazingly with consistant 60fps on Banjo-Tooie at counter factor of 1.

Speaking of Banjo-Tooie,it ran surprisingly fast with Glide64 on Alpha 4 and my "no frameskip" code.
It competes with Rice for speed,even with that setting on -1.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 12:13:14 PM
@retroben Thanks for the very clear report. :)

The regression is probably due to this:
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/6f66b694aa610b2d7cf569e2fbdcc7f979cc7bd9#diff-06f7a4d6687ec9ef8bc2e5cfe714616eR470

@retroben You could try deleting that line (file located in /Android/data/org.mupen64plusae.v3.alpha) and see if the speed returns.

There are also other glide settings you can change manually:
https://groups.google.com/forum/#!topic/mupen64plus/urawGVtw2qY
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 12:16:08 PM
Here's the upstream commit.  Notice the comments at the bottom of the page.

https://github.com/mupen64plus/mupen64plus-video-glide64mk2/commit/b2a78163914a54d8ed1c1e2641cbf47f6896e250
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2014, 01:08:37 PM
So,install Alpha 5 again and change that setting?
It does not alter the performance in Alpha 4 when "fb_read_always" is default in the user config.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 01:15:54 PM
Yes, please install alpha 5 and delete that line from Glid64Mk2.ini.  Thanks.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2014, 01:19:13 PM
Did what you said,and I already mentioned better speeds with it off.
It is still quite a bit slower compared to Alpha 4.
The previously mentioned regression where Link's pause model is missing the torso,and with other various graphics missing and glitched.
The biggest offender is when fb_read_always is turned off in Alpha 5,the fade transitions no longer work.
Strangely,this does not happen with older Alphas having it turned off,they properly show fade transitions.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 01:34:08 PM
@Paul - Could you please post the commit hashes next to the builds in the OP?  Thanks.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 01:37:01 PM
Sure, I'll do that in a bit when I get a few minutes
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 01:46:18 PM
@retroben - The only configuration changes made between alpha 4 and alpha 5 were to some default settings.  You could try changing these back to their v4 values by editing mupen64plus.cfg

DefaultsAlpha 4Alpha 5
adjust_aspect10
fb_read_always01
vsync01
clock_24_hr01
wrpAnisotropic01
aspect-10

Edit: The other possible cause is the new rotation setting.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2014, 02:51:12 PM
It could either be the Vsync slowing things dowm or the wrpAnisotropic,or both.

Edit:Can't be either since both are already disabled on my settings files.

Still saying the main cause is something that got mixed up in Glide64 after the data merge.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 06:13:34 PM
Added links to commits for each Alpha in OP.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 07:07:41 PM
@retroben, I built a version of Alpha 5 with the Glide64 rotation stuff removed.  Please note whether this performs any differently than Alpha5:

Alpha 5b (http://www.paulscode.com/source/Mupen64Plus-AE/10DEC2014/Mupen64Plus_debug_a5b.apk) (Glide64 no rotation comparison) 4fe367f (https://github.com/paulscode/mupen64plus-ae/commit/4fe367fb77a14ea6152c63b9fcf6c40d68497b62)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 07:41:05 PM
I just git-bisected.  This is the commit that breaks it, no doubt about it.
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/6f66b694aa610b2d7cf569e2fbdcc7f979cc7bd9

One thing I stupidly forgot to do was bump the asset version, so testers will have to manually "Reload App Resources" when going from Alpha4 (or earlier) to Alpha5, and vice versa.  This is located in
    Global Settings->Data->Reload App Resources

We'll need to update the asset version before posting Alpha6.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 10, 2014, 07:43:50 PM
Yep. Yes those games have FB effects, but the nuked speed is definitely not worth it.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 07:48:55 PM
I'm thinking these settings will have to work similarly to the other ini settings we were discussing (except in this case, it is organized by ROM header name instead of MD5).  Probably could do the same thing, where we maintain two files (one for defaults, and one for user overrides).  The overrides could still be stored by MD5 (so from user's perspective it is no different than the other ini settings).  Then give the plugin a small INI file upon launch for the specific game being launched.  Sounds complicated though now that I'm typing it out...
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 07:51:27 PM
First we should study the upstream code.  We may be able to override the setting in mupen64plus.cfg.  That would be much easier by far.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 10, 2014, 07:55:38 PM
Yep. Yes those games have FB effects, but the nuked speed is definitely not worth it.
Aha! Yep, I just tried a couple of games with heavy usage of frame buffer effects and they've definitely slowed to a crawl.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 08:01:35 PM
One thing I stupidly forgot to do was bump the asset version

Ah, yes.  That would explain why I didn't notice a performance drop when I updated from 4 to 5.  Definitely see it now.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 10, 2014, 08:09:19 PM
One thing I stupidly forgot to do was bump the asset version

Ah, yes.  That would explain why I didn't notice a performance drop when I updated from 4 to 5.  Definitely see it now.
It's a shame really since games like majora's mask are unplayable past a certain point without frame buffer effects. (Lens of truth)
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 10, 2014, 08:14:41 PM
If FB read was a dynamic thing that could be toggled in game, that might work. I haven't looked at glide's source to see how impossible it would be.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 08:16:51 PM
First we should study the upstream code.  We may be able to override the setting in mupen64plus.cfg.  That would be much easier by far.

Yep, there is a [Video-Glide64mk2] section in the main config file.  Param fb_read_always defaults to -1 (Game default).  We could just manually set it to 0 (or 1 if we add an option for it)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 08:28:42 PM
Alright, someone just needs to update NativeConfigFiles.java to add the line.  And bump the asset version.  I can't get to it tonight.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 09:02:54 PM
I got it.  Will post as Alpha 6 in a bit.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 09:14:47 PM
Hang tight, don't post Alpha6 yet.  I manually changed the config file and it got rid of most, but not all, the slowness in the DK64 intro.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 09:37:35 PM
Oh, ok.  Which settings need to change?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 09:40:57 PM
Ok I lied, I pushed some fixes.  There are still some regressions however.  The intro is still noticeably slower than Alpha4, some of the letters are missing in the intro subtitles, and one of the opening transitions is a little glitchy.  I haven't actually played the game yet  :P
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 09:51:20 PM
Thanks superjake.  We've actually decided to make the move to compartmentalizing the data files by game, as this will make it much easier to do all sorts of things in the opening gallery screen (e.g. jump straight into a savestate).  There's a more in-depth discussion recently in the "Brainstorming Version 3.0" thread if you want to weigh in.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 09:54:05 PM
The new rotation feature has no impact on the transition glitch (right after the dolby logo) nor the slowness, nor the missing letters in the subtitles that all arose after Alpha4.

Wondering if we should just revert the 'align-glide-upstream' merge commit so we can move on with the other stuff.  Too many fires to deal with at the moment.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 10:03:50 PM
Will be good to eventually track down the regressions, but can definitely put that off until later after the framework and front-end are solid.  Tricky part is that upstream GLES support is relatively recent, so regressions from before that will be tedius to test if they are not reproducible on the PC version.

No strong preference either way myself, though.  What does everyone else here think?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 10:16:13 PM
Will be good to eventually track down the regressions, but can definitely put that off until later after the framework and front-end are solid.  Tricky part is that upstream GLES support is relatively recent, so regressions from before that will be tedius to test if they are not reproducible on the PC version.

No strong preference either way myself, though.  What does everyone else here think?

The other option is just to proceed as we have been, and just emphasize front-end testing/usability.  Ask folks not to get too hung up on glide regressions, other than to note them.  When the dust settles on the front end, we can always revert that merge-commit then (on a test branch) and do some A/B comparisons with the latest stuff.  You bring up a good point about staying out of sync and the apples/oranges comparison with the PC version.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 10:18:55 PM
Posting Alpha 6

Alpha 6 (http://www.paulscode.com/source/Mupen64Plus-AE/10DEC2014/Mupen64Plus_debug_a6.apk) (Override new glide64 defaults) 10988f5 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/10988f56e0e55f11c84c763f96177eddf9d5cb25)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 10, 2014, 10:29:17 PM
Cool.  Hopefully I can stay focused on the front stuff for awhile.  A bunch of little works in progress  8)
https://github.com/mupen64plus-ae/mupen64plus-ae/network
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 10:37:25 PM
Same here, I need to stop getting side-tracked  ;D  I'll focus on getting the new gallery into a branch so I can put it up on github.
Title: Re: 3.0 Alpha Testing
Post by: SuperL on December 10, 2014, 10:39:40 PM
Is there an APK version of the new alpha? I would like to try it.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2014, 10:43:52 PM
*falls face-first on the floor like Mario*

Just tried Alpha 6...
Sorry,but I still get the 2fps with it on and no fading transitions plus missing objects when off.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 10, 2014, 11:16:54 PM
Is there an APK version of the new alpha? I would like to try it.

Yes, the bold green text are links to the APKs.  The latest will always be available in the first post of this thread.


I still get the 2fps with it on and no fading transitions plus missing objects when off.

Got it.  We'll get back to tracking down glide64 regressions later.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 11, 2014, 02:08:14 AM
For those of you playing Majora,you can switch to Rice for the lens of truth to work better,but the widescreen border has been messed up from the changes done to Rice,and it is painful on the eyes.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 11, 2014, 05:05:32 AM
*falls face-first on the floor like Mario*

Just tried Alpha 6...
Sorry,but I still get the 2fps with it on and no fading transitions plus missing objects when off.

@Paul I think you posted the wrong link judging by the filename
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 11, 2014, 06:39:34 AM
@Paul I think you posted the wrong link judging by the filename

Oops, sorry about that.  I updated the links.
Title: Re: 3.0 Alpha Testing
Post by: asturias3636 on December 11, 2014, 08:24:56 AM
hi, v3 Alpha version when I leave a game in 2013 Nexus7 mupen64 application stops, I get a message "has stopped the application Mupen64 AE (v3 Alpha) ."
Greatly improved mupen64 ;D great job
Title: Re: 3.0 Alpha Testing
Post by: asturias3636 on December 11, 2014, 11:28:55 AM
The Donkey kon64 work fluid (25-30fps) in nexus72013(android 5.0.1) with the Alpha v3 using emulation speed-gln64 profile.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 11, 2014, 11:49:59 AM
Nice to see it is working on Lollipop. :)

Tried Alpha 6 for real this time. (harumph)
Still missing fade transitions and getting glitched graphics.

Here is one screeny of the "Q I GAME" option.
Conveniently shows it on the download page itself,so no need for actual download.

http://www.2shared.com/photo/HgdyBGlg/donkey_kong_64-000.html

And here below,we see a missing vertex of water graphics...

http://www.2shared.com/photo/Y4g7yruv/donkey_kong_64-001.html

To clarify the situation,some older versions and a certain one don't have these issues with fb_read_always set to 0.
Really frustrating to deal with when it used to work fine with faster speeds on 0 and no missing graphics or loss of fading transitions.

If all you did was force off the "fb_read_always" option then that's just like putting on a bandage without disinfectant.
My screenshots stand out more now.

EDIT:Just remembered this is a big problem with DK64 since Glide64 is the only one that works with transparency on the bananaport pads.
Sure,the others render graphics okay,but they can't get that translucency right.

Rice has gotten worse with the repeating screen data and missing screen clearing functionality.
Then glN64 doesn't like DK64 at all since it has a camera glitch that hinders your control.

I think we need a GFX Plugin data overhaul to revert these major regressions.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 11, 2014, 12:41:04 PM
Thanks for the screenshots.  Noted, there is still a regression between Alpha4 and Alpha6.  We do not doubt that and we will absolutely be resolving that in the future.

Right now Paul and I can only focus on one or two things at a time.  Our immediate focus is the foundational issues in the Version 3 front-end.  Things like
 - crashes on start/stopping the game
 - crashes and bugs in the gallery, settings screens, diagnostics screens, etc.
 - basic usability of the front-end

Once most of that has been worked out, we will be moving on to
 - synchronizing the core and plugins with upstream
 - isolating and fixing in-game regressions
 - polishing and enhancing the front-end (non-game) stuff

These are alpha builds, and this is called Tester's Corner for a reason.  All testers should expect alpha builds to be somewhat unstable, with occasional performance drops between alpha releases.  That is the definition of an alpha.  If you are expecting an alpha to be an awesome product that meets all your desires, then you will be disappointed.  That is simply not how software development works.  There are literally hundreds of years of programming experience between all the mupen64plus developers.  We ask that you trust our judgement, respect our methods, and set your expectations appropriately when testing unstable products.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 11, 2014, 02:42:15 PM
@littleguy, might also track down why the load times to and from the new gallery are upwards of an entire second. I'm not sure if it's accessing the database every single time or loading the romheader every time (haven't had a chance to look into it yet) but simply caching which file is what name and which image in an ini file would more than suffice if that's what it's doing. And just confirm the file still exists.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 11, 2014, 03:15:20 PM
Thanks Zaneris.  Yes, the slowness is a nagging thorn in my side and is related to the meta-database and the need to calculate MD5 checksums in the app.  I hope to cut that down somewhat after this next round of refactoring that I mentioned in your last pull request.  There is quite a bit of caching already going on, but I'm sure there are some inefficiencies still left to squeeze out.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 11, 2014, 09:42:08 PM
Some of the regressions between Alpha4 and Alpha5 - caused by this commit (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/13129f83a393807f26833e5458dd99d6b7b6cf9f)
  - Glitchy screen transitions: example immediately after Dolby logo on DK64 restart
  - Missing textures: example in the subtitles in DK64 intro after restart

Edit: Much of the slowdown caused by a change in debug logging (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/dd17a2c65969b9cd06ebe8e31572dcee0460bf6f#diff-587003bede49f93fc746bd9de9c1deedL26).  Was hard to detect because the logs weren't percolating up to logcat (going to stdout probably instead).
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 11, 2014, 10:53:27 PM
@Paul Alpha7 can be published if you wish, as of this commit (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/fa36871a83b953b1956eb9aa303faa4047bb44f3).

Spent the evening hunting down the regressions.  They weren't where I was expecting.  In my testing it appears they are all gone.  I didn't change anything upstream; I simply backed off on how aggressively I synced from upstream.

Glide should perform identically on Alpha7 and Alpha4.  If anyone finds any differences, just let us know.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 11, 2014, 11:56:37 PM
Here is latest build.  I left my phone at work today, so couldn't verify build other than making sure it launched in the emulator.  Hopefully no problems:

Alpha 7 (http://www.paulscode.com/source/Mupen64Plus-AE/11DEC2014/Mupen64Plus_debug_a7.apk) (Address glide64 regressions) fa36871 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/fa36871a83b953b1956eb9aa303faa4047bb44f3)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 12, 2014, 01:01:39 AM
Alpha 7:Works great with DK64 again. ;D

I also have a screenshot of a first swap between glN64 to Glide64 if you need to see it.
Funky's Armory bananas look really rotten with a solid black texture in the middle in that first run.
Opened it again with restart and the texture was fine,but the stretching and tree teleport glitches have returned.

The fastforward is still causing brief slowdown at first whenever used before actually bringing up the speed.
Here's to hoping the atari graphics bug doesn't show up again.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 12, 2014, 08:07:55 AM
Confirmed that Alpha 7 removes the fps drops on frame buffer effects, but, the frame buffer effects are gone as well.

Hopefully the core developers can come up with something a little less resource intensive...
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 12, 2014, 08:25:40 AM
the frame buffer effects are gone as well.

Were they there in alpha4?  If so, can you suggest a game that I can easily test with (or provide a savestate)?
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 12, 2014, 09:42:41 AM
@littleguy, just checked and they weren't in alpha 4 for Glide, only 5.

The easiest game to see them quickly I think is banjo kazooie since you get that transparent puzzle piece transition effect as soon as you press start at the loading screen. Black without FB effects, and transparent with.

I don't think they're worth implementing for mobile due to the performance impact.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 12, 2014, 10:15:48 AM
Thanks much for clearing that up.

On a related note, has anyone observed any regressions between the published version on Google Play (2.4.4) and Alpha7?

Regarding the front-end, I was thinking it might be useful to place a copy of mupen64plus.cfg in each game-specific directory, rather than using a universal one for all games.  That way experts/testers can make hand modifications to the file (e.g. for the advanced options not exposed in the front-end) on a game-by-game basis.  Agreed?
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 12, 2014, 10:46:36 AM
Yes, that sounds like a good idea to me.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 12, 2014, 11:52:34 AM
Yes, that sounds like a good idea to me.
+1, average user won't know it exists and power users could benefit.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 12, 2014, 01:40:08 PM
We already can make changes,I just changed Kirby 64's buffer clear to 1 as a trade off for getting rid of the yellow plaid glitch.
Doing so sacrifices the theater texture by clearing it off the screen,leaving you with a smaller game screen.

I hope to find a 60fps code for Kirby64 today since the cutscenes use that framerate and I can exploit it. ;D
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 12, 2014, 01:47:33 PM
We already can make changes,I just changed Kirby 64's buffer clear to 1 as a trade off for getting rid of the yellow plaid glitch.

Littleguy was talking about global settings in the main config (versus the game-specific video plugin sections as in glide64's ini)  This would allow you to make game-specific changes to global settings so you wouldn't have to keep going back in and edit the file every time you wanted to switch to a different game.  (ties in well with the UI's game-specific settings concept)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 12, 2014, 01:59:55 PM
Oh,still pretty easy to do the other way thanks to ES File Explorer.

Edit:Here's the Kirby 64 code I mentioned.

Max Frames
800492D9 0001
02=Default
This makes the game run in 60fps but sadly at double speed of the 120VI internal refresh rate.
One upside is that it makes the game faster pace for a new fun challenge.

Frameskip
800492DB 00xx
Helps anyone with a lower end Android device that can't get any speed.
01=Default
02=One Frame
03=Two Frames

I had a blast in my Mupen64Plus AE 60fps test run. ;D
I may try to find a game speed code to make it half speed to balance out the 60fps to match it with 60VI.
Title: Re: 3.0 Alpha Testing
Post by: SuperL on December 12, 2014, 11:59:42 PM
So, I tried the latest alpha.

I'm not familiar with the technical nitty-gritty as you guys are, but I am amazed as how well some of these games ran. Donkey Kong 64 is actually playable now, even it does crash after exiting.

Are you guys planning on putting a "hide status bar" feature for pre-Kit Kat firmwares? Some other emulators have that and I think it would be useful here too.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 13, 2014, 09:36:51 AM
So, I tried the latest alpha.

I'm not familiar with the technical nitty-gritty as you guys are, but I am amazed as how well some of these games ran. Donkey Kong 64 is actually playable now, even it does crash after exiting.

Are you guys planning on putting a "hide status bar" feature for pre-Kit Kat firmwares? Some other emulators have that and I think it would be useful here too.
Can you think of any that have this feature off the top of your head?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 13, 2014, 10:26:13 AM
Are you guys planning on putting a "hide status bar" feature for pre-Kit Kat firmwares? Some other emulators have that and I think it would be useful here too.

I didn't know that was possible without root.  On Jellybean I used to use this app and it worked fine.
https://play.google.com/store/apps/details?id=de.tsorn.FullScreen
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 13, 2014, 01:47:37 PM
I didn't know that was possible without root.  On Jellybean I used to use this app and it worked fine.
https://play.google.com/store/apps/details?id=de.tsorn.FullScreen

It can be done in app without root,  I'll submit a pull for it at somepoint in the next few days.

Code: [Select]
public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        // If the Android version is lower than Jellybean, use this call to hide
        // the status bar.
        if (Build.VERSION.SDK_INT < 16) {
            getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
                    WindowManager.LayoutParams.FLAG_FULLSCREEN);
        }
        setContentView(R.layout.activity_main);
    }
    ...
}
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 13, 2014, 01:56:28 PM
Majora's Mask has proper lens of truth rendering in Glide64 now!!!  ;D
Got my keyboard working on my Intel x86 Android tablet.

Hey,Gillou,if you have a RadioShack near enough,they might have the same cord I got from my local one,and you could also make things easier for yourself for just fifteen bucks.
It is the Micro USB On-The-Go Cable.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 13, 2014, 03:13:23 PM
It is the Micro USB On-The-Go Cable.

OTG cables are easy to make if you have a solder gun and a few USB cables laying around:  http://makezine.com/projects/usb-otg-cable/
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 13, 2014, 03:50:20 PM
Abundant on amazon and ebay...
http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=otg
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 13, 2014, 04:22:19 PM
But more fun to make (if you are into electronics of course)   ;D
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 13, 2014, 04:39:07 PM
*facepalms for self ignorance* So that's what OTG stands for!
That would have saved me a LOT of time. :P
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 14, 2014, 12:18:35 PM
http://m.dx.com I find always has the cheapest cables and stuff like that.
Title: Re: 3.0 Alpha Testing
Post by: SuperL on December 14, 2014, 05:28:53 PM
So, I tried the latest alpha.

I'm not familiar with the technical nitty-gritty as you guys are, but I am amazed as how well some of these games ran. Donkey Kong 64 is actually playable now, even it does crash after exiting.

Are you guys planning on putting a "hide status bar" feature for pre-Kit Kat firmwares? Some other emulators have that and I think it would be useful here too.
Can you think of any that have this feature off the top of your head?

At the top of my head, Mame4Droid Reloaded and the Robert Broglia ".EMU" suite of emulators
Title: Re: 3.0 Alpha Testing
Post by: asturias3636 on December 15, 2014, 06:45:39 AM
Hello, the game Star Wars Rogue Squadron n64 not start, does not work in any version of Mupen64, tested in Nexus 7 2013 (android 5.0.1) and in Motorola Moto G (android 4.4.4) .a greeting.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on December 15, 2014, 10:00:34 AM
The game Zelda Master Quest crashes.
it works on 2.4.2
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 15, 2014, 12:09:27 PM
How does it crash,and which GFX plugin?
Does it happen immediately,or when you use the inventory?
Don't forget to mention your device and all the specs.

Rice has issues with Zelda in certain cases where unpausing the game causes it to freeze with music playing.
Glide64 does not freeze in that same scenario.
It makes sense for Master Quest to crash,especially if it is the GC extracted version.
One downside is Mupen being on the other side of the compatibility spectrum compared to PJ64.

Try all the GFX plugins.
Title: Re: 3.0 Alpha Testing
Post by: rafar on December 15, 2014, 12:12:06 PM
amazing work guys, banjo-tooie and dk64 are playable now.  :)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 15, 2014, 12:42:18 PM
The game Zelda Master Quest crashes.
it works on 2.4.2

Please post the crash log, located in /mupen64plusae-v3-alpha/CrashLogs/ of your device.  This will contain most of the information that retroben requested :)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 15, 2014, 01:24:17 PM
HEY!!!,Gillou!
Could you please reupload your build since the Master Quest Debug ROM runs perfectly fine on it while crashing on the Alpha build?

Or can you please at least give me your consent so I can upload my copy of it?
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 15, 2014, 01:34:38 PM
@retroben there is no problem with you posting it.  Just don't post it on this thread since it is not related to 3.0 Alpha Testing.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 15, 2014, 01:44:16 PM
Still need consent from Gillou.

Also,the Conker ECTS Demo runs on your Alpha just fine. ;D
Though I had to rename it to .n64 from the original .rom filename,giving me a reason to hate the new game selection style.

Please add support for the .rom file extension so this and other games using it can be selected without renaming them.
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 15, 2014, 01:54:13 PM
Still need consent from Gillou.

It's licensed under the GPL, so not technically.  But sure if you want to wait for a thumbs up from Gilles no problem  ;)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 16, 2014, 02:30:28 PM
Does anyone on this thread have a Qualcomm device that exhibits the screen rotation bug when using the glide plugin?  If so, would you mind going to About -> Hardware Info from the main gallery screen, and posting the text here (use the share button).  Or, if you have a crash log file, that will work too.

I was going to add a setting to workaround the bug, but first wanted to see if there was anything that could be used to auto-detect (or at least narrow down) the devices that need it.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 16, 2014, 10:50:45 PM
I don't have the issue on my FireTV with JellyBean and Krait CPU/Adreno320 GPU,but I know that someone mentioned it was no longer occurring on a certain version of Android.
I think it might have been Lollipop where it was fixed,but i'm not sure.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on December 17, 2014, 01:06:12 AM
It was fixed in the August 7th v66 development driver for kitkat, I know it was still broken in their June development driver v53 or v55 irc and Android 4.4.4, JB never had the problem it was only with kitkat.
Title: Re: 3.0 Alpha Testing
Post by: asturias3636 on December 17, 2014, 07:17:21 AM
The devices Qualcomm with android  5  no problems with the screen rotation Glide plugin, I have a Nexus7 2013 with adreno 320 and snapdragon s4 pro with android 5.0.1.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 17, 2014, 07:28:49 AM
Thanks.  I know the issue is fixed in Lollipop, but there are still users/devices that are running KitKat.  If you have one of these devices, please post the text from About -> Hardware Info, or a crash log.  That text contains codes that we can check to "auto-detect" whether the workaround option needs to be visible.

If you have a device that used to have the problem, but no longer does due to firmware updates, I would still appreciate getting the info from you.  Thanks.

Title: Re: 3.0 Alpha Testing
Post by: asturias3636 on December 17, 2014, 07:58:52 AM
Device: Virtual
Id: -1
Descriptor: a718a782d34bc767f4689c232d64d527998ea7fd
Class: BUTTON

Device: gpio-keys
Id: 1
Descriptor: 485d69228e24f5e46da1598745890b214130dbc4
Class: BUTTON

Device: apq8064-tabla-snd-card Button Jack
Id: 3
Descriptor: db07212d213438566449709b3ea207d5e793b808
Class: BUTTON

Device: h2w button
Id: 4
Descriptor: e421997b57c785755f2193bf6543d7ef1a49061e
Class: BUTTON

Processor   : ARMv7 Processor rev 0 (v7l)
processor   : 0
BogoMIPS   : 13.53

processor   : 1
BogoMIPS   : 13.53

processor   : 2
BogoMIPS   : 13.53

processor   : 3
BogoMIPS   : 13.53

Features   : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
CPU implementer   : 0x51
CPU architecture: 7
CPU variant   : 0x1
CPU part   : 0x06f
CPU revision   : 0

Hardware   : QCT APQ8064 FLO
Revision   : 0000
Serial : XXXX

Board: flo
Brand: google
Device: flo
Display: LRX22C
Host: wpee20.hot.corp.google.com
ID: LRX22C
Manufacturer: asus
Model: Nexus 7
Product: razor


This is what you need?? About>hardware info...
In lollipop(5.0.1) I have no problems rotation, but in the previous version(android 4.4.4) if he failed the glide plugin.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 17, 2014, 08:00:35 AM
Perfect, thanks!
Title: Re: 3.0 Alpha Testing
Post by: asturias3636 on December 17, 2014, 08:19:17 AM
In Motorola Motog with android 4.4.4 kitkat, adreno305 GPU and snapdragon 400, no problems with the screen rotation Glide plugin,I think only failed adreno 320 with kitkat...
Title: Re: 3.0 Alpha Testing
Post by: rafar on December 17, 2014, 01:33:05 PM
I have no problems with screen rotation on my Lg G2, snapdragon 800 and kit kat 4.4.2. Greetings
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 17, 2014, 01:49:23 PM
Could this mean KitKat is causing the problem directly with Adreno320?
I have Adreno320 in FireTV,but it is on JellyBean and I don't get rotation issues.
Good thing for FireTV,rbox is trying to get Lollipop working instead of implementing a KitKat version.

I may be protected by an orientation app that forces landscape.

Edit:Here is the app I use for stubborn apps that default in portrait mode...

https://play.google.com/store/apps/details?id=bong.android.androidlock

Anyone with the rotation issue can try it out to see if it successfully forces landscape and prevents the rotation bug from ocurring.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 17, 2014, 01:51:30 PM
AFAIK the issue only affected Adreno 320 on KitKat (no problem on Jellybean or Lollipop).  Full discussion here
http://www.paulscode.com/forum/index.php?topic=1278.0
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 17, 2014, 02:26:22 PM
I can try to flash my Nexus 7 to KitKat if no one else steps forward. Bit difficult given 2/3 of the touchscreen is unresponsive.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 18, 2014, 10:14:45 PM
@Paul - I just pushed a bunch of refactorings and cleanup (ab749798bca896653e0636c44ab4c6360f8a7155) (f012c42bc0b79c19dad0c59b3dbc5df8ba5506a0).  Now would be a good time to post the next alpha, before I start pulling in more dynarec changes from upstream. 

One important change that will affect testers is that the game save folder has been renamed. (It's generated only from md5 and header contents, rather than mupen64plus.ini which might change later).  Also, mupen64plus.cfg can be overridden per game, which should save some tedium for expert users.  Other changes include a crash fix and manifest support for Android TV.

Edit: Also did some maintenance on the upstream forks, though I haven't synced down yet.  I added tags to rsp-hle and video-rice to denote that after I sync down we will be using completely unadulterated upstream code.
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 18, 2014, 10:25:04 PM
You're going to have to write and test some save file conversion code at somepoint from old to new before this could ever be published to the play store.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 18, 2014, 10:30:37 PM
Yep, that's been on our mind since we started.  This alpha phase is a way for the dust to settle so that we don't have to rewrite the conversion script after version 3.0.0 is published.
Title: Re: 3.0 Alpha Testing
Post by: N64joan on December 19, 2014, 03:59:48 PM
Hello, I have a problem with "pokemon stadium 2" crashing when I struggle with the second coach in the second fight. and another problem with the plugin in "killer insting gold". Some plugins work on my tablet but it works in "killer insting gold" the game slows down. I think that is incompatible with my processor, but rarely work on an old processor "ARM cortex a7" and a new one does not work (in "ARM cortex a7" works but "• Quad-core 1.6GHz ARM Cortex-A9 (rk3188) "does not work.)


.I'm playing in qlive97 (archos platinium 97b)
The characteristics of tablet:
Display • 9.7’’: 2048 x 1536 pixels, IPS,
Android 4.2, "Jelly Bean"
Processor:
• Quad-core ARM Cortex-A9 1.6GHz (rk3188)
• Quad-core GPU Mali 400 MP4
RAM • 2GB RAM)
thanks for your attention




Title: Re: 3.0 Alpha Testing
Post by: N64joan on December 19, 2014, 04:19:14 PM
hello, you could add the option for dual core, I have quad core cpu and gpu. I think my tablet would have more performance by leveraging the CPU cores. I have another dual core cpu "arm cortex a7" and it works better than the cpu arm cortex a9.

Thanks for your attention
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 20, 2014, 11:12:47 PM
The app is already multi-threaded and uses however many cores are available.
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 21, 2014, 12:00:11 AM
Is there a way to force extra cores to be used when they are dormant?
It would be cool for rooted users if possible.
Two of my four cores are almost never getting used according to Kernel Tuner.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on December 21, 2014, 09:53:31 AM
I have some bugs when I use a controller.

On the game select screen I cannot see which game is selected.
And I cannot get in the settings with a controller, I can only select games, when I press up it does not go to the settings button.

Thank you.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 22, 2014, 10:20:02 AM
With Gilles' awesome dynarec fixes, interpreter mode is looking more than ever like just a developer/corner-case option.  Anyone mind if I remove it from the built-in "Emulation Profiles" list?  With that change, it might also be nice to rename the built-in profiles as follows:
 - glide - Accurate
 - glide - Fast
 - gln64 - Accurate
 - gln64 - Fast
 - rice - Accurate
 - rice - Fast
where Accurate means no frameskip and Fast means with (auto)frameskip.

Also, was thinking maybe glide - Fast (glide with autoframeskip up to 5 frames) would be a better default.  For fast devices, there's no difference in behavior with glide - Accurate.  Anyone who sees artifacts with frameskip will likely try one of the "Accurate" modes next.

What do people think?
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on December 22, 2014, 10:44:51 AM
I think it's always a good idea not to prompt the user with too many options ;)
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 22, 2014, 11:23:46 AM
Agreed, simple accurate vs fast is probably the best.  And glide with Fast would probably be the best default if not only for consistency with previous versions.  Obviously it is also currently the most accurate of the video plugins (pending gliden64), so I could see a valid argument for going either way for the default.  It becomes less relevant, though, since we can change the default for the games which actually require accurate versus fast (Paper Mario, for example).
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on December 22, 2014, 12:40:08 PM
Hiding the profiles entirely unless the user enables a "show advanced" option would be ideal.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 22, 2014, 04:23:16 PM
Hiding the profiles entirely unless the user enables a "show advanced" option would be ideal.

Yep, that's kind of the eventual goal.  Probably still show the other options, but have the default value be different for some games.  The settings system has been reorganized heavily for V3, and that's one of the big reasons.  Still needs to be implemented, but it should be fairly straightforward to do now.  I have a todo list and I try not to tackle too many things at once ;)

Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 22, 2014, 10:17:38 PM
Just discovered a regression in Rice -- garbage rendering outside the viewport.
(https://dl.dropboxusercontent.com/u/3899306/Screenshots/super_mario_64-006.png)

Tracked it down to this commit (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/fba6b5df57979911368e66323b076185f498268a), one of the upstream syncs, before any of the alphas were posted.  Easier to view the diff here (https://github.com/mupen64plus-ae/mupen64plus-ae/compare/77869c99e25af8b87105e0dc01aae48c522728ca...fba6b5df57979911368e66323b076185f498268a) since the sync was done in two commits.


@Paul - If (and only if) you have the time, I'd suggest these three commits for the next three alphas.  I don't think there's a rush, but these are probably good milestones.  8 and 9 don't need to be tested unless regressions are found in 10.
 - Alpha-10 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/652dd31d79fb31743e1060c0dca4171b3fd2b7a9)
 - Alpha-9 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/225d958ff4ac8dc4fb6bfddb227c8ee05861f4c9)
 - Alpha-8 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/f012c42bc0b79c19dad0c59b3dbc5df8ba5506a0)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 22, 2014, 10:52:39 PM
*stretches face with hands for grief* jk

Waiting so long,and now we got a possible pile-up for multiple betas to test. ::)
Hope I don't take too long to see the next beta get posted before the other ones follow. ;D

Can't wait for the next alpha,and I hope you all have a merry christmas. ;)
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 23, 2014, 08:49:45 AM
Alpha 10 (http://www.paulscode.com/source/Mupen64Plus-AE/23DEC2014/Mupen64Plus_debug_a10.apk) 652dd31 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/652dd31d79fb31743e1060c0dca4171b3fd2b7a9)

Alpha 9 (http://www.paulscode.com/source/Mupen64Plus-AE/23DEC2014/Mupen64Plus_debug_a9.apk) 225d958 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/225d958ff4ac8dc4fb6bfddb227c8ee05861f4c9)

Alpha 8 (http://www.paulscode.com/source/Mupen64Plus-AE/23DEC2014/Mupen64Plus_debug_a8.apk) f012c42 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/f012c42bc0b79c19dad0c59b3dbc5df8ba5506a0)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 23, 2014, 09:55:16 AM
Homer:Doh!

Okay,I will test them one-by-one right now since my stupid uncle and loud dad just woke me up.
As long as this cursed storm doesn't knock my power out though.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 23, 2014, 10:04:01 AM
Don't bother testing alpha 8 and 9 unless there's a problem with alpha 10.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on December 23, 2014, 10:39:55 AM
What I noticed with Alpha 10:

Perfect Dark looks much better, now with lights, but the controller is very lagy compared to 2.4.
Mario is also lagy with the controller. On the plus side no more crackling sounds.

Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 23, 2014, 10:40:56 AM
Thanks.  Which controller (touchscreen or a physical controller? If the latter, which brand?)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 23, 2014, 10:56:11 AM
Since I tried Alpha 8,Link's hair is fixed when getting the Deku Shield,now it stays normal instead of getting wooden hair.
Navi's circle graphic is rendering properly now instead of invisible.
Banjo-Tooie shadows with Glide64 are still bugged,and Rice still has the border issue.

Reserved...

Alpha 10 results:
Still fine with Zelda Ocarina,and fast forward speed is fixed.
It is micro crashing by going to the game list after quitting a game.
There is a major slowdown with Super Smash Bros. on Glide64,even with the "fb_read_always= 0" setting.
DK64 is running just fine,only having stretching model in a few spots like Cranky's Lab in training area so far.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on December 23, 2014, 12:18:18 PM
@littleguy

I have a MadCatz C.N.T.R.L.R.

With alpha 10 I have lag, with alpha 9 I have NO lag (good)

I tested Perfect Dark and Mario 64, with alpha 10 sometimes the buttons seem to get stuck, so i just keep walking forward even though I am not walking forward anymore, and other controller glitches like that, it feels/is laggy. like the button is stuck. with alpha 9 I have no such problem.

I have a Nexus 5.

Also another problem, if i set the virtual on screen gamepad to "disabled" it does not get disabled and still is on screen, when I set it to FPS only, it dissapears, so dunno if that's a good thing but works out for me.

And in the game select screen I cannot see which game I have selected when I'm using the Madcatz controller. Yes I can start a game, I just guess on which game the selection is, but i cannot visualy see it.

And a crash when exiting a game (pressing the back button)

Thank you, hope it helps.

O yeah, my guess is with the controller input lagging, is that in alpha 10 it is doing so much proccessing and calculations that all the CPU time is being used up so the Madcatz controller has to wait for everything to clear so it can work again. In alpha 9 I have no problems.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 23, 2014, 12:51:03 PM
Thanks guys for the detailed and helpful feedback :)  I will look into the regressions soon.

If the game crashes, a crash log will be posted in mupen64plusae-v3-alpha/CrashLogs.  If you post the contents here it will help us isolate the problem.  I think some of the crashes are device specific (perhaps a race condition) because I cannot reproduce them.

The gallery selection with the controller will be fixed when Paul's back from vacation and has time to make the real gallery UI.  The current one is very basic, just enough to allow testing.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 23, 2014, 01:30:27 PM
@Jermain - which emulation profile are you using, that's producing the controller lag in Alpha 10?  Do any of the "Balanced" or "Speed" profiles have no lag?
Title: Re: 3.0 Alpha Testing
Post by: rafar on December 23, 2014, 02:19:56 PM
I have a good performance on alpha 10, it is soon for say anything in my case. . the shadows work better on banjo tooie and mario 64. Tonight I will test several games and I say about my experience. Greetings and merry christmas you all  :).
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 23, 2014, 10:22:14 PM
The audio pitch seems too high in Alpha 10 for some odd reason.

Also,when can we expect GlideN64 to be ready for the general public?
I really wanna see how it runs on Android since there is only videos of it being used on PC.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on December 24, 2014, 12:57:11 AM
@littleguy, I did a reformat and installation of my nexus 5.

And now the alpha 10 is running without any lag, last time I installed it over the old one, maybe that is to blame.
If it re-occures I will make a note of it here.

On another note, i changed the flickering to the T profile, and now the shadow bugs are gone (nexus 5)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 24, 2014, 02:35:55 AM
Just noticed a visual bug with Glide64 that is still Recompiler change related...
Banjo-Tooie still has the disappearing bottom square on honey barn enemies,but only for brief moments.
Saw it happen in HailFire Peaks to be specific.
Also still having especially broken shadow positioning when Kazooie Alone.

These won't matter as much when GlideN64 comes out though.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 24, 2014, 08:28:34 AM
The next few days will be slow here for me due to holidays but thanks again for the useful and detailed reports.

I can't speak to dynarec/graphical glitches but general performance/crashes are puzzling since not a whole lot changed between 9 and 10.  I'm not sure why reinstalling fixed the slowness for Jermain  ???

One user is also reporting a crash on the upstream desktop version due to a recent change, which is even more puzzling.
https://github.com/mupen64plus/mupen64plus-video-glide64mk2/issues/30
Title: Re: 3.0 Alpha Testing
Post by: N64joan on December 24, 2014, 01:06:03 PM
hello, in alpha 10 with the profile "balanced-qlide64" in "ready 2 rumble boxing" Audio failed
Title: Re: 3.0 Alpha Testing
Post by: N64joan on December 24, 2014, 01:18:17 PM
in alpha 10 with the profile "balanced-qln64" in "ready 2 rumble boxing" text "rumble" is not seen. "life bar" is not seen
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 25, 2014, 10:53:46 PM
Majora's Mask Debug Rom runs near perfectly in Alpha10 aside from the eventual loss of sound and audio synced framerate which caused unlimited fps.
The Zelda OOT Master Quest Debug Rom can also run now instead of failing to boot like the earlier Alpha builds did.

It is really fun to mess around with the debugging functions in both of these Debug roms.
For anyone missing out:Google is your friend.

Can any of you change the default player counts for the Master Quest/debug versions to 4P so I and other people can access every debug function that these two Debug Zelda games have to offer through other controller mappings?
Title: Re: 3.0 Alpha Testing
Post by: MoopenGirl on December 26, 2014, 12:13:23 AM
Nexus 7 2013 32GB (WiFi) running on stock Android KitKat 4.4.4.
Qualcomm Snapdragon S4 Pro

Screen orientation issue with the Glide64 plugin still existed when running Mupen64Plus AE 2.4.4, but the issue is resolved in the 3.0 Alpha 10 build.

Tested with built-ins:
Accuracy-glide64
Balanced-glide64
Speed-glide64

Saw that you guys were needing KitKat testers so figured I'd pop by. If there's anything specific you need just give a shout.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 26, 2014, 07:33:20 AM
Awesome, thanks!  I'm surprised that it's fixed in Alpha10, because I hadn't actually fixed it yet :o  Perhaps one of the upstream changes fixed it...  Either way, one more thing off the todo list and one less hack to add. :D
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 26, 2014, 01:48:28 PM
I wonder if that new rotation option implementation was part of what fixed it?
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 26, 2014, 02:44:00 PM
Still crashes on exiting a game https://www.sendspace.com/file/q8wgrv
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 27, 2014, 02:45:08 PM
@xperia64 Thanks much, I'll try to compare my logs and see if anything in the lifecycle handler is different on mine.

This might not be related, but it does make me wonder what's going on:
Code: [Select]
12-26 15:42:20.345 14086 14086 W ContextImpl: Implicit intents with startService are not safe: Intent { act=com.nvidia.ControllerMapper.START_SERVICE } android.content.ContextWrapper.bindService:517 com.nvidia.ControllerMapper.MapperClient$ServiceClient.connect:683 com.nvidia.ControllerMapper.MapperClient.<init>:102

Does NVIDIA insert an extra layer between the physical controller and Android to allow its own remapping capability?  The warning looks like the same issue we had with the MOGA controller library not being Lollipop compatible.  I think it's a warning in KitKat, error in Lollipop.  What Android version are you running? 
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on December 27, 2014, 05:41:42 PM
KitKat. Waiting for certain Xposed tweaks or Xposed itself to be ported to Lollipop.

That warning always gets shown every time I launch an app with a controller connected.
Title: Re: 3.0 Alpha Testing
Post by: Marleau on December 28, 2014, 01:10:32 PM
Hi,

In alpha 10 I found out while playing Super Mario 64 that the sound was coming 1/2 second too late regardless the plugin or the audio setting used. The version from the play store seems to working fine. You can see by yourself by jumping in the game.

Oh and sometime when I quit the game the app crash.

I'm using a Nexus 5 with android 5.0

Thank you for your hard work!
Title: Re: 3.0 Alpha Testing
Post by: rafar on December 28, 2014, 02:57:39 PM
On my s2 sometimes crash too when I exit of a game, but It never happens on my lg g2... (maybe for its bigger power?)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 28, 2014, 03:14:16 PM
Try changing the "Sync/Desync Audio" menu from in-game.  Also try the different audio buffer sizes in global settings -> Audio.  If any combination fixes the problem, please tell us which one.

Also, do you still get the audio lag if you Restart rather than Resume the game when launching it?
Title: Re: 3.0 Alpha Testing
Post by: Marleau on December 28, 2014, 11:09:00 PM
I tried every audio buffer with sync/desync and unfortunately there is no combination that seems to solve the issue.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 29, 2014, 08:45:11 AM
What about restarting rather than resuming?  Are you loading a savestate, slot save, or something?
Title: Re: 3.0 Alpha Testing
Post by: Marleau on December 29, 2014, 10:01:57 AM
Yes I always restarted and I still have audio lag. Sorry I forgot to mention it un my previous post
Title: Re: 3.0 Alpha Testing
Post by: rafar on December 29, 2014, 11:00:15 AM
I think the alpha has audio lag, happened to me with previous versions and with actual versions, but that doesnt important, the alpha is much better than the 2.4.4 version, games like dk64 or banjo tooie are both playable now, all cant be perfect.
Title: Re: 3.0 Alpha Testing
Post by: JoseDelgado on December 30, 2014, 08:27:58 AM
Forget it ill just seny my phone to fix
Title: Re: 3.0 Alpha Testing
Post by: Paul on December 30, 2014, 08:53:03 AM
@JoseDelgado, did you have any luck installing the 3.0 Alpha build?
Title: Re: 3.0 Alpha Testing
Post by: sdot_thadon on December 31, 2014, 08:01:57 AM
Hey guys, Noticed some new things going on here so I thought I'd  start testing some things here and there from version 10. I tried out wwf no mercy and everything was pretty much the same aside from a few sound hiccups here and there. I just got a new device however so for a little while I'll  be able to test from 2 different  phones. I tried it out on the note 4 and got mirrored textures if that's  what you call it with rice video plug-ins only. Could not reproduce  it on the note 2.  I'll  come back and upload pics in a bit.
Title: Re: 3.0 Alpha Testing
Post by: sdot_thadon on December 31, 2014, 08:58:31 AM
(http://i1170.photobucket.com/albums/r522/sdot_thadon/wwf_no_mercy-002.png) (http://s1170.photobucket.com/user/sdot_thadon/media/wwf_no_mercy-002.png.html)
(http://i1170.photobucket.com/albums/r522/sdot_thadon/wwf_no_mercy-000.png) (http://s1170.photobucket.com/user/sdot_thadon/media/wwf_no_mercy-000.png.html)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 31, 2014, 01:03:25 PM
Rice is a mess now with repeating graphics meshing all over the screen in most cases and black borders are covered in it as well.
The death pits like the one in Cauldron Keep on Banjo-Tooie also have repeating graphics.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on December 31, 2014, 10:55:57 PM
@Paul

Alpha 12 https://github.com/mupen64plus-ae/mupen64plus-ae/commit/80438bcba13e3e1a78999208d01b58a729703949
https://github.com/mupen64plus-ae/mupen64plus-ae/commit/762b18e2b1d77ee2536537c85ba64064e92c0318

Alpha 11 https://github.com/mupen64plus-ae/mupen64plus-ae/commit/e66efb39e76320f5c6f9579e7c6cef0607006d28

Alpha 11 does not need to be tested unless regressions are found in Alpha 12.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 01, 2015, 04:57:01 AM
I'm on it.  And back from vacation, so I'm back in the game as well :)
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v on January 01, 2015, 05:27:41 AM
Are high-res textures currently not supported in alpha 3.0 test ? (testing alpha 10 on my tablet)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 08:57:33 AM
@Paul - If you haven't built alpha 12 yet, hold off.  I'm going to add one more change to master.

Edit: Ok use this one for alpha 12: https://github.com/mupen64plus-ae/mupen64plus-ae/commit/762b18e2b1d77ee2536537c85ba64064e92c0318
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 01, 2015, 10:40:54 AM
Here are the latest test builds:

Alpha 12 (http://www.paulscode.com/source/Mupen64Plus-AE/01JAN2015/Mupen64Plus_debug_a12.apk)  (Sync audio-sdl)  762b18e (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/762b18e2b1d77ee2536537c85ba64064e92c0318)

Alpha 11 (http://www.paulscode.com/source/Mupen64Plus-AE/01JAN2015/Mupen64Plus_debug_a11.apk)  (Sync core)  e66efb3 (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/e66efb39e76320f5c6f9579e7c6cef0607006d28)

Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 10:57:05 AM
Are high-res textures currently not supported in alpha 3.0 test ? (testing alpha 10 on my tablet)

High-res textures are only supported in Rice for now.  The front-end for importing them is convoluted at the moment; you may find it easiest to just extract them manually to
Code: [Select]
<sdcard>/mupen64plusae-v3-alpha/CoreConfig/UserData/mupen64plus/hires_texture/
Title: Re: 3.0 Alpha Testing
Post by: chris6647 on January 01, 2015, 11:24:28 AM
Hello :)
I'm new here and since getting my hands on a Nvidia Shield tablet along with 3 Nvidia Wireless controllers (want 4 total so i can play mario kart etc with my friends). I've been attempting to use mupen64plus ae for my emulation needs, though i've been experiencing lots of issues and crashes which i would love to help ressolve if possible. I'm a normal android developer so i do have some understanding of how things work, though i've not yet played with native c in android. I attempted to get the code up and running locally, but have trouble getting everything i need to work on my windows 8.1 machine (cygwin just wont install for me).

It seems that i'm supposed to be able to send you guys crash logs from within the alpha app, however the logcat seems to indicate that's not working. Below is the crash i experience almost all the time when exiting emulation. My nividia shield tablet is running the latest OTA 5.0.1 android btw.

Code: [Select]
01-01 18:13:08.938    1538-1913/? I/AudioFlinger﹕ AUDIO_OUTPUT_FLAG_FAST accepted: frameCount=11258 mFrameCount=512
01-01 18:13:08.983  26502-26502/org.mupen64plusae.v3.alpha I/GameLifecycleHandler﹕ onPause
01-01 18:13:08.987  26502-26502/org.mupen64plusae.v3.alpha D/Core﹕ Emulation paused.
01-01 18:13:09.760  26502-26502/org.mupen64plusae.v3.alpha I/Choreographer﹕ Skipped 44 frames!  The application may be doing too much work on its main thread.
01-01 18:13:09.849  26502-26502/org.mupen64plusae.v3.alpha I/GameLifecycleHandler﹕ surfaceDestroyed
01-01 18:13:09.849  26502-26502/org.mupen64plusae.v3.alpha D/Core﹕ Stopping emulation.
01-01 18:13:09.906  26502-27207/org.mupen64plusae.v3.alpha D/Core﹕ Saved state to: yyyy-mm-dd-hh-mm-ss.sav
01-01 18:13:09.925  26502-27207/org.mupen64plusae.v3.alpha I/Core﹕ R4300 emulator finished.
01-01 18:13:09.934  26502-27222/org.mupen64plusae.v3.alpha W/art﹕ Native thread exiting without having called DetachCurrentThread (maybe it's going to use a pthread_key_create destructor?): Thread[24,tid=27222,Native,Thread*=0x62d13100,peer=0x13d130e0,"Thread-4794"]
01-01 18:13:09.935  26502-27214/org.mupen64plusae.v3.alpha W/art﹕ Native thread exiting without having called DetachCurrentThread (maybe it's going to use a pthread_key_create destructor?): Thread[22,tid=27214,Native,Thread*=0x5ef13100,peer=0x13d05080,"Thread-4790"]
01-01 18:13:09.953  26502-27207/org.mupen64plusae.v3.alpha I/GameSurface﹕ Destroying GL context
01-01 18:13:09.953  26502-27207/org.mupen64plusae.v3.alpha V/GameSurface﹕ Unbound EGL rendering context from EGL window surface
01-01 18:13:09.963  26502-27207/org.mupen64plusae.v3.alpha V/GameSurface﹕ Destroyed EGL window surface
01-01 18:13:09.966  26502-27207/org.mupen64plusae.v3.alpha V/GameSurface﹕ Destroyed EGL rendering context
01-01 18:13:09.966  26502-27207/org.mupen64plusae.v3.alpha V/GameSurface﹕ Terminated EGL display connection
01-01 18:13:09.985  26502-27207/org.mupen64plusae.v3.alpha D/Core﹕ Rom closed.
01-01 18:13:09.993  26502-26502/org.mupen64plusae.v3.alpha I/ae-bridge﹕ Unloading native libraries
01-01 18:13:10.014  26502-27207/org.mupen64plusae.v3.alpha A/libc﹕ Fatal signal 11 (SIGSEGV), code 1, fault addr 0x7ba76cd4 in tid 27207 (CoreThread)
01-01 18:13:10.034    1538-1886/? E/audio_a2dp_hw﹕ adev_set_parameters: ERROR: set param called even when stream out is null
01-01 18:13:10.114  26502-26502/org.mupen64plusae.v3.alpha I/GameLifecycleHandler﹕ onStop
01-01 18:13:10.114  26502-26502/org.mupen64plusae.v3.alpha I/GameLifecycleHandler﹕ onDestroy
01-01 18:13:10.121    1535-1535/? I/DEBUG﹕ *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-01 18:13:10.121    1535-1535/? I/DEBUG﹕ Build fingerprint: 'nvidia/wx_un_do/shieldtablet:5.0.1/LRX22C/29082_493.9700:user/release-keys'
01-01 18:13:10.121    1535-1535/? I/DEBUG﹕ Revision: '0'
01-01 18:13:10.121    1535-1535/? I/DEBUG﹕ ABI: 'arm'
01-01 18:13:10.122    1535-1535/? I/DEBUG﹕ pid: 26502, tid: 27207, name: CoreThread  >>> org.mupen64plusae.v3.alpha <<<
01-01 18:13:10.122    1535-1535/? I/DEBUG﹕ signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7ba76cd4
01-01 18:13:10.142    1535-1535/? I/DEBUG﹕ r0 63b24f60  r1 7ba76cd5  r2 7ba76cd5  r3 00000000
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ r4 00000084  r5 00000021  r6 00000004  r7 00000009
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ r8 800c3db0  r9 4013f0c8  sl 00000000  fp 4013ee60
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ ip 4013a69c  sp 800c3d38  lr 400e8227  pc 7ba76cd4  cpsr 600f0030
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ backtrace:
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ #00 pc 7ba76cd4  <unknown>
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ #01 pc 00017225  /system/lib/libc.so (pthread_key_clean_all()+80)
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ #02 pc 00016ea3  /system/lib/libc.so (pthread_exit+30)
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ #03 pc 00016bb5  /system/lib/libc.so (__pthread_start(void*)+32)
01-01 18:13:10.143    1535-1535/? I/DEBUG﹕ #04 pc 00014ba3  /system/lib/libc.so (__start_thread+6)
01-01 18:13:10.562    1535-1535/? I/DEBUG﹕ Tombstone written to: /data/tombstones/tombstone_08
01-01 18:13:10.574   1803-27533/? W/ActivityManager﹕ Force finishing activity org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.PlayMenuActivity
01-01 18:13:10.624    1544-1544/? D/phs:ipc-loc﹕ Socket 14: hangup from client "org.mupen64plusae.v3.alpha"
01-01 18:13:10.629    1803-1819/? I/WindowState﹕ WIN DEATH: Window{3dc4c550 u0 org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity}
01-01 18:13:10.649    1803-2391/? I/WindowState﹕ WIN DEATH: Window{315740c4 u0 org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GameActivity}
01-01 18:13:10.650    1803-2391/? W/WindowManager﹕ Force-removing child win Window{39652809 u0 SurfaceView} from container Window{315740c4 u0 org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GameActivity}
01-01 18:13:10.661    1803-1893/? W/InputDispatcher﹕ channel '2f9fc93d org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.PlayMenuActivity (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
01-01 18:13:10.661    1803-1893/? E/InputDispatcher﹕ channel '2f9fc93d org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.PlayMenuActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
01-01 18:13:10.662    1803-1893/? W/InputDispatcher﹕ channel '2078cae Toast (server)' ~ Consumer closed input channel or an error occurred.  events=0x9
01-01 18:13:10.662    1803-1893/? E/InputDispatcher﹕ channel '2078cae Toast (server)' ~ Channel is unrecoverably broken and will be disposed!
01-01 18:13:10.677    1546-1546/? I/Zygote﹕ Process 26502 exited due to signal (11)
01-01 18:13:10.681    1803-2145/? W/WindowManager﹕ Failed looking up window
    java.lang.IllegalArgumentException: Requested window android.os.BinderProxy@3cf8e273 does not exist
            at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:8423)
            at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:8414)
            at com.android.server.wm.WindowState$DeathRecipient.binderDied(WindowState.java:1113)
            at android.os.BinderProxy.sendDeathNotice(Binder.java:551)
01-01 18:13:10.681    1803-2145/? I/WindowState﹕ WIN DEATH: null
01-01 18:13:10.681    1803-6334/? I/WindowState﹕ WIN DEATH: Window{2f9fc93d u0 org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.PlayMenuActivity}
01-01 18:13:10.681    1803-6334/? W/InputDispatcher﹕ Attempted to unregister already unregistered input channel '2f9fc93d org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.PlayMenuActivity (server)'
01-01 18:13:10.683    1803-2459/? I/WindowState﹕ WIN DEATH: Window{2078cae u0 Toast}
01-01 18:13:10.683    1803-2459/? W/InputDispatcher﹕ Attempted to unregister already unregistered input channel '2078cae Toast (server)'
01-01 18:13:10.688    1803-2147/? I/ActivityManager﹕ Process org.mupen64plusae.v3.alpha (pid 26502) has died
01-01 18:13:10.716  27536-27536/? I/art﹕ Late-enabling -Xcheck:jni
01-01 18:13:10.719    1803-2147/? I/ActivityManager﹕ Start proc org.mupen64plusae.v3.alpha for activity org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity: pid=27536 uid=10188 gids={50188, 9997, 3003, 1028, 1015} abi=armeabi-v7a
01-01 18:13:10.745    1803-8523/? I/OpenGLRenderer﹕ Initialized EGL, version 1.4
01-01 18:13:10.828  27536-27536/org.mupen64plusae.v3.alpha D/ACRA﹕ ACRA is enabled for org.mupen64plusae.v3.alpha, intializing...
01-01 18:13:10.846  27536-27536/org.mupen64plusae.v3.alpha D/ACRA﹕ Looking for error files in /data/data/org.mupen64plusae.v3.alpha/files
01-01 18:13:10.847  27536-27536/org.mupen64plusae.v3.alpha D/ACRA﹕ Looking for error files in /data/data/org.mupen64plusae.v3.alpha/files
01-01 18:13:10.848  27536-27536/org.mupen64plusae.v3.alpha V/ACRA﹕ About to start ReportSenderWorker from #checkReportOnApplicationStart
01-01 18:13:10.852  27536-27558/org.mupen64plusae.v3.alpha D/ACRA﹕ #checkAndSendReports - start
01-01 18:13:10.852  27536-27558/org.mupen64plusae.v3.alpha D/ACRA﹕ Looking for error files in /data/data/org.mupen64plusae.v3.alpha/files
01-01 18:13:10.852  27536-27558/org.mupen64plusae.v3.alpha I/ACRA﹕ Sending file 1419539745000-approved.stacktrace
01-01 18:13:10.866  27536-27558/org.mupen64plusae.v3.alpha D/ACRA﹕ Connect to http://paulscode.iriscouch.com/acra-mupen64plusae/_design/acra-storage/_update/report
01-01 18:13:10.885  27536-27536/org.mupen64plusae.v3.alpha V/OUYAF﹕ ODK version number: 62
01-01 18:13:10.885  27536-27536/org.mupen64plusae.v3.alpha W/OUYAF﹕ Not running on Ouya hardware: shieldtablet
01-01 18:13:10.986  27536-27558/org.mupen64plusae.v3.alpha D/ACRA﹕ Sending request to http://paulscode.iriscouch.com/acra-mupen64plusae/_design/acra-storage/_update/report/740a026f-6db1-4629-84d2-ee46512afc42
01-01 18:13:11.003    1803-1803/? W/NotificationService﹕ Object died trying to hide notification android.app.ITransientNotification$Stub$Proxy@203e5e9c in package org.mupen64plusae.v3.alpha
01-01 18:13:11.152  27536-27551/org.mupen64plusae.v3.alpha I/art﹕ Background partial concurrent mark sweep GC freed 4224(256KB) AllocSpace objects, 3(48KB) LOS objects, 47% free, 1138KB/2MB, paused 5.014ms total 23.097ms
01-01 18:13:11.234  27536-27558/org.mupen64plusae.v3.alpha W/DefaultRequestDirector﹕ Authentication error: Unable to respond to any of these challenges: {}
01-01 18:13:11.236  27536-27558/org.mupen64plusae.v3.alpha E/ACRA﹕ Failed to send crash report for 1419539745000-approved.stacktrace
    org.acra.sender.ReportSenderException: Error while sending JSON report via Http PUT
            at org.acra.sender.HttpSender.send(HttpSender.java:250)
            at org.acra.SendWorker.sendCrashReport(SendWorker.java:179)
            at org.acra.SendWorker.checkAndSendReports(SendWorker.java:141)
            at org.acra.SendWorker.run(SendWorker.java:77)
     Caused by: java.io.IOException: Host returned error code 401
            at org.acra.util.HttpRequest.send(HttpRequest.java:177)
            at org.acra.sender.HttpSender.send(HttpSender.java:247)
            at org.acra.SendWorker.sendCrashReport(SendWorker.java:179)
            at org.acra.SendWorker.checkAndSendReports(SendWorker.java:141)
            at org.acra.SendWorker.run(SendWorker.java:77)

Also had problems with some games not recognizing all shield controllers for the multiple players, even though the mulator and android itself were able to detect them. As well as skipping frames, laggy image and audio.

Please let me know if i can do more to help. I will probably attempt getting the code to compile and install locally again later, but i'm gonna  take a break from it for now :)
/Chris
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 11:41:07 AM
Awesome, thanks for the detailed info.

Crash logs should be saved to mupen64plusae-v3-alpha/CrashLogs.  You can also access the logcat from the main gallery, but that is a different feature.

You don't need cygwin to build the app in windows.  You just need Eclipse, Android-SDK, and Android-NDK.  After you clone the repository, open Eclipse and Import "Existing Android Code Into Workspace".  Then right-click the project, select Android Tools -> "Add Native Support".  Provide a dummy name like "Foo" then look in the jni folder and delete Foo.cpp.  You might also need to specify the NDK/SDK locations in Eclipse settings (going off the top of my head).
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 01, 2015, 11:47:13 AM
(quoted from the 2.5 thread here since I didn't want to resurrect it)

And Tegra K1 appears to have an offset of -0.95. Tested with Glide64+SM64 star road since it shows incorrect offsets the most.

Closest existing profile would be O2.. I suppose the shadows are floating off the ground with offset -1.5?  Just wanted to confirm before adding another profile.  Do you have the hardware info output?
Title: Re: 3.0 Alpha Testing
Post by: chris6647 on January 01, 2015, 01:09:34 PM
You don't need cygwin to build the app in windows.  You just need Eclipse, Android-SDK, and Android-NDK.  After you clone the repository, open Eclipse and Import "Existing Android Code Into Workspace".  Then right-click the project, select Android Tools -> "Add Native Support".  Provide a dummy name like "Foo" then look in the jni folder and delete Foo.cpp.  You might also need to specify the NDK/SDK locations in Eclipse settings (going off the top of my head).

I'd tried that too, but for some reason when i try to tell Eclipse of the NDK location, it just says its an invalid path :S

(quoted from the 2.5 thread here since I didn't want to resurrect it)

And Tegra K1 appears to have an offset of -0.95. Tested with Glide64+SM64 star road since it shows incorrect offsets the most.

Closest existing profile would be O2.. I suppose the shadows are floating off the ground with offset -1.5?  Just wanted to confirm before adding another profile.  Do you have the hardware info output?

Not sure if the profile information is supposed to be for me? If so, i dont know what to do with it i'm afraid.

Would this be what you're asking for?

Code: [Select]
Device: NVidia Virtual Mouse
Id: -3
Descriptor: d6e8e58dd6e9a1f15dbf8163763911b0edabba60
Class: BUTTON, POINTER
Axes: 3
AXIS_X (touchscreen): ( 0.0 , 1919.0 )
AXIS_Y (touchscreen): ( 0.0 , 1199.0 )
AXIS_PRESSURE (touchscreen): ( 0.0 , 1.0 )

Device: Virtual
Id: -1
Descriptor: a718a782d34bc767f4689c232d64d527998ea7fd
Class: BUTTON

Device: gpio-keys.4
Id: 2
Descriptor: 485d69228e24f5e46da1598745890b214130dbc4
Class: BUTTON

processor : 0
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

processor : 1
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

processor : 2
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

processor : 3
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

Hardware : tn8
Revision : 0000
Serial : XXXX
Processor : ARMv7 Processor rev 3 (v7l)

Board: unknown
Brand: nvidia
Device: shieldtablet
Display: LRX22C.29082_493.9700
Host: mobile-u64-512
ID: LRX22C
Manufacturer: NVIDIA
Model: SHIELD Tablet
Product: wx_un_do
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 01, 2015, 01:51:34 PM
Has to be -0.95. With the O2 profile, when I'm on the top of the hill outside the castle in Mario Star Road, the water visually floods over the ground, when it should be in the moat only. Shadows incidentally are fine, but -0.95 is the best balance between flood and shadow clipping.
Hardware info.
Code: [Select]
Device: NVIDIA Corporation NVIDIA Controller v01.03
Type: Default
Signature: 0,1,11,14,15,16,17,18,22,23
Hash: 1574644603
  AXIS_X: Stick
  AXIS_Y: Stick
  AXIS_Z: Stick
  AXIS_RZ: Stick
  AXIS_RTRIGGER: Trigger
  AXIS_GAS: Trigger
  AXIS_LTRIGGER: Trigger
  AXIS_BRAKE: Trigger
  AXIS_HAT_X: Stick
  AXIS_HAT_Y: Stick

Device: NVidia Virtual Mouse
Id: -3
Descriptor: d6e8e58dd6e9a1f15dbf8163763911b0edabba60
Class: BUTTON, POINTER
Axes: 3
  AXIS_X (touchscreen): ( -1.0 , 1.0 )
  AXIS_Y (touchscreen): ( -1.0 , 1.0 )
  AXIS_PRESSURE (touchscreen): ( 0.0 , 1.0 )

Device: Virtual
Id: -1
Descriptor: a718a782d34bc767f4689c232d64d527998ea7fd
Class: BUTTON

Device: gpio-keys.4
Id: 5
Descriptor: 485d69228e24f5e46da1598745890b214130dbc4
Class: BUTTON

Device: NVIDIA Corporation NVIDIA Controller v01.03
Id: 10
Descriptor: a691ea53a0f5aabd5e2dd0674f6ce7c0c6aca61f
Vibrator: true
Class: BUTTON, POINTER, JOYSTICK
Axes: 13
  AXIS_X (touchscreen): ( -1.0 , 1.0 )
  AXIS_Y (touchscreen): ( -1.0 , 1.0 )
  AXIS_PRESSURE (touchscreen): ( 0.0 , 1.0 )
  AXIS_X (joystick): ( -1.0 , 1.0 )
  AXIS_Y (joystick): ( -1.0 , 1.0 )
  AXIS_Z (joystick): ( -1.0 , 1.0 )
  AXIS_RZ (joystick): ( -1.0 , 1.0 )
  AXIS_RTRIGGER (joystick): ( 0.0 , 1.0 )
  AXIS_GAS (joystick): ( 0.0 , 1.0 )
  AXIS_LTRIGGER (joystick): ( 0.0 , 1.0 )
  AXIS_BRAKE (joystick): ( 0.0 , 1.0 )
  AXIS_HAT_X (joystick): ( -1.0 , 1.0 )
  AXIS_HAT_Y (joystick): ( -1.0 , 1.0 )

processor : 0
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

processor : 1
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

processor : 2
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

processor : 3
model name : ARMv7 Processor rev 3 (v7l)
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc0f
CPU revision : 3

Hardware : tn8
Revision : 0000
Serial : XXXX
Processor : ARMv7 Processor rev 3 (v7l)

Board: unknown
Brand: nvidia
Device: shieldtablet
Display: KOT49H.22229_440.9583
Host: mobile-u64-428
ID: KOT49H
Manufacturer: NVIDIA
Model: SHIELD Tablet
Product: wx_na_wf

Also, sorry to bring it up again, but whatever version of Gillou's build I have does NOT crash when exiting, unlike master which crashes on some pthread issue. I believe it was the last Banjo-Tooie dynarec fix build. Additionally, I prefer how Gillou moved the rendering resolution and screen stretch settings from Global settings into the emulation profiles, useful with the rice wide screen hack setting for example.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 01, 2015, 03:17:28 PM
I still have the last Gillou build apk before it was taken down to avoid "confusion" apparently.

Curse this dreaded cold chill today!  >:(
I will probably take a lot longer to test the Alpha because of this coldness. :(
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 01, 2015, 03:27:38 PM
The confusion comes from the fact that it is not in the direct ancestry of the Alpha tests.  Like I mentioned you can post it, just not on this thread which is about the alpha tests.  Comparisons are really not helpful though without a link to the commit (assuming it was pushed to github).
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 01, 2015, 03:37:43 PM
I have started to manually bisect Gillou's branch in hopes I can find something.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 03:50:39 PM
Also, sorry to bring it up again, but whatever version of Gillou's build I have does NOT crash when exiting, unlike master which crashes on some pthread issue.

The reason the crash still exists in Alpha12 is because I haven't started working on it yet ;)  I wanted to get us all synced up with upstream before diving into the front-end Android stuff.  We are now very close to perfect sync so I will probably be addressing all these things in the next week or two.

I already dissected Gilles' (and xperia64's) branches several weeks ago, and archived them here:
https://github.com/littleguy77/mupen64plus-ae/branches/all

so I have a pretty good handle on the diffs between Gilles' build and the alpha tests.  I'm pretty sure it's a lifecycle thing, related to unloading a library or destroying a thread, as those are some of the principal remaining differences between Gilles' branch and the mainline.  Probably the easiest workflow is for me to start a little branch that xperia64 can test, and the two of us can iterate until we find the fix.

Additionally, I prefer how Gillou moved the rendering resolution and screen stretch settings from Global settings into the emulation profiles, useful with the rice wide screen hack setting for example.

Yeah, I was going to bring that up for discussion on the brainstorming thread after I took care of the more critical fixes.  There are a few pros and cons that are worth discussing before I make the switch (it's not hard to do).
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 01, 2015, 03:52:54 PM
The offscreen audio is no longer getting distortion with Banjo-Kazooie on Alpha 12. ;D

One minor GUI bug from updating to 12 made my added cheats hidden and internally disabled,but I easily fixed it by saving the cheats again to refresh the list.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 01, 2015, 03:56:28 PM
-snip-
Fair enough. And part of the crash is fixed, as when the native crash kicks me back to galleryactivity I can select a game again without having to completely kill the app.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 03:56:52 PM
The offscreen audio is no longer getting distortion with Banjo-Kazooie on Alpha 12. ;D

Awesome!  Alpha12 re-enabled audio resampling by reverting to the upstream implementation.  Must have been the cause of the problem.

One minor GUI bug from updating to 12 made my added cheats hidden and internally disabled,but I easily fixed it by saving the cheats again to refresh the list.

Just so I understand, did you use the built-in cheat editor in the app, or did you manually modify mupencheat with a text editor?
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 01, 2015, 04:02:11 PM
I already dissected Gilles' (and xperia64's) branches several weeks ago, and archived them here:
https://github.com/littleguy77/mupen64plus-ae/branches/all

Yep.. comparing commits on those branches will be considerably more useful than comparing to a build without context.  And they can be bisected to find the source of specific behaviors.  ;D
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 01, 2015, 04:05:51 PM
One minor GUI bug from updating to 12 made my added cheats hidden and internally disabled,but I easily fixed it by saving the cheats again to refresh the list.

Just so I understand, did you use the built-in cheat editor in the app, or did you manually modify mupencheat with a text editor?
I also noticed this issue with the cheats I added with the built-in editor. The custom cheats are gone until you go into manage cheat codes and save again. Probably because the volatile mupencheat.txt is erased and needs to be recreated after the data is re-extracted.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 04:08:05 PM
And they can be bisected to find the source of specific behaviors.  ;D

I split up the original branches simply by dealing out the individual commits to separate branches.  In a few cases I split some of the original commits (e.g. where multiple plugins were modified in the same commit).  So although the content is consolidated, many of the commits may fail to build or run.  They are mostly useful for visually inspecting the modifications and getting the "gist" of what was changed and why.  Probably not useful for blind git-bisecting.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 04:09:21 PM
Probably because the volatile mupencheat.txt is erased and needs to be recreated after the data is re-extracted.

My thoughts too.  I thought we had already addressed that but maybe it slipped through the cracks.  Will add to the todo list.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 01, 2015, 04:27:48 PM
DK64 is running great.
The DK Rap had a Kremlin model spaz on the Tiny Kong scene.
I got the tree teleport glitch once,but at least no vines are spazzing out.

Creepy Castle has a spot in front of Snide's HQ with the "club enemy" where the models spaz out and stretch.
It happens normally in other builds,but I neglected to mention it.
Title: Re: 3.0 Alpha Testing
Post by: SuperL on January 01, 2015, 09:26:29 PM
The latency is much better on the newest alpha. Hardly any of the audio is out-of-sync with the video.

Paper Mario has an issue, though. I don't know if this is a regression or not but Text becomes invisible at various points.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 01, 2015, 09:27:08 PM
The invisible text is a known issue with glide, maybe the other video plugins too.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 01, 2015, 09:31:50 PM
Paper Mario has an issue, though. I don't know if this is a regression or not but Text becomes invisible at various points.

Thanks.  Do any of the previous alphas resolve the issue?  We are inch-by-inch synchronizing with the desktop version of mupen64plus, and finding regressions (new bugs that weren't in a previous alpha build) is the most important thing for us right now.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 01, 2015, 11:26:29 PM
Just tried paper Mario with Glide64-fast on the first buildbot build. The first cutscene where Mario falls into a field and the star spirits talk uses text with a special static effect which actually shows up now, though just faint instead of animated (previously the text was invisible)
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 01, 2015, 11:38:31 PM
Quest64 had an issue with the hippo-like enemy's water attack being untextured on Alpha 4 but it is fixed in Alpha 12.
So much nostalgia playing this game again. :)
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 02, 2015, 05:53:59 PM
I tested alpha 12 and I still have audio lag on my lg g2. I tried with sync and no sync options but it keeps the same result... anyone else who happen this?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 02, 2015, 06:28:27 PM
@rafar - Do you get the same audio lag on the published version (2.4.4)?  Do you get the same audio lag on Alpha 1?
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 02, 2015, 08:25:23 PM
Know what I love about Alpha 12?
The fact that it runs Banjo-Tooie on my x86 tablet! ;D
Probably because of the vanilla core and audio changes.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 02, 2015, 08:30:25 PM
Great :D  Probably because Gilles' fixes to the dynarec got merged into upstream core, then pulled downstream between Alpha10 and Alpha11.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 02, 2015, 09:50:56 PM
Alpha 13: http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501031150_3beac96.apk

I expect to see new visual artifacts between Alpha 11 and 13 due to the removal of glState.cpp.  See the commit message (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/6099d0a376dd4026a1717ff4c8fa424014d1a05b) for a full explanation.  Expect to see missing polygons, missing elements in the HUD, and garbage graphics.  I already fixed a few -- see this (https://github.com/mupen64plus-ae/mupen64plus-ae/commit/47d3c9ee386848743b7dde17afc27ee421603878) commit message.

We really need alpha testers to hunt down all the visual regressions in glide.  Testers should compare Alphas 11, 12, and 13.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 03, 2015, 12:12:35 AM
So that's why Alpha 12 Banjo-Tooie has missing objects with Glide64 on my x86 tablet.
I can even get a really decent performance with CountPerOp=1 set.
Also,Rice is causing a logless game crash with Banjo-Tooie when attempting the JiggyWiggy Challenge 2.

I hope the slowdown issues from the first Alpha onward get fixed soon.
The difference in Super Smash Bros. performance is staggering.

Unrelated to Alpha:I hope Gillou can prepare his x86 test build so I can see if it runs Banjo-Tooie even better.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 03, 2015, 02:46:56 AM
@rafar - Do you get the same audio lag on the published version (2.4.4)?  Do you get the same audio lag on Alpha 1?

on 2.4.4 I have a good sync (only tested on super mario 64).

pd: pokemon snap controls are fixed on alpha 12 ;D
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 03, 2015, 08:58:08 AM
So that's why Alpha 12 Banjo-Tooie has missing objects with Glide64 on my x86 tablet.

Can you provide some details please?  Are the objects not missing in Alpha 11?  What are the missing objects?  Can you provide a savestate so that we can easily reproduce and check?
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 03, 2015, 12:48:17 PM
Alpha 12 was the first one I tried that lets me run Banjo-Tooie on my x86 tablet.

Nevermind about the missing parts,it appears to be the same issue from my FireTV using Glide64 since the beehive model is missing the bottom portion like before.

Edit:I will post screenshots anyway.

http://www.2shared.com/photo/sG9gjuMb/banjo_tooie-000.html

http://www.2shared.com/photo/UeCmYV37/banjo_tooie-001.html

http://www.2shared.com/photo/QlN6JsdO/banjo_tooie-002.html

I am glad to see my screenshots are in top quality. ;D

I have a favor to ask,can the image database for the game boxart use highly compressed jpg to save more space AND your bandwidth.
If not that,please try to make the png files even smaller without sacrificing too much quality.
Are you using pure images or recreated thumbnails?
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 03, 2015, 01:51:09 PM
Tried the normally temperamental games with a lot of 2D (Mario Party, Animal Crossing, Paper Mario, OOT, Yoshi's Story) with Alpha13.

Mario Party is fine, Animal Crossing has slightly different, but still broken black squares on the pause menu.

The flipping animation in the paper mario file select has some more garbage than before.

Yoshi's Story, World 1-3 at least has some issues, but I'll have to check a Alpha 12

One small unrelated issue: the gallery menu thinks my OOT rom is Japanese, which it isn't.

Title: Re: 3.0 Alpha Testing
Post by: rafar on January 03, 2015, 02:53:43 PM
pokemon stadium has on the last alpha, black images on the first menu. That not happens on alpha 10 and 12.

(we should make a list with all bugs and problems and each tester play several games)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 03, 2015, 02:55:33 PM
I have a favor to ask,can the image database for the game boxart use highly compressed jpg to save more space AND your bandwidth.

The entire image database is 78 MB.  That's 421 images.  The largest is 130 KB, the median is 100 KB.  I really don't think this is worth talking about since most games on Google Play are 10-100 MB.  If we use jpg compression we can probably cut space in half, but that's as far as I'm willing to go.  They are already very low resolution images.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 03, 2015, 02:58:19 PM
Yoshi's Story, World 1-3 at least has some issues, but I'll have to check a Alpha 12

Also check Alpha 11

One small unrelated issue: the gallery menu thinks my OOT rom is Japanese, which it isn't.

Yeah, it probably wasn't found in the database and just selected the first match.  Prompting the user to select the match is still on the todo list (but in truth is pretty low priority since it doesn't harm anything).
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 03, 2015, 03:31:40 PM
Yoshi Story looks perfect with Glide64 on the second auto build at least.
It is really slow though because of whatever introduced lag into the Alpha builds,such as the fast forward bug.
The Jungle Puddle water surface always had a "black buffering" issue that happens with every standard plugin.
It also happens with every N64 emulator to ever exist.
The only one that works well enough is a software plugin on PJ64 which is compared as immensely slow for obvious reasons.

I hope Gonetz can get the Yoshi Story water buffer issue fixed for GlideN64.
I wonder if it is similar to Sega Genesis with Sonic games using horizntal interrupt to render water?
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on January 03, 2015, 04:28:11 PM
Worms Armageddon crashes the app.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 03, 2015, 06:23:44 PM
The Yoshi's Story thing was a one-off bug with the Alpha13. In fact, Alpha 12 has a more issues with the main menu (the nintendo logo was Glide64's font set I think, and there were some z-layering issues)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 03, 2015, 07:50:47 PM
Paul set up an auto-build system :)  So for those following here is Alpha 13 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501031150_3beac96.apk).

For those who are new to software development, a regression is a bug that did not exist in a previous build, but now exists in a new build.  In other words, a regression is a new bug.  I expect there to be regressions going from Alpha 11 (http://www.paulscode.com/source/Mupen64Plus-AE/01JAN2015/Mupen64Plus_debug_a11.apk) to Alpha 12 (http://www.paulscode.com/source/Mupen64Plus-AE/01JAN2015/Mupen64Plus_debug_a12.apk), and more regressions going from Alpha 12 (http://www.paulscode.com/source/Mupen64Plus-AE/01JAN2015/Mupen64Plus_debug_a12.apk) to Alpha 13 (http://Alpha 13: http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501031150_3beac96.apk).

It would help tremendously if testers could provide very specific information:
 1. What new bug are you seeing
 2. What is the first alpha version that displays the bug
 3. What is the last version that does not display the bug
 4. The exact ROM name as shown at the top of the play menu or in the gallery
 5. A savestate so that we can easily reproduce the problem
 6. Ideally, two screenshots of the same scene: one with the bug and one without the bug

Please try your best to answer all six items above, so that we don't have to keep asking more questions.  You can take savestates -- and now screenshots -- very easily using the in-game menu.
 - Savestates are saved to mupen64plusae-v3-alpha/GameData/<ROMname>/UserSaves
 - Screenshots are saved to mupen64plusae-v3-alpha/GameData/<ROMname>/Screenshots

If you find a bug that is (to the best of your knowledge) in all Alpha versions, please describe it in similar detail, and say it's a general bug that exists in all the Alphas.

If you reported a bug before but didn't provide this level of detail, I would encourage you to re-report it with the specifics listed above.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 03, 2015, 07:56:57 PM
Wouldbeen post:The graphics plugins between my ARM and X86 devices (FireTV,Iconia) look exactly identical with things like the Banjo-Tooie missing model segments with Glide64.

Actual post:I already mentioned this one,but the fast forward lag and slowdown issue was there since the very first Alpha,and has never went away in any build up to the second auto build after Alpha 12.
I will also be testing that new part whenever it is ready.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 03, 2015, 08:48:58 PM
On a different note, with glide almost synced, I'm finally getting some time to browse the backlog of changes from Gilles' and xperia64's experimental branches.  Good stuff in there!

Potential pull requests for upstream:
https://github.com/littleguy77/mupen64plus-ae/commits/Gillou68310/core-mods
https://github.com/littleguy77/mupen64plus-ae/commits/xperia64/core-mods
https://github.com/littleguy77/mupen64plus-ae/commits/Gillou68310/glide-mods
https://github.com/littleguy77/mupen64plus-ae/commits/xperia64/glide-mods
https://github.com/littleguy77/mupen64plus-ae/commits/Gillou68310/rice-mods
https://github.com/littleguy77/mupen64plus-ae/commits/xperia64/rice-mods

Potential changes to mupen64plus-ae:
https://github.com/littleguy77/mupen64plus-ae/commits/xperia64/front-mods
https://github.com/littleguy77/mupen64plus-ae/commits/Gillou68310/gln64-mods
https://github.com/littleguy77/mupen64plus-ae/commits/xperia64/gln64-mods
https://github.com/littleguy77/mupen64plus-ae/commits/xperia64/jni-mods
https://github.com/littleguy77/mupen64plus-ae/commits/Gillou68310/sdl-bridge-front-mods

In case anyone's wondering, my priorities have been
 1. Sync with upstream (almost done)
 2. Identify potential pull requests for upstream (started)
 3. Merge backlog of fixes to gln64 (started)
 4. Fix stuff in ae-bridge and sdl (e.g. crash on exit) (started)
 5. Fix broken features in java Android front-end (some work here and there)
 6. Add features to front-end (noted suggestions but not started)
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 03, 2015, 09:01:16 PM
Funny thing is most games look better instead of having regressions and Zelda OOT pauses faster now.

I do have four regressions with Conker's Bad Fur Day where the intro shadows get broken differently than usual.
Then the army door when in Mrs. Bee chapter part has a missing polygon segment.
The third one is an existing problem that got worse with the framebuffer showing a glitched/squished/white copy of the bee on the screen instead of a small part of wings.
And fourth is the ground textures are glitching around.

Let me know if I should get screenshots.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 03, 2015, 09:13:08 PM
In terms of my branch, I'd only recommend using things from these two:
https://github.com/littleguy77/mupen64plus-ae/commit/775dea862524e84553fbdcbf0f825ce3ac504270
https://github.com/littleguy77/mupen64plus-ae/commit/c5c855066ec2169ffc3f131e15677afd877ed332


Some of the others are just plain silly (me trying to track down the game quit crash and going slowly insane at the top there :P): https://github.com/littleguy77/mupen64plus-ae/commit/8b0e9a0b639f72b2b217de77f37d2fb4ac4531bb

and the graphics-related ones break things. I manually merged them from the ptitSeb's glide, gln64, and rice neon additions/tweaks and some of the changes either slow everything down, break things, and/or are only meant for the pandora's omap. Lastly, don't bother with Arachnoid. Too many hacks, not that fast, and poor compatibility. I don't know of anyone with a GLES1.1 device these days.


Regarding comment about OOT pausing faster:
Has the pause fix cheat finally been hardcoded into the core?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 03, 2015, 09:14:23 PM
Let me know if I should get screenshots.
Believe it or not, I have only played a handful of N64 games all the way through.  So all six bullet items listed above are essential to me fixing the problem.  Assume that I have never launched the game before.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 03, 2015, 09:16:36 PM
Thanks xperia64!

Regarding comment about OOT pausing faster:
Has the pause fix cheat finally been hardcoded into the core?

Yes, as of alpha 11.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 04, 2015, 04:18:56 AM
@littleguy, perfect, in my case I´ll try to help answering the 6 questions above  ;D


in my opinion, we all should note all the bugs on each game, and distribute the games... if every tester must compare 20 games every day in 3 or 4 different alphas... I think that´s crazy.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 04, 2015, 12:26:32 PM
Got tired of waiting and zipped the Conker screenshots anyway.
At least it actually let me upload a zip this time.

http://www.2shared.com/file/wIsoXkOR/Conkers_Worse_Fur_Day.html

The 2shared multiple files engine is terrible because I can't browse by folder to grab the specific image files and they don't appear in the list of many other images because of an HD texture pack.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 04, 2015, 01:32:17 PM
Not sure what you're waiting for ?

Thanks much for the screenshots, but I still can't fix anything until you answer all six questions.

1. What new bug are you seeing
 2. What is the first alpha version that displays the bug
 3. What is the last version that does not display the bug
 4. The exact ROM name as shown at the top of the play menu or in the gallery
 5. A savestate so that we can easily reproduce the problem
 6. Ideally, two screenshots of the same scene: one with the bug and one without the bug

Obviously I don't need a savestate for the bug in the rareware logo scene.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 04, 2015, 02:08:45 PM
You wouldn't need one for the others either,just enter WELDERSBENCH in the in-game cheat option to unlock all chapters like I did when testing it.

The two with the door are both when bugged,but showing how it appears when near the end of the screen.
It is also very similar to how the Banjo-Tooie glitch looks in how it fixes the model on the screen end.
These are most likely started from when the Glide64 change was first made while regressions are expected because Conker looked fine in earlier Alphas.

I should probably check the first Hangover area too.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 04, 2015, 03:08:56 PM
Just answer the questions PLEASE!  I have never played a minute of this game.  Why are you making it so difficult?
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 04, 2015, 06:51:00 PM
Not much easier for me if I have to re-download and re-install older versions,only to have to do it all over again.
Alpha 10 might be the last version where it does not have these extreme differences.
I have not touched Alpha 11 because you said to use 12.
Alpha 12 might be the first one with Conker messed up since the Glide64 something-or-other was removed.

Conker's shadow is invisible until pausing emulation.
And the patch of grass has missing blending effects.
The door and several other details could be a framebuffer individual vertex/polygon depth/clipping bug or something similar,if that term is correct.

As painful as it is to me,I will test between the older builds when I get the chance in four hours from now.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 04, 2015, 07:09:09 PM
These are TEST builds for TESTERS to TEST.  If you don't want to TEST, then just wait until 3.0 is published on Google Play.

Devs cannot FIX problems if TESTERS are not clear in their bug reporting.  We spend HOURS and DAYS systematically dissecting the code to locate the source of bugs.  We are literally looking for a needle in a haystack if testers are not specific.  If you find it too inconvenient to spend 10 minutes reinstalling older versions to save us HOURS or DAYS, then you are not a TESTER, you are a USER.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 04, 2015, 11:22:04 PM
New bugs:corrupted shadows,missing blending,some polygon/vertex invisible from bad framebuffer depth/clipping.

First version with regression:Alpha 12

Last version working:Alpha 11

Conker's Bad Fur Day (U) [!]

savestate screenshots:not needed/already provided.

I have finished testing the required ones since it already happens in Alpha 12.

Edit:To be completely honest,a large number of other pieces of level and objects like the bridges in Hungover are disappearing when looked at directly,far too many to reasonably screenshot them all.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 05, 2015, 04:35:04 AM
Sorry for dont help enough, I am on holidays yet, and my girlfrind dont leave me alone  ;D
(I know my english is poor but gimme a shot :) )

New bugs:This bug afect the left side screen when starts the game, and affects the normal performance of the game.

First versions with regression:  glide64 fast, speed (all alphas and officials)

Last versions working:glide64 accurate

Pokemon Stadium (S) [!] (Spanish version)

savestate screenshots:
(http://nsae02.casimages.net/img/2015/01/05/mini_150105120449218302.png) (http://www.casimages.es/i/150105120449218302.png.html)

Moreover the menus are afected:

glide64 accurate:

(http://nsae02.casimages.net/img/2015/01/05/mini_150105114251487520.png) (http://www.casimages.es/i/150105114251487520.png.html)

savestate file (good one)
https://drive.google.com/open?id=0B9JF6P2xH4TUYjRZRF9zNDlMdjQ&authuser=0

glide64 fast, or glide64 speed:

(http://nsae02.casimages.net/img/2015/01/05/mini_15010511455186741.png) (http://www.casimages.es/i/15010511455186741.png.html)

savestate file (alpha 11 file with bugs, glide64 fast)
https://drive.google.com/open?id=0B9JF6P2xH4TUdzdOWWw4Nm94eHM&authuser=0


Title: Re: 3.0 Alpha Testing
Post by: rafar on January 05, 2015, 04:52:40 AM
POKEMON STADIUM 2

New bugs:Intro of the game.

First versions with regression:all alphas, all plugins

Last versions working: 2.4.4, only runs ok gles2n64

Game version: Pokemon Stadium 2 (S) [!] (Spanish version)

savestate screenshots:

2.4.4 version:
(http://nsae02.casimages.net/img/2015/01/05/mini_150105115950895217.png) (http://www.casimages.es/i/150105115950895217.png.html)

(http://nsae02.casimages.net/img/2015/01/05/mini_150105120013648654.png) (http://www.casimages.es/i/150105120013648654.png.html)

all alphas:
(http://nsae02.casimages.net/img/2015/01/05/mini_150105115207644024.png) (http://www.casimages.es/i/150105115207644024.png.html)

(http://nsae02.casimages.net/img/2015/01/05/mini_150105115232558727.png) (http://www.casimages.es/i/150105115232558727.png.html)



Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 05, 2015, 06:58:03 AM
INFINITELY better.  Thanks :D

Since you guys did not post savestates, are these from the intro/opening scenes?  If they're in the middle of the game we'll need savestates (in-game menu -> Save to file...).
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 05, 2015, 07:26:34 AM
@littleguy I edit my messages for include the savefiles. Curiously with glide64 fast appears almost all bugs that I said before, however with glide64 accurate dissapear lot of them (pokemon stadium 1).

Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 05, 2015, 07:31:56 AM
@littleguy Curiously with glide64 fast appears almost all bugs that I said before, however with glide64 accurate dissapear lot of them.

That actually makes sense.  It occurred to me last night that it might happen.  I think I know where to fix it.

Signing off for the rest of the day.  My real job beckons :)
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 05, 2015, 09:22:32 AM
@littleguy  I have a question, for you devs, I know you are trying to improve and fix the regressions, so if I find bugs that appeared previously, would that information  be useful too or you are only interested in looking for regressions of the newest versions? (I dont know if I explained with enough clarity  :()
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 05, 2015, 09:56:30 AM
I can't speak for all the devs, but from my perspective, the priority would be:

Priority 1: Regressions between Alpha Test versions (for example, something broke going from Alpha 11 to Alpha 12)

Priority 2: Regressions between the Alpha Tests and the latest published version of the app (i.e. all Alpha tests, starting from Alpha 1, have a new problem that was not in 2.4.4)

The above two cases should be reported on this thread, providing as much detail as possible (as littleguy outlined), so that we can quickly and reliably reproduce the problem for easier disection.


To avoid confusion, the below cases should be reported on a new thread in Android Support, not on this thread.

Priority 3: Regressions between 2.x versions (for example, something broke going from 2.3.5 to 2.4.0)

Priority 4: Issues that were fixed on some build that is not in the general ancestry of the published releases or the 3.0 Alpha tests (for example, an experimental build that had a side-effect of fixing a problem that exists in both the 2.x and 3.0 alpha tests).  Provide as much information as possible.

Priority 5: A general problem that has always affected the app (i.e. not a regression)

This is just a general rule of thumb, though.  Actual order of priority will really depends on the specific issues themselves, with a lot of factors coming into play (seriousness, complexity, reproducibility, and so on).

Title: Re: 3.0 Alpha Testing
Post by: retroben on January 05, 2015, 12:12:24 PM
Banjo-Tooie with Rice on Alpha 1 and all later versions get this bug...

(http://i.imgur.com/Rywix0J.png)
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 05, 2015, 03:21:30 PM
DONKEY KONG 64

New bugs:Weird deformation of donkey kong character when it is there, near to cranky house.

First versions with regression:Alpha 10, alpha 11, alpha 14

Last versions working:Alpha 7 

Game version: Donkey Kong 64 (E) [!]

Screenshots and savefiles:

Alpha 7

(http://nsae02.casimages.net/img/2015/01/05/mini_150105101252342260.png) (http://www.casimages.es/i/150105101252342260.png.html)

https://drive.google.com/open?id=0B9JF6P2xH4TUWlRHYnN2YlI0dWs&authuser=0
https://www.dropbox.com/s/407fbm8ocycdmvg/dkok?dl=0


Alpha 10 and 11 version:

(http://nsae02.casimages.net/img/2015/01/05/mini_150105100931950273.png) (http://www.casimages.es/i/150105100931950273.png.html)

https://drive.google.com/open?id=0B9JF6P2xH4TUUk9yV0x2WEZQTnM&authuser=0
https://www.dropbox.com/s/83x53pdy6ywati8/dkbugAlpha10?dl=0
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 05, 2015, 04:43:54 PM
BANJO KAZOOIE

New bugs: black lines on background of menu

First versions with regression:Alpha 7 (alpha 10, alpha 11, alpha 14)

Last versions working:2.4.4

Plugin used: gliden64 (accurate, fast, speed)

Game version: Banjo Kazooie (E) (M3) [!]

Screenshots and savefiles:

Official 2.4.4:
(http://nsae02.casimages.net/img/2015/01/06/mini_150106100923734354.png) (http://www.casimages.es/i/150106100923734354.png.html)

https://drive.google.com/open?id=0B9JF6P2xH4TUeVZNdmw1Z0NEOWs&authuser=0
https://www.dropbox.com/s/tfpzad4ytq9tl3b/bk2.4.4?dl=0

Alpha 7:
(http://nsae02.casimages.net/img/2015/01/06/mini_150106100749867862.png) (http://www.casimages.es/i/150106100749867862.png.html)
https://drive.google.com/open?id=0B9JF6P2xH4TUNEl2QmFVWk9lSDg&authuser=0
https://www.dropbox.com/s/yvhj0z2xdmhsn7j/bk7bug?dl=0
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 05, 2015, 04:47:33 PM
Thanks rafar.  I cannot access any of your links - Dropbox Google permission denied.

Giving them unique versions numbers makes it harder to downgrade, and is a fair bit of extra work.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 05, 2015, 04:56:37 PM
The files are uploaded in google drive... do you prefer another way? I dont understand why you cant download it...
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 05, 2015, 05:49:23 PM
Sorry, meant to say google drive.  This is the webpage I get says

Quote
Google Drive - Access Denied

You need permission
Want in? Ask the owner for access, or switch to an account with permission. Learn more
You are signed in as [....]
Title: Re: 3.0 Alpha Testing
Post by: Sowden on January 05, 2015, 10:23:48 PM
Hey guys.  The builds are getting better and better, but I am still having the same two player problems with Goldeneye.  I have posted pictures to show my problem.  The first one shows the title of the rom and my custom controller profile.  The next one shows that I only have one controller to map.  Is this a problem with my rom or something on your end?  Thanks guys for all of your hard work.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 06, 2015, 01:56:04 AM
There is a global Rice issue in all Alpha versions I already mentioned a number of times.
It causes borders to be filled with repeated and/or doubled textures.

Just gonna link this one image here as an example since embedding went so bad for me.
LOL! Dolby's "Double D" symbol. ;D

http://www.2shared.com/photo/i7bgjdMX/banjo_tooie-001.html

It looks fine on 2.4.4 and on two "certain" others before Alpha 1.
An extra clue of what is changed would be that Super Smash Bros. had the popout stage elements issue before,and it was fixed by Alpha 1,but with this new repeating texture issue as the sacrifice.
Super Smash Bros. already had some rendering issues on Rice,but now is even worse since more games like Banjo-Tooie are affected.

And don't over-react at me not being precise enough!
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 02:18:17 AM
@Paul thanks, that info it is really useful for me. But I have an another question (or two  ;D)

as you said to me, it is possible find and fix an issue or regression between 2 alphas version or official 2.4.4 or previous:

it is possible or useful for devs find bugs there are in one plugin in the same alpha? I mean for example if a bug exist in glide64 fast but in glide64 accurate not , it could be useful for find out that issues for fixed or it must to be of the same plugin type?

if previous question is afirmative, could be useful information between 2 differents plugins? for example, an issue that apears in rice but it doesnt stay in glide64.


These answers are good to know for me, because I found bugs on glide64 fast that not apears on glide64 accurate and I dont know if it is possible resolve that issues or maybe I need compare only with same type of plugin.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 03:16:27 AM
CONKER´S BAD FUR DAY

New bugs: missing  shadows

First versions with regression:Alpha 12 (alpha 13 has a different shadow issue, it is deformed)

Last versions working:alpha 10, alpha 11

Plugin used: glide64 (accurate, fast)

Game version: Conker´s Bad Fur Day (E) [!]

FIXED ON ALPHA 14
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 06, 2015, 06:55:17 AM
I can't speak for all the devs, but from my perspective, the priority would be:

Priority 1: Regressions between Alpha Test versions (for example, something broke going from Alpha 11 to Alpha 12)

Priority 2: Regressions between the Alpha Tests and the latest published version of the app (i.e. all Alpha tests, starting from Alpha 1, have a new problem that was not in 2.4.4)

The above two cases should be reported on this thread, providing as much detail as possible (as littleguy outlined), so that we can quickly and reliably reproduce the problem for easier disection.


To avoid confusion, the below cases should be reported on a new thread in Android Support, not on this thread.

Priority 3: Regressions between 2.x versions (for example, something broke going from 2.3.5 to 2.4.0)

Priority 4: Issues that were fixed on some build that is not in the general ancestry of the published releases or the 3.0 Alpha tests (for example, an experimental build that had a side-effect of fixing a problem that exists in both the 2.x and 3.0 alpha tests).  Provide as much information as possible.

Priority 5: A general problem that has always affected the app (i.e. not a regression)

This is just a general rule of thumb, though.  Actual order of priority will really depends on the specific issues themselves, with a lot of factors coming into play (seriousness, complexity, reproducibility, and so on).

Agree 100%

I mean for example if a bug exist in glide64 fast but in glide64 accurate not , it could be useful for find out that issues for fixed or it must to be of the same plugin type?

Yes, it is very useful for devs to know if the bug exists in a single version between two emulation profiles that use the same video plugin (e.g. "glide64 fast" and "glide64 accurate").

if previous question is afirmative, could be useful information between 2 differents plugins? for example, an issue that apears in rice but it doesnt stay in glide64.

That is usually not very important to devs.  There are significant compatibility and performance differences between the three video plugins, and they are usually well known after several years of user reports.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 06, 2015, 06:55:53 AM
Just gonna link this one image here as an example since embedding went so bad for me.
LOL! Dolby's "Double D" symbol. ;D

http://www.2shared.com/photo/i7bgjdMX/banjo_tooie-001.html

For reference, embed images like so:

[img width=200]http://url.to.image.png[/img]

This will require a direct URL to the image file (in your above link you have only an html URL, so it wouldn't work)

If you have a direct link to a thumbnail, you can wrap that inside a URL tag:

[url=http://url.to.image.host.html][img width=200]http://url.to.thumbnail.png[/img][/url]
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 07:10:38 AM
@Paul @littleguy perfect  ;)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 06, 2015, 07:29:25 AM
Testers - Thanks very much for all the detailed reports in the last few days, these are *extremely* helpful to tracking down bugs and issues :D.  These are exactly the kinds of contributions that the project so desperately needs.

I spent a lot of time last night thinking about the regressions I created in Alpha 12 and Alpha 13.  I intentionally broke the code, with the plan to systematically fix each break the "right" way (or so I think).  But with vacation over and my real job picking back up, I am starting to think it might be best for the project if I revert the breaking changes I made in those two versions.  Then we can take a more incremental approach to the issues, and the other devs aren't left "holding the bag" if I have to go on hiatus for days or weeks at a time.

@Devs - Unless there are major objections, I will revert my breaking changes (i.e. reinstate glState.cpp) and push out Alpha 14 tonight, which should be an incremental improvement (without regressions) over Alpha 11.

@Testers - Feel free to ignore Alpha 12 and Alpha 13 until the dust settles.  I would like to emphasize that the reports already made on these versions are most certainly not in vain, as they have already provided useful insights to the devs and will continue to do so.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 06, 2015, 07:42:40 AM
Hey guys.  The builds are getting better and better, but I am still having the same two player problems with Goldeneye.

Wow, there are actually several bugs I can see from your screenshots, that is really useful.  Remind me again, does the Raphnet adapter connect multiple N64 controllers to one USB port?  If so, then you will need to check the box in Global settings -> Input -> Share controller.  Apologies for the confusing wording, we may need to rethink that.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 06, 2015, 07:54:12 AM
@Devs - Unless there are major objections, I will revert my breaking changes (i.e. reinstate glState.cpp) and push out Alpha 14 tonight, which should be an incremental improvement (without regressions) over Alpha 11.

Sounds like a good plan.  It was definitely a good exercise to see what some of the various problems are left to address to clean things up.  We appreciate the work you put into this!

Things are a tad busy at work for me as well (holidays got us a bit behind schedule for an upcoming software release), but things should settle down here soon so I won't have to put in as much overtime.  I am slowly making progress on the gallery (initial commit shouldn't be too much longer).
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 06, 2015, 09:10:43 AM
git revert + auto-build system = Alpha 14 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501060902_6c2cc67.apk)

Alpha 14 should be compared to Alpha 11 and earlier (do not compare to 12 or 13).  See OP for downloads.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 06, 2015, 10:21:31 AM
git revert + auto-build system = Alpha 14 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501060902_6c2cc67.apk)

Pretty cool to have my computer at home building and uploading APKs while I am at work  ;D
Title: Re: 3.0 Alpha Testing
Post by: Sowden on January 06, 2015, 11:25:38 AM
Wow, there are actually several bugs I can see from your screenshots, that is really useful.  Remind me again, does the Raphnet adapter connect multiple N64 controllers to one USB port?  If so, then you will need to check the box in Global settings -> Input -> Share controller.  Apologies for the confusing wording, we may need to rethink that.

Really?  Well, glad I posted that then.  No the Raphnet is only one controller, its the Mayflash that has two controllers.  I use the Raphnet mostly because the Mayflash is faulty.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 06, 2015, 11:44:23 AM
Same Conker version with a different buffer issue in Alpha 14.

Also happens on Alpha 11,which makes sense.

Looking at Birdy The Scarecrow on Hungover causes a buffer on the bottom left of the screen with a black untextured scarecrow head.

Edit:So much easier for me to just link the screenshot from 2shared I love 2shared.  :)

http://www.2shared.com/photo/4gCVzuGf/conker_bfd-000.html

Edit:Oh yeah,thanks again anyway Paul!  8)

Edit2:It happens in every Alpha from the looks of it.
Alphas 4,7,10,11,and 14 while disregarding the 12 and 13 builds.

Does Alpha 14 still have the vanilla Core and Audio changes from the two previous versions?

Also,another minor issue is the shadow of the (to be sliced) N64 logo is appearing in the intro from below the floor where it is stored for quick placement at the right moment.
I know this because I have messed around with the intro data before and found out there is two models being used.
So this looks like a shadow layering issue,just wanted to point it out for ya.

Both also happen on 2.4.4 as well,so they are older bugs.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 12:33:29 PM
that black shadow of bottom left is too on 2.4.4 version.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 12:44:34 PM
SUPER MARIO 64

New bugs:  weird texture of the door (just when it gets closed) (bug1) grey background when mario goes though the door (less than 2s each one)

First versions with regression:alphas

Last versions working:2.4.4

Plugin used: rice

Game version:  Super Mario 64 (E)(M3)[!]

Screenshots and savefiles:

Official 2.4.4:
(http://img15.hostingpics.net/thumbs/mini_848212Screenshot20150106191612.png) (http://www.hostingpics.net/viewer.php?id=848212Screenshot20150106191612.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUay1aUlJNNHpESW8&authuser=0
https://www.dropbox.com/s/avlpnfamluxpsmp/sm64rice244?dl=0
Alphas:
(http://img15.hostingpics.net/thumbs/mini_714882Screenshot20150106191732.png) (http://www.hostingpics.net/viewer.php?id=714882Screenshot20150106191732.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUMXZZVWhwU3FuZkk&authuser=0
https://www.dropbox.com/s/xweczcao9f80861/sm64rice14?dl=0


Screenshots and savefiles (bug 2):

Official 2.4.4:
(http://img15.hostingpics.net/thumbs/mini_828753Screenshot20150106191950.png) (http://www.hostingpics.net/viewer.php?id=828753Screenshot20150106191950.png)
-

Alphas:
(http://img15.hostingpics.net/thumbs/mini_761626Screenshot20150106191945.png) (http://www.hostingpics.net/viewer.php?id=761626Screenshot20150106191945.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUZG1SQ1cxc3luNEE&authuser=0
https://www.dropbox.com/s/gww9n0u0q70sev2/sm64transitionrice14?dl=0
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 12:50:28 PM
1080 snowboarding

New bugs:  main menu

First versions with regression:alphas

Last versions working:2.4.4

Plugin used: rice

Game version:  1080 Snowboarding (E)(M4)[!]

Screenshots and savefiles:

Official 2.4.4:
(http://img15.hostingpics.net/thumbs/mini_885833Screenshot20150106192613.png) (http://www.hostingpics.net/viewer.php?id=885833Screenshot20150106192613.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUYU5tNjdZUnVsZDA&authuser=0
https://www.dropbox.com/s/mvkf4julztcduj5/1080rice244?dl=0

Alphas:
(http://img15.hostingpics.net/thumbs/mini_410268Screenshot20150106192457.png) (http://www.hostingpics.net/viewer.php?id=410268Screenshot20150106192457.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUV21SaXJXdV9oeEE&authuser=0
https://www.dropbox.com/s/knk58srdh8wt0f5/1080rice14?dl=0
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 12:51:10 PM
MARIO PARTY

New bugs:  faulty top and bottom borders

First versions with regression:alphas

Last versions working:2.4.4

Plugin used: rice

Game version: Mario Party (E)(M3)[!]

Screenshots and savefiles:

Official 2.4.4:
(http://img15.hostingpics.net/thumbs/mini_471173Screenshot20150106185539.png) (http://www.hostingpics.net/viewer.php?id=471173Screenshot20150106185539.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUWGQtSzJmM1o4ZTg&authuser=0
https://www.dropbox.com/s/ej71nvmp65whrqj/mp1rice244?dl=0
Alphas:
(http://img15.hostingpics.net/thumbs/mini_680423Screenshot20150106185352.png) (http://www.hostingpics.net/viewer.php?id=680423Screenshot20150106185352.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUcFlYM2dHa3pfOFU&authuser=0
https://www.dropbox.com/s/seywz2n9mljjgsd/mp1rice14?dl=0
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 12:52:18 PM
MARIO TENNIS 64

New bugs: 

First versions with regression:alphas

Last versions working:2.4.4

Plugin used: rice

Game version:  Mario Party (E)[!]

Screenshots and savefiles:

Official 2.4.4:
(http://img15.hostingpics.net/thumbs/mini_944593Screenshot20150106190145.png) (http://www.hostingpics.net/viewer.php?id=944593Screenshot20150106190145.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUTXVRZVM1OE1EeU0&authuser=0
https://www.dropbox.com/s/n5kucde6xj3n99s/mtennisrice244?dl=0
Alphas:
(http://img15.hostingpics.net/thumbs/mini_666617Screenshot20150106190303.png) (http://www.hostingpics.net/viewer.php?id=666617Screenshot20150106190303.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUakZES2lXclNiSkE&authuser=0
https://www.dropbox.com/s/8mmmoztlte5rjz2/mtennisrice14?dl=0
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 06, 2015, 12:53:37 PM
LEGEND OF ZELDA: OCARINA OF TIME

New bugs:  borders top and bottom when link goes through a tunnel or open a trunk (żits name is this?)

First versions with regression:alphas

Last versions working:2.4.4

Plugin used: rice

Game version: The Legend of Zelda, Ocarina of Time(E)(M3)(V.1.0)[!]

Screenshots and savefiles (bug 1):

Official 2.4.4:
(http://img15.hostingpics.net/thumbs/mini_956097Screenshot20150106184729.png) (http://www.hostingpics.net/viewer.php?id=956097Screenshot20150106184729.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUcjdCNGJvRW9LeDg&authuser=0
https://www.dropbox.com/s/pxzb4qapwjukdo2/ocariceok244?dl=0
Alphas:
(http://img15.hostingpics.net/thumbs/mini_863693Screenshot20150106184924.png) (http://www.hostingpics.net/viewer.php?id=863693Screenshot20150106184924.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUUkd0TjJtaVRabW8&authuser=0
https://www.dropbox.com/s/ejqb1golooasys2/ocaricefast14?dl=0


Screenshots and savefiles (bug 2):

Official 2.4.4:
(http://img15.hostingpics.net/thumbs/mini_145535Screenshot20150106185208.png) (http://www.hostingpics.net/viewer.php?id=145535Screenshot20150106185208.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUbG5XOUVxMGRoVUk&authuser=0
https://www.dropbox.com/s/be22wi9oy5udovx/oca2rice244?dl=0
Alphas:
(http://img15.hostingpics.net/thumbs/mini_583168Screenshot20150106185020.png) (http://www.hostingpics.net/viewer.php?id=583168Screenshot20150106185020.png)
https://drive.google.com/open?id=0B9JF6P2xH4TUT3RwU1VBa1dMSU0&authuser=0
https://www.dropbox.com/s/be22wi9oy5udovx/oca2rice244?dl=0

zoom on targeting happen the same that both bugs.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 06, 2015, 01:14:50 PM
So much easier for me to just link the screenshot from 2shared I love 2shared.  :)

No problem :)

Does Alpha 14 still have the vanilla Core and Audio changes from the two previous versions?

Yes, Alpha 14 has vanilla upstream
 - audio
 - core
 - rsp-hle
 - ui-console (for all intents and purposes; it just has a few extra lines of glue code).
 - video-rice

video-glide64mk2 is better than vanilla -- I will be pushing the downstream fixes upstream this week.

Note that the famous "Gilles build" has a few extra dynarec fixes that aren't upstream yet, and hence aren't in Alpha 14 yet.  His progress is described here: https://github.com/Gillou68310/mupen64plus-ae/issues/1#issuecomment-68690556.  So more improvements will be coming but are outside my control.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 07, 2015, 10:52:36 PM
WOW! Not a single post from anybody for so long. :(

Would one of those dynarec related things be the speed increase from his build over the 2.4.4 version?
Obviously,the Banjo-Tooie crash and DK64 collision fixes are already added to the Alpha builds since I never get crashing or pass through walls.
And yes,I know you mean the other crash fix for specific devices while FireTV runs it fine already.

Super Smash Bros. performance (four DK match in Hyrule) on the Alphas right now is pretty slow by comparison while it is slower on 2.4.4 because the lack of "fb_read_always" being listed in the 2.4.4 configuration file for disabling.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 08, 2015, 11:45:26 AM
Yes, Its so quiet here.

Tested the last auto-build:

glide64 fast
Pokemon stadium: the left side issue in the intro affects until 70% of the screen (more or less 30% previously)

rice
Pokemon stadium 2: currently, instead 3 images of each pokemon in the intro, is only 1, but the background is grey (faulty) and it would must be black.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 08, 2015, 12:02:20 PM
WOW! Not a single post from anybody for so long. :(

Yes, Its so quiet here.

Because the holidays are over and most devs and testers have gone back to their real jobs.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 08, 2015, 12:02:36 PM
One of the upstream developers just announced that some major reorganization of the Rice plugin is coming soon:
https://groups.google.com/forum/#!topic/mupen64plus/UOpNb4UVOcg

Don't get excited.  This is a major "housecleaning" effort, rather than fixes or performance improvements.  Inevitably there will be some regressions when the dust settles.

Bottom line:
 - Don't bother testing Rice for now.  We'll tell you when the housecleaning is finished and when to start testing Rice.
 - Focus your testing on Glide and the user interface for now.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 08, 2015, 08:41:33 PM
It's recently come to my attention that having fb always read set to 0 also disables some in-game osd counters in various games, probably already known, but at least I know the source of previous issue here
www.paulscode.com/forum/index.php?topic=96.msg12311#msg12311
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 08, 2015, 09:02:26 PM
Would help better if you'd mention one.
Since there is game specific configuration files now,you can enable it for each game that needs it.

DK64 doesn't "NEED" it to run fine,it will only be missing the pause background image and nothing else of importance.
Conker's Bad Fur Day,Banjo-Kazooie,Banjo-Tooie,and Super Smash Bros. don't need it at all.

What games DO need it enabled specifically for really important things like OSD?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 08, 2015, 09:05:40 PM
@Mikhail - Before the recent changes, were you manually setting fb_read_always to 1?
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 08, 2015, 09:19:00 PM
Is their a verbosity setting for glide so I can double check?
 I've noticed when starting games it doesn't always show the on/off comment.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 08, 2015, 09:23:31 PM
Is their a verbosity setting for glide so I can double check?

Do you mean logcat verbosity?  Not without rebuilding.  Also, verbose logging in glide brings framerate below 1FPS.  (I just happen to be creating a pull request for that as we speak.)

I've noticed when starting games it doesn't always show the on/off comment.

Could you please clarify?  I do not understand what you are trying to say.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 08, 2015, 09:28:20 PM
The one that comes up as

FB Read Always: , Motion Blur: , Filtering Mode:
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 08, 2015, 09:43:44 PM
Ah, thanks.

Unless you were modifying fb_read_always by *manually editing* mupen64plus.cfg before, nothing is different in the latest versions.  The latest versions do not allow you to manually edit that field any more (it's always zero - disabled).  Previously, the default value was -1, which meant that glide64mk2.ini could override the value on a per-game basis, though in practice no games were overriding it.  So the end result is the same unless you had been modifying either of those files by hand.

There have been a lot of changes upstream, but fb_read_always is not a likely culprit in this case.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 10, 2015, 11:05:55 AM
Here is Alpha 15 (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501101002_c7fb2b3.apk)

It is identical to Alpha 14, except that it fixes a bug in the auto-detection of V64- and Z64-formatted ROMs.  You may need to use a file manager to move your game data to the newly-generated folder in mupen64plusae-v3-alpha.  Sorry for the inconvenience, but this is exactly why we are rolling out Alpha versions first.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 10, 2015, 01:03:13 PM
Looked into the nvidia shield tablet's flicker reduction profile. Ocarina of Time should be between -2.825 and -2.85, while Super Mario Star Road needs -0.95
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 10, 2015, 01:06:17 PM
It is crazy that it's that sensitive.  It would be the only device that requires that much precision, and different values for different games.  I wonder if using the upstream's default polygon offset settings would work better (i.e. remove the Android hack).  I'll try to make a test build when I get the chance.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 10, 2015, 01:11:10 PM
My Nexus 7 (2013) had similar issues. Mario Star Road is the hyper sensitive one, and I never tested OOT like this on the N7.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 10, 2015, 01:56:41 PM
Found another issue with the cover art interface.

Mediaserver is using 60% of my battery and I have no other pictures or media stored on my device.
The .png images used for cover art may be causing it somehow,so I hope you can make cover art optional or utilize the .nomedia trick by making the emulator bypass the .nomedia file when placed in the directory so the server/scanner can avoid reading that folder.
Sure,it looks nice,but it is not worth your battery life being drained away.

You can still use the .nomedia trick anyway so that it can prevent this from happenning at all.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 10, 2015, 02:02:08 PM
I'll add the .nomedia thing in the next version.  Thanks for the reminder.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 10, 2015, 03:45:03 PM
Ah, thanks.

Unless you were modifying fb_read_always by *manually editing* mupen64plus.cfg before, nothing is different in the latest versions.  The latest versions do not allow you to manually edit that field any more (it's always zero - disabled).  Previously, the default value was -1, which meant that glide64mk2.ini could override the value on a per-game basis, though in practice no games were overriding it.  So the end result is the same unless you had been modifying either of those files by hand.

There have been a lot of changes upstream, but fb_read_always is not a likely culprit in this case.

The comment isn't coming up at all with F1 Grand Prix II, it is with RE2 though,
 I can't be certain it isn't showing the mesage though, it's still rendering bs outside the game window probably related the Adreno rotation glitch www.paulscode.com/forum/index.php?topic=1227.msg11325#msg11325

Editing the fb_always_read Glide64mk2.ini in org.mupen64plusae.v3.alpha still works whilst the per game coreconfigs have no effect.

The gln force screen clear has no effect at all now and the setting in gln64.conf always resets back to 0, even though the
emulation.cfg are true and the gln entries are now gone from mupen64plus.cfg
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 10, 2015, 05:59:40 PM
fb_read_always is always disabled in the latest alphas.  Unless you hand modified the files in 2.4.4, it was always disabled there as well.

Changing Glide64mk2.ini will not have any effect on the latest alphas.  Any changes you make to fb_read_always in GameData/<romname>/CoreConfig/mupen64plus.cfg will be overwritten on relaunch.

Gln64 config settings are specified in their own config file, never in mupen64plus.cfg.  That's the same as it was in 2.4.4.  It's possible however that the gln64 file is not being read properly in the latest alphas, which could be the cause of your gln64 issues.  I'll take a look.  Thanks :)
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 10, 2015, 06:37:27 PM
If where using per game settings and general global profiles wouldn't it make sense to have the per game settings as a seperate profile called user?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 10, 2015, 07:49:37 PM
Sorry, I do not understand your question.  Let me know if the following explanation clarifies or confuses.

In the Android UI, some settings are global, some settings are game-specific.  There is currently no overlap -- a setting exposed through the Android UI is either global or game-specific.  There are a number of additional settings -- let's call them "expert" settings -- which can only be changed by manually editing the core config files.  99% of all users won't touch these, but they are there for devs, testers, and anyone who knows what they're doing.  Expert settings are specified on a game-by-game basis since there is a different mupen64plus.cfg for each rom, saved in GameData/<romdir>/CoreConfig/.  There should also be glide and gln64 config files in that directory as well, but I think that might not be working correctly yet (I need to check).  Global and game-specific settings cannot be overridden by manually editing the config files -- the Android UI will simply overwrite your changes at next launch, using the values you specified in the Android UI.

Right now fb_read_always is hard-coded to 0 for all games and cannot be overridden.  It would probably make sense to expose this in the emulation profiles so that someone can control it if they really want to.  But I think it should be 0 for all the built-in emulation profiles that will ship with the app, since enabling fb_read_always has a severe performance penalty.

By the way, I'm open to suggestions if people think a particular setting should be made game-specific rather than global (and vice versa).  Some testers had mentioned a preference for some of the global display settings being moved into the game-specific area.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 10, 2015, 08:56:57 PM
Too many files housing too many settings imo,

emulation.cfg - Not needed since where only getting to select video, frameskip, R3400, cant these profiles be hard coded?

If where having game specific settings for each video plugin do we really need the .ini, .conf junk in org.mupen64plusae.v3.alpha?
for games that require specific fixes already can't these settings be automatically placed into rom CoreConfigs on the first game run once it identifys the z64 rom md5 + title / region header, then if a user should want to test something they can override a previous fix by editing the rom CoreConfig instead of trawling through the lengthy files which contain fixes for all games, it can be quite tiresome editing a setting for a single game.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 10, 2015, 09:09:12 PM
Mario Star Road with -2.85
http://i.imgur.com/6pi3BrL.jpg

OOT with -0.95
http://i.imgur.com/WqFgvwt.jpg
http://i.imgur.com/CTooDqO.jpg

Edit: Finally tested mario star road on PC mupen, and it does have the same issue (thought it didn't).
I think the correct offset is actually between -2.825 and -3.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 10, 2015, 10:55:05 PM
Too many files housing too many settings imo,

emulation.cfg - Not needed since where only getting to select video, frameskip, R3400, cant these profiles be hard coded?

If where having game specific settings for each video plugin do we really need the .ini, .conf junk in org.mupen64plusae.v3.alpha?
for games that require specific fixes already can't these settings be automatically placed into rom CoreConfigs on the first game run once it identifys the z64 rom md5 + title / region header, then if a user should want to test something they can override a previous fix by editing the rom CoreConfig instead of trawling through the lengthy files which contain fixes for all games, it can be quite tiresome editing a setting for a single game.

Patience young grasshopper.  There is method to the madness.

99% of users will not and should not touch any config files.  The new architecture will make it easier for game-specific profiles to be created.  There's still a lot of work to be done.  More stuff is likely to move into the emulation profiles to encapsulate game-specific needs.  So if a particular game needs some hack applied AND IF that hack isn't already applied automatically by core (most already are), THEN there will EVENTUALLY be an emulation profile for that game and it will be the default for that game.  Version 3 has been architected to allow for that.  We are focusing on the 99% use case (plug and play, minimal settings), but still allowing the 1% to do special stuff if they know what they're doing.

.ini and .conf "junk" is all part of the upstream codebase.  We work with it, not against it.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 11, 2015, 10:06:43 AM
I added the .nomedia thing and it will be in the next alpha.  This keeps the cover art and touchscreen skins out of the Android Photo Gallery.  If you can't wait, here (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501111002_b6c0f2d.apk) is the auto-build.  I had to reboot the phone for the gallery to refresh.  Note that you might still have some stale images from older builds laying around, so you might have to delete those manually (or copy the .nomedia file to the stale directories).
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 11, 2015, 01:40:44 PM
Thanks,I hope it fixes my Mediaserver problem,and it is not some other resource/condition causing it.
Just recently beat Quest 64 in the Alpha build on FireTV without cheats (excluding a cheap grinding exploit and a few savestate reloads) so you can add that one to the completable list with Donkey Kong 64,though I didn't max out Brian's elements to 50.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 11, 2015, 02:23:21 PM
@xperia64 - Probably a long shot but I added an option to disable the polygon offset hack (first entry in Flicker Reduction preference) in case you wanted to try that on your shield tablet.  See the latest on the auto-builds page.  If that doesn't help anything, just let me know which polygon offset you want me to use.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 11, 2015, 02:39:53 PM
Disabled behaves like a custom offset of 0. The water in the moat is at the correct level with the flicker reduction disabled or set between -0.95 and 0, but the shadows still flicker. Might just be that glide is incompatible with Mario star road, which is unfortunate because the other plugins have some issues as well.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 11, 2015, 03:13:24 PM
...and Glide64 is ironically the fastest with fb_read_always disabled.
Rice is slower with SM64,and so is glN64.

It will be a while before I check my tablet testing for the .nomedia change.
Title: Re: 3.0 Alpha Testing
Post by: Sowden on January 12, 2015, 12:31:18 PM
 :D  The Goldeneye two players selection has been fixed.  I can now play against my friends!  Thanks for making the fix, the emulator is running great.  And sorry if this has been mentioned, but the climb up Death Mountain in OOT doesn't glitch anymore.  I haven't tried any of the other builds, but the ground was all glitching out in the latest version from google play.  Thanks guys, later.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 12, 2015, 01:50:15 PM
I forgot to mention that Quest 64 also has the floor shaking issue in a few instances.
How can this Glide64 plugin issue be fixed?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 12, 2015, 01:59:24 PM
Gilles made a possible fix for that here but hasn't submitted a pull request for it yet.
https://github.com/littleguy77/mupen64plus-ae/commit/078675adef88a5930d3eac256467e2ecaa8c2922
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 12, 2015, 04:58:43 PM
@retroben I suppose the issue you are saying it is on 2.4.4 too. If it is the issue I am thinking, it appears in other games like mario 64, and zelda ocarina.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 12, 2015, 08:51:30 PM
@xperia64 I have experienced a few of those crashes on exiting the game now.  I don't have a way to reproduce them consistently (only about 1 in 10 crashes for me) but it's a start.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 12, 2015, 09:29:13 PM
Mine are extremely consistent. The following always happens:
Load game->Exit game->Crash to GalleryActivity->repeat. Occasionally instead of crashing to GalleryActivity the app just exits.

Also the alphas don't have all the BanjoTooie dynarec fixes, do they?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 12, 2015, 10:03:08 PM
No, Gilles is still sorting some of his fixes out before he pushes them upstream.
https://github.com/Gillou68310/mupen64plus-ae/issues/1#issuecomment-68690556
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 13, 2015, 12:25:00 PM
@xperia64 - Are you able to build the Android project?  If so, then build it and run on your device until you get the crash.  Then go to a command prompt, cd to the mupen64plus-ae/tools directory, and run ./ndk-stack.sh.  Post the crashdump text file here.  Might give us some more insights into the crash.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 13, 2015, 12:32:58 PM
I'll do it tonight. Checking the logs, it's crashing in libEGL  :o
eglReleaseThread and some pthread stuff are the only relevant looking areas just from glancing the logs.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 13, 2015, 02:44:18 PM
Now are fixed the issues in the intro of Pokemon Stadium 1 with glide64 fast  ;D
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 13, 2015, 04:54:28 PM
Next alpha will support arbitrary filenames.  Check out the auto-build (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501131401_9eb5796.apk) if you can't wait.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 13, 2015, 06:21:52 PM
Finally built the latest alpha myself.
I fixed a crash with CheatUtils.java when coming from a clean install. Line 88 should be:
Code: [Select]
cheat_v.add( cheat_section_v = new CheatSection( crc, name, country ) );as opposed to
Code: [Select]
cheat_v.add( new CheatSection( crc, name, country ) );(alternatively cheat_section_v could be defined on the previous line and added)
 
I'm currently recompiling the NDK stuff in debug mode as the output from ndk-stack in release mode is worthless with the game exit crash I have.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 13, 2015, 07:19:59 PM
Awesome, thanks for the fix.  I pushed it up to github.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 13, 2015, 07:44:56 PM
Right. I found how to prevent the exit crash: disable the video plugin.
But yeah, it is crashing at eglReleaseThread: http://pastebin.com/jQrSFqhP
The only relevant thing I've found with a similar crash is when using GLES2 on an android emulator.

Happens with all video plugins in all versions of alpha (Alpha 3 to current).
Still seems like a race condition given that it occurs between ae-bridge's unloading native libraries and GameLifecycleHandler's onStop.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 13, 2015, 08:56:02 PM
Awesome.  There are already some other pthread issues -- I get warnings about thread destructor not being called.  Hopefully one fix will take care of the warnings and your crashes.  I will pull up one of Gilles threading modifications and see if that changes anything.  A lot of things are pointing at ae-bridge.

https://github.com/littleguy77/mupen64plus-ae/commits/Gillou68310/sdl-bridge-front-mods
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 13, 2015, 08:58:26 PM
AE bridge is where I went looking some months ago for the cause of this crash
(that one commit with the 20 "Unloading Native Libraries" logs etc :P)
I agree that something weird is going on there.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 13, 2015, 09:04:41 PM
What I fear the most is some flaw or misunderstanding of SDL.  I really don't want to touch that source code.  I really don't.  The Android parts of that code look like sausage to me.  The latest version 2.0.3 makes all sorts of breaking changes in the Android interface compared to 2.0.0 (which we use).  It gets its tentacles deep into the Android lifecycle.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 14, 2015, 09:13:49 PM
Next alpha will support:
 - zipped ROMS
 - cover art located in a sub-folder, which you can manually delete if you want to save space
 - arbitrary ROM filenames (e.g. ending in .rom or .foo or .whatever)
 - virtually eliminate false detections of ROMS
 - GalleryData folder renamed GalleryCache, so it's obvious you can safely delete its contents.

Auto-build (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501142101_eb4ec99.apk) if you can't wait.

Edit: Still need to add a "searching" popup with spinners so that you can cancel the ROM search/extract process.  For now just let it run, even if it doesn't look like it's doing anything.  It will eventually finish (or you can just exit the app).
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 14, 2015, 10:03:46 PM
I put a zipped ROM in my ROM folder and it didn't show up. Pilotwings 64 (USA).zip containing Pilotwings 64 (USA).n64
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 14, 2015, 10:09:51 PM
I'm determining zip file by checking the first four bytes of the file to see if they match a signature.  I would greatly appreciate it if someone identified a more reliable way of determining zip file.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 15, 2015, 12:38:30 AM
I think my problem is that the mediaserver is serving the images even when the app is not in focus,causing unreasonable battery drain if you don't manually force stop the app.

Please add an option to disable cover art primarily for the sake of battery life for my tablet and all other peoples tablets/phones. :(
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 15, 2015, 02:47:59 AM
I have noted an amazing improve of the performance of several games (mario 64, banjo tooie and zelda ocarina) in the last build. 
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 15, 2015, 06:51:37 AM
I put a zipped ROM in my ROM folder and it didn't show up. Pilotwings 64 (USA).zip containing Pilotwings 64 (USA).n64

Can you check what the first four bytes of the zip file are?  That might indicate whether the problem was that the zip file is not recognized as such, or if it is the ROM inside that is not recognized.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 06:55:02 AM
Good point.  Also, the logcat will produce a message whenever
 (a) a zip file is found
 (b) an entry in the zip file is a ROM

This is the sort of info I will be adding to the search popup.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 07:42:38 AM
I think my problem is that the mediaserver is serving the images even when the app is not in focus,causing unreasonable battery drain if you don't manually force stop the app.

Does the cover art still show up in your photo gallery with the latest auto-builds?  You might need to clear the mediaserver app data from the Android settings and/or reboot.  If you still see cover art in the photo gallery, check to be sure you don't have copies of the cover art in a stale folder somewhere.  Click on the image in the photo gallery then hit the menu to see its properties and check its file path.  Nothing in mupen64plusae-v3-alpha should be visible to mediaserver any longer.

If you're still having problems, try this link: http://geeknizer.com/fix-android-media-server-scanner-sdcard-cpu-battery-drain/

If you still having problems after that, uninstall all mupen apps just to be sure the issue is truly caused by mupen.  Perhaps another app you recently installed is creating the issue.

Please add an option to disable cover art primarily for the sake of battery life for my tablet and all other peoples tablets/phones. :(
Next alpha will support:
 - cover art located in a sub-folder, which you can manually delete if you want to save space

Is this not a good enough solution for you?
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 15, 2015, 01:03:07 PM
The mediaserver did not appear until I started using the Alpha build with the cover art.
There was no sign of mediaserver on the battery in either the 2.4.4 stable build or the one made by Gillou,which I used both of before installing the Alpha.

I rarely use the tablet all that much so I hardly run anything else,and yet I lose 4% or 5% battery in a matter of moments.
I spent a large chunk of time turning off every single location and sync setting and disabling a lot of bulky apps i'd never use.

I think it would be simpler to make the customizations for the choice to not use cover art and instead mimic the N64oid style game list.

>:( ...The other MAJOR annoyance I just realized is the fact I can't just browse and select anything anymore because newly placed game roms will not be in the list,so I have to wait for the refreshing to finish (FireTV's crappy read speed) in order to select that newly placed game.
It could get even worse when you have one in another folder that you have to refresh for in order to get it listed,only to have the other ones disappear from the list as a result of being in another folder.
This new "refresh" method is very flawed in the way that it limits your control and can hinder proper file access.
It is one step away from being as difficult as MAME which limits you to exact fileset perfection.

I am sorry about my rant of this,I truly am. :(
You could still make cover art optional and change the refresh button to a detection button so it can still use cover art while being in full listing mode,which can always have a filetype filter with only n64,v64,z64,zip,N64,V64,Z64,and ZIP as the displayed filetypes for quickly accessing them in folders with tons of other files.

I also just thought of an interesting idea of adding a favorites lister for placing favorite games in a quick access page.

Again,I apologize for my cruel harshness. :(
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 01:22:09 PM
Thanks, I can understand the frustration, that makes sense.  Thanks for keeping a lid on inflammatory words.

Just to be clear, 90% of the time taken during the refresh is the calculation of the MD5 sum, which is used to uniquely identify the ROM and obtain the correct meta info.  Scanning the disk and downloading the cover art is only a small fraction of the time.  Just want to mention it in case anyone thinks scanning and downloading are consuming all the time.

The scan and cache has both features and flaws.  If you don't precompute the MD5 sum, then you have to do it on-demand.  If you don't change your set of ROMs too often, this adds up to a lot of time savings.  This was the idea proposed in the 3.0 Brainstorming thread in Developer's Corner of the forum.  I have not made the decision unilaterally.  But now that we have a better appreciation for the flaws, it would be good to revisit the design choices.

With that in mind, I'd like to open this topic up to discussion again.  Everyone, please weigh in.  I will try my best to only listen and not shoot down ideas prematurely.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 01:24:14 PM
@retroben - Regarding battery life, have you deleted all the cover art from your disk?  The app will still run fine if the cover art images are missing.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 15, 2015, 01:51:01 PM
I have recently done so and have also just found and installed Mediaserver Killer (root),by rori of XDA Forums.
Now I should hopefully get the longer battery life my device deserves.

It even has a nifty ignore list so things like music apps will not be messed with,as it won't be killed when an ignored app is used.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 02:22:52 PM
Also keep in mind that all of the alphas so far are just using a dummy gallery screen.  Paul is working on the real one, which from the sounds of it is much more careful about memory and stuff.  It will share little (if any) code with the current dummy code.  If mediaserver interacts with the running app, that would be good for Paul to beware of.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 15, 2015, 02:30:53 PM
The zip file I tried earlier has 504b0304
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 02:34:26 PM
It should have found it then.  Must have had an issue with the entry in the zip file.  I'll try to release Alpha16 tonight, which will have a much more informative UI about the scan/extract process.

Edit: You can also check the logcat directly from the Gallery.  See About -> Logcat.  That should tell you where the search is failing (including any exception messages).
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 03:48:46 PM
>:( ...The other MAJOR annoyance I just realized is the fact I can't just browse and select anything anymore because newly placed game roms will not be in the list,so I have to wait for the refreshing to finish (FireTV's crappy read speed) in order to select that newly placed game. It could get even worse when you have one in another folder that you have to refresh for in order to get it listed,only to have the other ones disappear from the list as a result of being in another folder.

...

You could still make cover art optional and change the refresh button to a detection button so it can still use cover art while being in full listing mode,which can always have a filetype filter with only n64,v64,z64,zip,N64,V64,Z64,and ZIP as the displayed filetypes for quickly accessing them in folders with tons of other files.

These are very good observations.  How about this idea: Replace the "Refresh ROMs" button with a drop-down menu, containing:
 - Auto-detect ROMs
 - Add ROM
 - Clear gallery

The first menu item works exactly as it does now, *except* that it doesn't remove tiles that already exist in the gallery.  This allows you to cherry-pick a few folders in different locations.  Just repeat for each unique folder.

The second menu item allows you to add a single ROM to your gallery.  After you select a single ROM, a new tile is added to the gallery (if the ROM isn't already there).  Next time you want to play that ROM, you can just click the tile.

The third menu item clears the GalleryCache directory, removing all cover art, unzipped roms, and list of known ROMs.

Edit: The first and second items could even be merged, so that you select either a single ROM or a directory from the same popup.

***

On another topic, in the auto-search I will add something to allow you to skip zips and cover art if you want to save a bit of space/time.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 15, 2015, 04:07:44 PM
It just says CacheRomInfoTask: Found zip file Pilotwings 64 (USA).zip
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 15, 2015, 04:13:31 PM
It would be nice if you change a image of the image folder, it doesnot be overwrited if you "refresh roms". I dont know if it is possible to do that... so I use to change perfect dark and ocarina of time images manually for the PAL images.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 04:27:08 PM
It just says CacheRomInfoTask: Found zip file Pilotwings 64 (USA).zip

If you didn't see any exception messages, that confirms it.  Whatever ROM is inside the zip isn't being detected.  I can add more logging in the next iteration.  I will also double check for bugs.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 15, 2015, 09:35:55 PM
Next alpha will have a better progress dialog when scanning for ROMs.  Autobuild here (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501152002_6db2611.apk) if you can't wait.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 16, 2015, 08:24:57 AM
Almost every rom dissapeared with new build when I did a new "refresh roms".  Only were found 7 or 8 roms. All of my roms have .n64 extension.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 16, 2015, 08:38:43 AM
Thanks.  Did the app crash or get put in the background during the scan?

Run the scan again.  When it's finished, go to Help -> Logcat... from the gallery screen, and post the text here (you can use the "Share" button in the popup to copy to clipboard).
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 16, 2015, 09:05:55 AM
I run the scan again after of change the Languaje to english (I had spanish) and it found all the roms... and then I re scan after of change to Spanish if that was the problem and it found all the roms again... I dont know how it happened but  at the first time I installed the new build I did like 3 or 4 scans and always found 7 or 8 (always the same roms).
Here if the logcat if you still want to see it: 

Code: [Select]
--------- beginning of /dev/log/system
[ 01-16 15:58:51.392 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:58:51.472 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:58:54.082 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:58:54.142 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:58:55.472 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:58:55.512 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:58:57.752 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:58:57.862 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:58:59.352 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:58:59.802 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:59:02.872 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:59:07.322 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:59:09.872 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:59:09.942 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

--------- beginning of /dev/log/main
[ 01-16 15:59:17.512 32345:32345 I/Xposed   ]
org.mupen64plusae.v3.alpha OFF

[ 01-16 15:59:17.642 32345:32345 I/ActivityManager ]
Timeline: Activity_idle id: android.os.BinderProxy@431f7588 time:79777663

[ 01-16 15:59:18.892 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:59:18.972 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:59:20.362 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:59:20.422 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

[ 01-16 15:59:22.912 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch Down

[ 01-16 15:59:22.992 32345:32345 I/ViewRootImpl ]
ViewRoot's Touch Event : Touch UP

Title: Re: 3.0 Alpha Testing
Post by: Sowden on January 16, 2015, 02:39:33 PM
Hey guys.  I just tried playing Mario Golf on the latest build (the one thats auto built) and I have noticed some huge problems from the last google play version.  I have uploaded photos from my list in order and they were all played on the "Fast"est.  They go as followed:

Glide64: Displays everything for the most part, but it is way laggy.  Its unplayable because I can't make an accurate club swing
http://troyh.us/FTPshare/pieproductions/Screenshot_2015-01-17-04-12-13.png
Gin64: Landscape graphics are all messed up, can't see where I'm hitting the ball at.  Will say though that this is the smoothest plugin out of them all, somewhat playable
http://troyh.us/FTPshare/pieproductions/Screenshot_2015-01-17-04-14-20.png
Rice: Landscapes are a little messed up, but I can make it out for the most part.  The screen is black until I slightly move my joy stick.  Not so much lag, most playable out of all of them
http://troyh.us/FTPshare/pieproductions/Screenshot_2015-01-17-04-17-59.png

I don't know if this has been mentioned, but this sticks out at me.  Thanks, later.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 16, 2015, 03:05:37 PM
Perfect dark and Pokemon Stadium 2 with last build are  very laggy now (glide64 fast).  But as I said few days ago, several games improved greatly their performance (conker, banjo tooie, donkey kong 64, pokemon stadium for example)
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on January 16, 2015, 04:23:44 PM
Hi All,

I noticed in the 3.0 version there is not an option to load a custom controller profile?  I created the InputProfiles folder and nothing is picked up there...

I saw there was a new Profile folder and created a .cfg but it's not being picked up by the program.  I'm using an amazon fire controller which requires the config.

Thanks

Edit: Just renamed my custom file to controller.cfg and it works now :D
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 16, 2015, 04:24:42 PM
@rafar Can you narrow down between which alpha versions or auto-builds the lagginess started and/or performance improved?  I haven't touched the core in awhile.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 16, 2015, 04:32:36 PM
Hi All,

I noticed in the 3.0 version there is not an option to load a custom controller profile?  I created the InputProfiles folder and nothing is picked up there...

I saw there was a new Profile folder and created a .cfg but it's not being picked up by the program.  I'm using an amazon fire controller which requires the config.

Thanks

The new version uses a somewhat different system for controller profiles.  Rather than using a unique file for each controller profile, all the controller profiles are placed in a single file, located at mupen64plusae-v3-alpha/Profiles/controller.cfg.  Normally you wouldn't need to manually edit it, but since that controller has unique issues, you can workaround them by editing the file:

Code: [Select]
[Amazon Fire Controller]
map=0:-31,1:-32,2:-33,3:-34,4:108,5:-47,6:99,7:96,8:-23,9:-24,10:-29,11:-30,12:103,13:102,16:-1,17:-2,18:-3,19:-4
sensitivity=100
deadzone=0

If you want to edit the mappings via the UI (e.g. for the Start button) go to Settings -> Controller profiles... in the main screen of the V3 app.  Then tap the name of the controller you wish to modify/copy/delete/etc.
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on January 16, 2015, 04:53:52 PM
Quote

The new version uses a somewhat different system for controller profiles.  Rather than using a unique file for each controller profile, all the controller profiles are placed in a single file, located at mupen64plusae-v3-alpha/Profiles/controller.cfg.  Normally you wouldn't need to manually edit it, but since that controller has unique issues, you can workaround them by editing the file:

Code: [Select]
[Amazon Fire Controller]
map=0:-31,1:-32,2:-33,3:-34,4:108,5:-47,6:99,7:96,8:-23,9:-24,10:-29,11:-30,12:103,13:102,16:-1,17:-2,18:-3,19:-4
sensitivity=100
deadzone=0

If you want to edit the mappings via the UI (e.g. for the Start button) go to Settings -> Controller profiles... in the main screen of the V3 app.  Then tap the name of the controller you wish to modify/copy/delete/etc.

Works perfectly. Thank you.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 16, 2015, 05:21:50 PM
@rafar Can you narrow down between which alpha versions or auto-builds the lagginess started and/or performance improved?  I haven't touched the core in awhile.

Sure, tomorrow I will edit this post with more details   ;D

Edit: it is probably I said be my fault, because I am having problem with several builds, I will make a clean install for be sure.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 17, 2015, 12:47:17 PM
Donkey Kong 64 has a major warping issue on x86 Intel devices.
I can instantly warp out of bounds by touching a certain part of the left wall near Cranky's Lab,and also in DK's Cabin at the boombox table when jumping at it.
Please don't make me go through the 20+ different builds worth of testing because of this.

Needed mention:This does not happen in Gillou's version,which must mean something crucial is missing from the Alpha builds.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 17, 2015, 01:15:52 PM
@retroben    the issue looks like the post #328?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 17, 2015, 03:44:47 PM
I have said it many times and I will say it again.  Gilles is working on pushing his dynarec fixes upstream.  He's already got a bunch of them upstream, and they are in the latest alphas.  He still has a few more to go.  From what I understand, he is not fully comfortable with the remaining fixes and wants to find a "better" solution before they get pushed upstream (https://github.com/Gillou68310/mupen64plus-ae/issues/1#issuecomment-68690556).  In other words, he's concerned that the remaining fixes are just a "band-aid" and might create as many new bugs as they fix.  So he is wisely cautious.

Once his fixes are merged upstream, I will pull them immediately into the alphas.  I have no control over when they will be merged upstream, but you can be sure I will make them available here as soon as humanly possible.

@Gilles - Feel free to make a branch off of master if you want folks to test your remaining fixes.  They will be built automatically every hour and posted here (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/).  You can discuss them here or on a separate thread -- whatever you like.  I would recommend changing the Android manifest so that users can install it side-by-side with the alphas.  (The easiest way to do it is in the context menu in Eclipse, when you right-click on the project.)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 17, 2015, 03:58:31 PM
Please don't make me go through the 20+ different builds worth of testing because of this.

You can do whatever you wish.  The more effort you feel like putting in, the less the devs have to do.

Speaking of which, I kind of feel all alone again on this project.  If any devs want to join in and tackle some major issues, that would be fantastic.
 - Fix the crash on exit that xperia64 has described, almost certainly related to ae-bridge
 - New gallery screen
 - Multiple, timestamped auto-saves (in case the last auto-save is corrupt)
 - Selection screen for unmatched/unknown ROMs (e.g. prompt for closest match or define new meta-data)
 - Hi-res texture UI for friendliness
 - General front-end polishing
 - Polygon offset wizard or something (need to know GL)

I know that the java code has become a behemoth, but I'll be happy to explain anything and everything as best I can if any dev has any questions.  I will write formal documentation if necessary.

Right now I'm polishing the ROM search process to incorporate @retroben's good suggestions.  I'm also working on a few things I left dangling upstream.  If no one tackles the crash on exit, that will be my next priority.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 17, 2015, 04:03:18 PM
I do want to redo CheatActivity with an ActionBar. Are we using appcompat_v7 yet? If so, I'll try to work on it soon.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 17, 2015, 07:21:10 PM
I'll add it if it's not there already.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 17, 2015, 08:17:15 PM
Speaking of which, I kind of feel all alone again on this project.

Sorry about that, lately I seem to only have an hour or two here and there to spend on programming.  I have a little time tomorrow, though.  I'll try and get something useful committed.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 18, 2015, 02:01:30 AM
amazing the new refresh option  ;D
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v on January 18, 2015, 02:44:40 AM
Scanning for ROMs causes an emulator crash.
Title: Re: 3.0 Alpha Testing
Post by: littleguy 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.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 18, 2015, 06:28:27 AM
Alpha 16 posted.  See OP for changelog and download link.
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v 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.
Title: Re: 3.0 Alpha Testing
Post by: littleguy 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.
Title: Re: 3.0 Alpha Testing
Post by: littleguy 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.
Title: Re: 3.0 Alpha Testing
Post by: Paul 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?
Title: Re: 3.0 Alpha Testing
Post by: d3n3 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.


Title: Re: 3.0 Alpha Testing
Post by: rafar on January 18, 2015, 10:05:33 AM
glide64 fast, goes slower on my g2 than glide64 accurate, did you try with this plugin?
Title: Re: 3.0 Alpha Testing
Post by: d3n3 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.
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v 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.
Title: Re: 3.0 Alpha Testing
Post by: retroben 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?
Title: Re: 3.0 Alpha Testing
Post by: Paul 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.
Title: Re: 3.0 Alpha Testing
Post by: retroben 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.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 18, 2015, 02:05:42 PM
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.

I've been playing around with the file itself, and unable to extract it with any other utilities I have either.  Definitely appears to just be a corrupt zip file (either a bad zip, interrupted download, or possibly an exploit of some type).  Whatever the case, I'll add in a try/ catch block to make sure when these types of files are encountered they do not crash the app.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 18, 2015, 04:13:48 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 an FYI for anyone who's curious - the latest version has no difficulty with zip files that contain ROM files and other kinds of files together.

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.

Yes, GLES hardware implementation is all over the place.  Here was my first ever post to GitHub:
https://github.com/mupen64plus-ae/mupen64plus-ae/issues/5

And it's still discussed to this day:
https://github.com/mupen64plus/mupen64plus-video-rice/issues/42
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 18, 2015, 04:17:15 PM
@scorpio16v: this build (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201501181501_8c69c17.apk) (commit 8c69c17) shouldn't crash any more if it encounters that corrupt zip file.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 18, 2015, 06:17:32 PM
- Polygon offset wizard or something (need to know GL)

I don't know enough GL myself, but my thought on a possible strategy for this would be to set up a scene with two colored polygons (say red and blue, with red being the one you want to be on top).  Then pick an offset value and use glReadPixels to determine the color of a particular pixel.  Repeat using a bisect-like "higher, lower" function until the proper offset is found (presumably the threshold at which the pixel is red and would become blue if adjusted any further).
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on January 18, 2015, 06:37:23 PM
I don't know enough GL myself, but my thought on a possible strategy for this would be to set up a scene with two colored polygons (say red and blue, with red being the one you want to be on top).  Then pick an offset value and use glReadPixels to determine the color of a particular pixel.  Repeat using a bisect-like "higher, lower" function until the proper offset is found (presumably the threshold at which the pixel is red and would become blue if adjusted any further).

The problem is with GLES 1.0, which I think is what Mupen uses? (Correct me if I'm wrong here)
Unlike GLES 2.0+ which is entirely shader based, 1.x has a fixed pipeline which doesn't directly talk to the GPU, it has to run through a hardware translation layer that converts your fixed pipe into a shader based one that the GPU understands, and this is what varies chip to chip.

The solution to permanently fix it would be to switch to GLES 2.0, but this would be a shit ton of work... and... I'm not doing that unless someone is paying me, lmao. As an added bonus you'd get a significant bump in performance though.

p.s. Don't actually offer me money to do this, I value my free time too much, haha.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 18, 2015, 06:42:22 PM
@Paul Yes that's exactly what I was thinking :D  I tried tinkering with this a long time ago, to see if I could make a simple java-based dialog with java GL calls (simpler to avoid jni).  I might dig that up again.  I think it might be important to have a few polygons, some at an angle with respect to the viewer to address polygon-offset-factor.

Edit: @Zaneris - mupen is already GLES 2.0.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 18, 2015, 08:24:51 PM
I dug up my old polygon offset stuff.  Just a start, but pushed it to my fork.

Was thinking an ideal test would have a spinning cube where you tweak the settings until you see blue, green, and red sides.  Too much offset and the green side turns red, too little offset and the green side turns blue.  Then do the bisect algorithm to narrow down on the right values.  Having the cube tumbling randomly would ensure that the offset works well at various viewing angles.  Would be trivial to program in GL, just need to figure out the java context management stuff.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 18, 2015, 08:58:58 PM
The "tumbling around randomly" concept would require human interaction though.  Would be nice if possible to determine a specific set of angles that could be sampled programmatically to auto-detect the correct offset value (versus having the user tweak the settings until it looks right).  Probably wouldn't take more than a second or two for the program to do, and could potentially be added as part of the "first run" actions.

That said, a manual process like you are thinking would be easier to develop (and probably a good place to start -- certainly better than what we have now, where you change the value, fire up Mario 64, rinse, and repeat).
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 18, 2015, 09:31:04 PM
Yeah good point.  I guess it's just baby steps at this point ;)
Title: Re: 3.0 Alpha Testing
Post by: Zaneris on January 18, 2015, 10:10:25 PM
Edit: @Zaneris - mupen is already GLES 2.0.
Just took a look and I'm not so sure...

It says it requires it in the manifest, yes.
Code: [Select]
<uses-feature android:glEsVersion="0x00020000" />And SDL has support for GLES2 rendering...

But I'm not seeing a 2.0 surface initialized anywhere...
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 18, 2015, 10:19:38 PM
See GameSurface.java for context creation.  Android.mk links against glesv2.  All video plugins include SDL_opengl_es2.h.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 07:32:38 AM
I made some modifications to the new dynarec and the DMULTU instruction is now recompiled instead of interpreted (ARM).  I need some testers to be sure nothing has been broken during the process. Autobuild is available here http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_DMULTU_201501191001_fc16ce2.apk (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_DMULTU_201501191001_fc16ce2.apk)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 19, 2015, 08:20:33 AM
Awesome, thanks Gilles.  Testers - you can install this side-by-side with the Alpha builds - no need to uninstall.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 19, 2015, 08:30:43 AM
Autobuild will be available here http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/ (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/) within an hour and should start with "Mupen64PlusAE_DMULTU"

Phooey.. doesn't look like it built.  I'll have to diagnose when I get home this evening, sorry about that!
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 08:35:13 AM
Autobuild problem?
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 19, 2015, 08:39:47 AM
Maybe.  Unless I don't understand the "git branch -r" command properly, in which case it may auto build in 20 minutes (script runs "git branch -r" before running "git fetch --prune --all", so if a new remote branch isn't detected until running fetch, then it will be picked up next time the script runs).  I really need to understand git better if that is the case..
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 19, 2015, 09:05:26 AM
Cool, it built (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_DMULTU_201501190902_7088aab.apk) this time around.  This was due to what Littleguy explained to me on another thread recently:

It took me a while to realize it, but there are three branches of interest, not two, when you clone a repo.
 - The remote branch (lives on github)
 - The remote-tracking branch (mirrors the remote branch as of last fetch, lives on your machine)
 - The local branch (lives on your machine, is independent of remote-tracking branch)

As a safety measure, git doesn't delete the remote-tracking branch on your local machine when the remote branch is deleted.  You have to intentionally delete it with git fetch --prune.  There's a git config flag you can set if you want to prune by default: http://stackoverflow.com/questions/18308535/automatic-prune-with-git-fetch-or-pull

git fetch --all is what created the remote-tracking branch (origin/test-glide-...) on your cron machine.  That branch existed temporarily on github until I decided to delete it.

So, if I hopefully understand how git works now: "git branch -r" looks up the "remote tracking branches", which are initially created when "git fetch" is run to retrieve the actual remote branches.  Thus, since the script ran "git branch -r" before "git fetch ...", it won't know about and build a new branch until it runs the second time.  I should be able to swap these two commands to fix that little quirk.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 09:10:43 AM
Thanks Paul, I uploaded the link in my initial post  ;)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 19, 2015, 09:18:36 AM
So, if I hopefully understand how git works now: "git branch -r" looks up the "remote tracking branches", which are initially created when "git fetch" is run to retrieve the actual remote branches.  Thus, since the script ran "git branch -r" before "git fetch ...", it won't know about and build a new branch until it runs the second time.  I should be able to swap these two commands to fix that little quirk.

Exactly.  `git fetch --prune --all`, then `git branch -r`.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 19, 2015, 09:21:22 AM
Thanks Gillou, I going to test it   :)


edit: dont work any game to me. It appears the next message with black background: "Failed to attach core library"

Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 09:46:21 AM
Did you get a warning at first launch? Something like "The app might not have installed properly"?

Nevermind I forgot to commit a part of the code :o
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 19, 2015, 09:49:08 AM
jajaja no problem!
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 09:57:26 AM
Fixed but you'll have to wait for the new autobuild, sorry about that!
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 19, 2015, 10:05:14 AM
downloading the new build  ;D

edit: at the moment works correctly.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 19, 2015, 11:26:18 AM
Still getting tree warp glitch and 4th dimensional vine glitch on the DMULTU build. :(
Edit:Creepy Castle weak spot still there. (one of the small stubs on top of castle)

I also noticed a particular music bug (probably relevant to all builds) where the first time a fresh song plays,it gets delayed for a long couple of seconds. (1st Cranky barrel round start had five seconds of musicless delay)
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 11:43:29 AM
I'm not expecting to fix anything with the DMULTU build, I'm focusing on optimization ;-)
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 11:45:31 AM
Also does someone has a Cortex-A15 device? (you can check here http://www.futuremark.com/hardware/mobileice_storm_unlimited/filter/android (http://www.futuremark.com/hardware/mobileice_storm_unlimited/filter/android)) I might have some optimizations for it (DIV/DIVU).
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 19, 2015, 11:52:10 AM
xperia64 has a shield tablet
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 19, 2015, 11:53:26 AM
For your next build Gillou, could you change the title of the app as well? I have to launch it through link2sd because I'm not sure which package is the alpha and which is your build.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 19, 2015, 01:53:49 PM
Sure  ;)
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 19, 2015, 02:04:16 PM
I tested dk64 a little bit with the dmultu build with no issues. ( although on all current builds the audio is really out of sync no matter what, might be an audio format issue )
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 20, 2015, 01:48:47 AM
Conker in the DMULTU build looks perfect with the fading shadow on jumps and is a little faster now,not sure if also the same on normal Alpha or not.

Gotta bring this up again...
Can a form of "Register Caching" (a feature found in PJ64) be implemented into Mupen64Plus AE?
Last time I asked,the answer was about Android VM heap not having enough available RAM...
But what about using NDK for utilizing the whole device's RAM?

Register Caching shows a major increase in performance in Conker on PJ64,and when disabled,the game lags the same way as it does on Mupen64Plus AE.
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 20, 2015, 07:57:50 AM
Can a form of "Register Caching" (a feature found in PJ64) be implemented into Mupen64Plus AE?

That is a better question for upstream IMO.  AE is intended to be an Android front-end to Mupen64Plus.


Last time I asked,the answer was about Android VM heap not having enough available RAM...
But what about using NDK for utilizing the whole device's RAM?

Whoever said that was mistaken.  The emulator is written in C/ C++ and already built with the NDK, so the VM heap is not a limitation to anything except the Java-based UI.  The feature you are describing sounds like a component of the core (granted I don't entirely understand the meaning of "register caching" -- the dynarec already utilizes a cache of registers for mapping N64 registers to host registers using a least-soon-needed strategy.. but last time I brought that up, your response sounded like you were referring to something else.)

Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 20, 2015, 08:19:23 AM
I made another optimization on DIV/DIVU instructions for devices having "Integer Divide" (eg Cortex-A15).
I don't own a Cortex-A15 device myself so I'm not sure this is gonna work. Please test and report.
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_integer-divide_201501200901_a180d01.apk (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_integer-divide_201501200901_a180d01.apk)
!!!!!!!!!!!WARNING!!!!!!!!!!!!!: This will not work on non Cortex-A15 devices.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 20, 2015, 10:06:16 AM
@Gillou68310

I tried the build on a Nexus 5, I think it's faster. I tried the camspy on Perfect Dark, it's fast, before it was very choppy.

Thanks !!
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 20, 2015, 10:09:31 AM
Wow, I didn't even know the camspy worked!  But I never tested either :P

@Jermain - you can have Alpha build and Gilles' test build installed at the same time.  You can turn on FPS display in the global settings to verify the speedup.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 20, 2015, 10:10:21 AM
Guys I have one more question.

When I use my MadCatz Controller the sensitivity is too high, On PC I can change it in the emulator (project 64). When I have sensitivity 50% it feels like a real N64 controller. But sometimes I want it on 100% just depends what game I'm playing.

Like in Perfect Dark when you have to shoot 2 guys to save the negotiator with the sniper rifle it's so hard on Mupen with the sensitivity on 100%. On pc I set it to 50% and I can win like it's really on the N64.

So can you make this option somewhere in the settings?

Thanks !!
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 20, 2015, 10:11:00 AM
GREAT IDEA LITTLE GUY !!

I'll check it out !!
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 20, 2015, 10:13:26 AM
The setting is in the Controller Profiles.  Copy a built-in profile, or create a new one.  There's a setting for sensitivity in the mapping screen that pops up.  Then select your newly-created profile for whichever games you want to use it on.  Keep in mind, if you use lower sensitivity, you might not be able to move full speed.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 20, 2015, 10:15:57 AM
Gillou's build is faster. Camspy is between 15-20 frames. Old Build is 13-17.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 20, 2015, 10:23:22 AM
In mario tennis I noticed a better performance too. Maybe I must use a older device for compare easily, all games run pretty well (30-50 fps).
Title: Re: 3.0 Alpha Testing
Post by: Paul on January 20, 2015, 10:31:46 AM
This leads to an interesting question of how to eventually support this in the published app (or if that is possible).  For the time being, I could just have a Cortex-A15 version of future releases available from here on the forum.  Longer-term we might actually be getting to the point where it would be useful to have a plugin-import functionality (I started looking into this a while back with TotallyApps when he was active, since that was a necessary function of his front-end.. as a proof of concept, it was possible).
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 20, 2015, 10:41:49 AM
Is A15 a distinct ABI that can be specified in Application.mk?  If the architecture is that different it seems Android would expose it as a separate build option.

Edit: Worst-case, we could bundle a separate .so file for A15, and select the appropriate one at runtime... would be transparent to the user (but add to the app size).
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 20, 2015, 10:55:00 AM
@rafar, @Jermain which build are you testing, DMULTU or Integer-Divide?
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 20, 2015, 10:58:22 AM
Gillou the app called itself Mupen Integer-Divide
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 20, 2015, 11:01:01 AM
Thanks Jermain, I didn't know the nexus 5 has a Cortex A15 processor :o
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 20, 2015, 11:04:49 AM
Guys you can upload 2 different versions of the app on the google play store, And the play store will serve the normal build to everybody else and the Cortex a15 build to supporting devices.

It's possible for differend opengl versions, I don't know if it supports different Cortex versions.

read up on it here:

https://developer.android.com/distribute/googleplay/developer-console.html

or just test it out on the play store yourself. whoever is having the playstore account.
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 20, 2015, 11:06:09 AM
@Gillou68310 yes it has a krait core snapdragon 800, which is like a cortex 15.

Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 20, 2015, 11:06:31 AM
Quote
Edit: Worst-case, we could bundle a separate .so file for A15, and select the appropriate one at runtime... would be transparent to the user (but add to the app size).

@littleguy actually I thing this is the best way to handle it
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 20, 2015, 12:15:15 PM
I wonder if there is anything similar for Adreno GPUs. :P
It would be cool to see it not lag quite as much because of Qualcomm's Adreno weakness. :(
Though,I read something from a few years ago on here that Qualcomm Adreno already got some kind of performance fix involving a screen touch fps issue.

@Gillou:Here's to hoping there is a proper instruction you could find that can enhance performance on the Adreno GPUs,if you are willing to do so. (or CPU if that is the problem)
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 20, 2015, 12:51:23 PM
Quote
@Gillou68310 yes it has a krait core snapdragon 800, which is like a cortex 15.

Lol thanks for the info I have the same processor on my phone and I didn't even know it's based on cortex A15
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 20, 2015, 01:05:40 PM
I found an intersting post from sonicadvance (dolphin dev)
https://developer.qualcomm.com/forum/qdevnet-forums/general-discussion/26532 (https://developer.qualcomm.com/forum/qdevnet-forums/general-discussion/26532)
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 20, 2015, 02:18:37 PM
*reads linked page*
Possibly dumb question: About your DIV/DIVU build,what position does that put my Qualcomm Krait with Adreno in?
I have VFPv4 as well,according to PPSSPP's helpful info listing feature.

I guess that if you were to add the instructions mentioned in that page,it may help Qualcomm's performance and maybe even more,provided that it can be used on Mupen64Plus AE.

Edit:IDIVa and IDIVt are also actually listed when viewed on PPSSPP! ;D
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 20, 2015, 02:23:55 PM
All the games I tried with the divi/divu test run very smoothly. The remaining audio crackling from skipping is gone in smash and conker.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 21, 2015, 12:27:28 AM
My Adreno runs it just fine,or did you mean just the optimization would not work on non Cortex devices?
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 21, 2015, 04:40:39 AM
Quote
Edit:IDIVa and IDIVt are also actually listed when viewed on PPSSPP! ;D

IDIVa is actually the cpu feature required to be able to run the "Integer Divide" build.

Everyone can check if it's available in the hardware info page (look for "Features")
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 21, 2015, 05:40:02 AM
I dont know if this info is useful for you but I found the next info in that page, I have a lg g2 (snapdragon 800)

Features: swp half thumb fastmult
vfp edsp neon vfpv3 tls vfpv4 idiva
idivt
CPU implementer : 0x51
CPU arquitecture : 7
CPU varia : 0x2
CPU part: 0x06f
CPUrevision : 0
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 21, 2015, 06:46:43 AM
Edit:IDIVa and IDIVt are also actually listed when viewed on PPSSPP! ;D

As Gilles said, you can also obtain the info directly from mupen64plus-ae alpha builds.  From the gallery, tap About -> Hardware info and scroll down.  Press the Share button to copy/paste or do whatever you want with the info.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 21, 2015, 07:53:03 AM
I updated the "integer divide" branch. The IDIVa feature is now auto detected at runtime and used if available. Also I'm sending the list of available features to the log, so everyone can check the log to be sure the feature is actually being used.
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_integer-divide_201501210801_e250b48.apk (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_integer-divide_201501210801_e250b48.apk)
Title: Re: 3.0 Alpha Testing
Post by: IDSG on January 21, 2015, 08:54:03 AM
I updated the "integer divide" branch. The IDIVa feature is now auto detected at runtime and used if available. Also I'm sending the list of available features to the log, so everyone can check the log to be sure the feature is actually being used.

So if the CPU don't have the IDIVa feature it will use the DMULT solution? or it will use the normal approach?
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 21, 2015, 09:07:17 AM
Quote
So if the CPU don't have the IDIVa feature it will use the DMULT solution? or it will use the normal approach?

It will use the old DIV/DIVU approach (slower). DMULTU is another optimization,  it's not related to this one ;)
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 21, 2015, 10:08:13 AM
One more optimization to test ;D
DMULT instruction is now recompiled instead of interpreted (ARM).
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_DMULT_201501211201_3e1d814.apk (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_DMULT_201501211201_3e1d814.apk)
Title: Re: 3.0 Alpha Testing
Post by: IDSG on January 21, 2015, 11:41:29 AM
Quote
So if the CPU don't have the IDIVa feature it will use the DMULT solution? or it will use the normal approach?

It will use the old DIV/DIVU approach (slower). DMULTU is another optimization,  it's not related to this one ;)

Oh, well i tested the DMULTU opt, and works perfectly without bugs on my Dual Cortex A9, it's a little faster
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 21, 2015, 08:52:16 PM
So,by theory,could you convert all of the instructions to recompiler for a crazy performance gain at the cost of accuracy?
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 21, 2015, 10:48:31 PM
One more optimization to test ;D
DMULT instruction is now recompiled instead of interpreted (ARM).
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_DMULT_201501211201_3e1d814.apk (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_DMULT_201501211201_3e1d814.apk)
Does this one include the idiv optimization? If not, I'd be curious to see how fast a build with both optimizations can run.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 21, 2015, 10:53:45 PM
When using the rice plugin with Doubutsu no Mori (J) [!] it renders the intial n64 boot logo multiple times overlapping about sixteen times all over the screen, this didn't happen in 2.4.4

The textures for title screen text aren't showing up either using rice, this also happened in 2.4.4 though.
Both problems exist within latest integer-divide also.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 21, 2015, 10:56:54 PM
I have the need for speed because there's hardly any noticable speed improvements from the optimized builds at all on my weak FireTV. :(
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on January 21, 2015, 11:48:51 PM
I have the need for speed because there's hardly any noticable speed improvements from the optimized builds at all on my weak FireTV. :(

You should be able to overclock it to 1.9Ghz, the Nexus 7 2013 can safely overclock to 1.7Ghz from it's stock 1.5Ghz, so a 200Mhz overclock on the firetv to 1.9Ghz should be no problem with it's bigger case area for heat dissipation.
The Adreno320 can be overclocked safely to 531Mhz.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 22, 2015, 03:17:07 AM
Tested again,and the Integer Divide build is a little smoother with Banjo-Tooie.

Edit:Remember,mine is Qualcomm Krait with "Adreno" instead,so it is a little different than Cortex and more different than others.
What's your CPU and GPU Jermain? (Edit it into your post like I just did mine.)
Title: Re: 3.0 Alpha Testing
Post by: Jermain on January 22, 2015, 06:43:01 AM
The DMULT version is 1 to 2 frames better.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 25, 2015, 02:38:29 AM
Decided to test again,and Divide seems to be faster by a few frames.
Everything in N64 emulation has being going crazy lately. (mainly PJ64 updating all over and compiled via EmuCR)

Let's hope Gonetz gets a little crazy with GlideN64 too. ;D
I'd really like to see if performance will be greatly increased with it on Mupen64Plus AE.
Hope he won't hit too many roadblocks with GPU/device differences,though I'd assume we would be testing it on our devices to help him out when the time comes.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 25, 2015, 03:52:14 AM
@retroben could you compare Pokemon snap (in first stage) in both versions, alpha and divide or dmult?

with alphas have 12 or 13 fps, and in the dmult version I only have 3 fps.

edit: I dont know how could improve the performance that plugin, I only think that plugin will fix many gliches or issues as the cam spy of perfect dark or the eye of truth of legend of zelda...
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on January 25, 2015, 04:56:22 AM
This doesn't seems to be related to my optimizations. The glide plugin seems to be the cause, try switching to rice or gln64.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 25, 2015, 06:38:13 AM
with gln64 plugin the game has a normal speed.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 25, 2015, 11:07:13 AM
@xperia64 Does this fix the crash on exit?

http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_fix-crash-on-exit_201501251102_1b36892.apk
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 25, 2015, 12:35:52 PM
The first game I load an exit works fine. However, the next game I load is unstable. Either PlayMenuActivity crashes (silently or with the normal android crash dialog), the game crashes/stops responding, or depending on the game, it works fine.
Banjo-Kazooie->Super Mario 64=PlayMenuActivity crash.
Yoshi's Story->F-Zero X=works fine sometimes. Other times the graphics go crazy and it displays a chopped up PlayMenuActivity before displaying the virtual controls and hanging indefinitely
Super Mario 64->Mario Kart 64=always crashes after going in-game
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 25, 2015, 12:40:44 PM
Thanks much, that's "progress" of some sort.  I'll keep digging.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 25, 2015, 04:28:54 PM
@xperia64 - If you get some time, would you mind posting all your recent crash logs from the mupen64plusae-v3-alpha/CrashLogs (i.e. crashes from Alpha 16 and from this test branch)?
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 25, 2015, 04:59:06 PM
Last crash report was from Jan 13th. Do I have to enable crash reporting, or is that just ACRA related?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 25, 2015, 05:05:28 PM
I noticed I don't have any crash reports either.  I'm not sure why.  Maybe it doesn't catch crashes if they originate in native code  ???  I'll have to check it out.

In the meantime, if you could capture the logcat by other means that would be very helpful.  I can't remember if you were getting stack traces or register info, but that would be ideal.

On a related note, do any devs care if we remove ACRA from version 3?  I'm not sure how helpful it ended up being.  BugSense was nice when it was free, and good for finding bugs in the front-end.  But ACRA isn't as easy to use and seems a little fussier.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 26, 2015, 10:07:16 AM
Test build.  Please let me know if this fixes all the recent bugs in Rice video that have shown up since 2.4.4.  Also, this should fix audio delay, and maybe pitch.  Let me know if it doesn't.

http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_test-audio-rice-fixes_201501261002_914dbc3.apk
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 26, 2015, 10:29:43 AM
I tested the Rice+Audio build. Rice is better, but there are thin lines on the left and right side of the screen where the glitch is still present http://m.imgur.com/qJKjG9J

With the audio, it crackles for a few seconds but then gets in sync.I noticed that ultra-low latency doesn't make things high-pitched anymore. However, about 1/3 through the DK64 intro the audio starts to desync.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 26, 2015, 11:33:05 AM
wow, I dont know if has a perfect sync but it is very close. I tested mario 64 with rice and sync audio and in my opinion it works well again
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 26, 2015, 01:34:31 PM
Banjo-Tooie looks good again,thanks for mostly fixing it.
I still get whole screens of garbage on Smash Bros. with Rice,but only with random frames while the outside border stays filled with garbage.
Could there be an option with Rice for changing the filter type to "force bilinear" or "force point sampled" so it doesn't constantly switch so much like it does on SM64 when getting a star?
(look at the lives counter pixels when collecting the star)

The Audio on each game now sounds correct to me so far.

Something to mention,can the VI rate 2200 overclock feature from Retroarch be added to Mupen64Plus AE for games like SM64 which has a really jagged and choppy framerate?
It even looks choppy with CountPerOp already set to 1 by default.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 26, 2015, 01:47:53 PM
Thanks retroben.  Pretty much all of your questions are over my head ??? so perhaps Paul or Gilles or xperia64 can jump in.

Regarding the Rice fix, I basically isolated one change that was made to Rice several months ago, and simply reverted it.  I'll open an issue upstream to determine the best way to actually fix the problem, now that it has been pinpointed.  The Rice issue affects all Alphas since Alpha 1.  If anyone is feeling energetic, I would appreciate any comparisons between 2.4.4 and my test build, for Rice.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 26, 2015, 02:49:48 PM
I think one of the main things to focus on with Rice is its unusually terrible performance in comparison to Glide64.
I get 5fps more with Glide64 than I get with Rice on Conker during the "you love manual long time" cutscene.

I normally used Rice because it had the best performance when compared to other plugins.
(excludes Super Smash Bros. because Glide64 is paerfect AND faster)

I wish there was a way to get the later version of Rice (faster Mudlord) or the Aristotle plugin ported over,but they are Windows exclusive AFAIK. :(
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 26, 2015, 04:18:07 PM
I have a good performance with all plugins, maybe with specific game one plugin get more issues, but the most of games work at 25 fps and I think my phone reachs that speed with all games.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 26, 2015, 08:56:25 PM
Noticed another issue with it,input gets disabled briefly when using fastforward,even for a few seconds.
I think it is because the short pause was replaced by a brief slowdown to keep the game going when fastforward was released.

@retroben - Are you still having this issue on the latest audio-fixes test build?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 26, 2015, 09:34:02 PM
I'll do it tonight. Checking the logs, it's crashing in libEGL  :o
eglReleaseThread and some pthread stuff are the only relevant looking areas just from glancing the logs.
The first game I load an exit works fine. However, the next game I load is unstable. Either PlayMenuActivity crashes (silently or with the normal android crash dialog), the game crashes/stops responding, or depending on the game, it works fine.
Banjo-Kazooie->Super Mario 64=PlayMenuActivity crash.
Yoshi's Story->F-Zero X=works fine sometimes. Other times the graphics go crazy and it displays a chopped up PlayMenuActivity before displaying the virtual controls and hanging indefinitely
Super Mario 64->Mario Kart 64=always crashes after going in-game

Going out on a limb here, but it sounds as though one of the system shared libraries (perhaps the tegra driver .so) is not unloading one or more of mupen64plus-ae native libraries.  No native or gl state should be retained between launches, by design of the loading/unloading process in ae-bridge.  Unfortunately I have no idea how to confirm or deny that theory, much less solve it.  Or I could be completely off on a wild goose chase.

Edit: We should also look into the teardown of the gl context in GameSurface.java.  Perhaps something is not getting released properly.  I'll see if I'm missing any error messages in that code...
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 27, 2015, 01:07:11 AM
@retroben - Are you still having this issue on the latest audio-fixes test build?

Yes,input still gets briefly disabled in the last audio fixes rice build,unless yet another update has been added.
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 27, 2015, 02:27:18 PM
Hires textures (the 3ds texture mod 0.7 beta) for Zelda Ocarina 1.0 are not loading in the latest Alpha.
The "famous" build loads them just fine. *snicker*

Edit:Checked the stable 2.4.4 and no hires textures are loading and now also the Alpha is no longer loading the Banjo-Tooie hires texture pack either. (it loaded before on the same Alpha)
It used to load them,but now is not working for some stupid reason.

The only one that works for hires textures is that one build by Gillou.
We really need that source data!
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 27, 2015, 02:32:26 PM
I tested the last build with crash exit fixes, and I had a lot of problems with mario 64. While I was testing the game, Mario is lying on the floor, the sound crashes and finally when I go out of the game, crashes as usually.

Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 27, 2015, 02:52:15 PM
The only one that works for hires textures is that one build by Gillou.

But the odd thing is that Gilles didn't modify any of the hi-res texture loading stuff.

Just to be clear, hi-res textures only work with the Rice video plugin.  When you say hi-res textures don't work, does the app just use the normal built-in textures and play like normal, or does the app do something strange instead?

We really need that source data!

I have the source.  As I've said before it's available as separate branches on my fork for anyone to see:
https://github.com/littleguy77/mupen64plus-ae/branches/all
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 27, 2015, 02:57:56 PM
I tested the last build with crash exit fixes, and I had a lot of problems with mario 64. While I was testing the game, Mario is lying on the floor, the sound crashes and finally when I go out of the game, crashes as usually.

Thanks much.  You and xperia64's reports are helping me isolate the problem.  I did some more debugging on this last night and I may have a few more avenues to explore on this.  One that's relatively easy to test is a race between the input plugin and the ae-bridge.  I'll try to post another test build soon.

@rafar - Were you having the crash-on-exit bug with the Alphas as well, or just that test build?
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 27, 2015, 03:05:15 PM
It just loads normally without the hires textures intact.
I can't help but blame Qualcomm and/or Adreno for this annoyance.

The pack I am using was tested on Android already because of screenshots on N64oid.

http://forums.zelda64.net/topic/10473840/1/

And I know I have it in the right folder because Banjo-Tooie hires textures were already imported and worked on the Alpha at one point when enabled by accident from a default rice-balanced profile.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 27, 2015, 04:51:13 PM
I tested the last build with crash exit fixes, and I had a lot of problems with mario 64. While I was testing the game, Mario is lying on the floor, the sound crashes and finally when I go out of the game, crashes as usually.

Thanks much.  You and xperia64's reports are helping me isolate the problem.  I did some more debugging on this last night and I may have a few more avenues to explore on this.  One that's relatively easy to test is a race between the input plugin and the ae-bridge.  I'll try to post another test build soon.

@rafar - Were you having the crash-on-exit bug with the Alphas as well, or just that test build?


I dont know how but at now I can not get mario lying on the floor as I said before, but I have several pics, later I will edit this post. Moreover, the audio neither crashed as I said previusly.

It is really difficult to assert when I have a crash-on-exit, I have tested for 10 or 12 times and only crashed twice, very close to test build results I get.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 27, 2015, 05:43:31 PM
When mario was lying on the floor, does that mean you couldn't control him?
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 28, 2015, 02:44:13 AM
Yes, mario can move and also jump. This happened to me only the first time I tested the last build crash-on-exit.

(http://nsae02.casimages.net/img/2015/01/28/mini_150128093846390586.png) (http://www.casimages.es/i/150128093846390586.png.html)

I moved him around the castle.

(http://nsae02.casimages.net/img/2015/01/28/mini_150128093834351435.png) (http://www.casimages.es/i/150128093834351435.png.html)

And here he is jumping.

(http://nsae02.casimages.net/img/2015/01/28/mini_150128093858235277.png) (http://www.casimages.es/i/150128093858235277.png.html)

I say this if it could be useful for you about the crash on exit.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 28, 2015, 07:38:33 PM
LOL  ;D :o

Of all the crazy bugs I've seen on this forum, this is easily the funniest!

Fortunately it's only in an experimental test build.  More signs pointing to state not being cleared between launches.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 29, 2015, 07:53:33 AM
Alpha 17 published.  Link and change log are shown on the OP.

Some of the fixes from the test builds have been officially integrated (audio latency and rice fixes).  Gilles' optimizations are NOT in Alpha 17 yet since they are not upstream yet.

The global settings were streamlined just a tad.  You may want to double check your "joystick animation" and "display framerate" settings after you upgrade.

Bugs in Rice video should only be compared to version 2.4.4 on the Play store.  Do not bother using or comparing Rice in Alphas 1-16.
Title: Re: 3.0 Alpha Testing
Post by: rafar on January 29, 2015, 11:46:32 AM
well done, mario 64 sync is good with rice, both banjo tooie and banjo kazooie dont have so good sync as mario 64 (I only tested that 3 games)

until now I have not seen any crash on exit  ;D
Title: Re: 3.0 Alpha Testing
Post by: retroben on January 29, 2015, 12:36:07 PM
Super Smash Bros. is not flickering the entire screen with garbage anymore,but still has the outer edges covered with it.
This happens in other emulators,so not much more you can do about it.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on January 29, 2015, 06:48:45 PM
I'm not sure if it's been on all the Alphas, but saving custom cheats with options is broken. Saving regular custom cheats works, but if I set the value to ???? and add some options, it doesn't save. I'll try to look into that soon.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on January 29, 2015, 07:18:31 PM
Sounds good.  You should definitely take the lead since I am pretty useless on the cheats UI.  Hopefully git-bisecting will narrow it down quickly.

On another note, I added a fair bit more error logging in ae-bridge for Alpha 17.  In case there are any clues on your crashing.  You might need to log with an external app or PC though.  I discovered that native segfaults and stuff do not get percolated up as java exceptions, hence they do not trigger the crash handler to persist the log to disk.  There may be some workarounds that I can try, at least on a test branch.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 05, 2015, 01:32:19 AM
@xperia64: Just re-found out that ClassicBoy has realtime cheats access which worked on N64 with Banjo-Tooie and my "no frameskip" code when I tested it disabled then enabled to make it reach 60fps from the original framerate.
You could probably look at it to see how it was done.
Title: Re: 3.0 Alpha Testing
Post by: Haz on February 05, 2015, 01:33:41 AM
Hello, I'm interested in testing (with a focus on Donkey Kong 64). I have two questions..

1. Is it possible to transfer my saved progress from 2.5 and enable version 3 to load the save files. If so, how is this done?

2. Has the transparency big in Donkey Kong 64 been fixed? This is what I was going to test. This bug is presented in the following ways,
* one of the fairies in gloomy gallon can't be photographed
* special barrels display when they should be invisible
* all blueprints display before they have been collected

Please let me know, hope I can help
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on February 05, 2015, 08:27:50 AM
@xperia64: Just re-found out that ClassicBoy has realtime cheats access which worked on N64 with Banjo-Tooie and my "no frameskip" code when I tested it disabled then enabled to make it reach 60fps from the original framerate.
You could probably look at it to see how it was done.
The problem is that ClassicBoy isn't open source, although legally it is required to be.
Title: Re: 3.0 Alpha Testing
Post by: rafar on February 05, 2015, 12:42:27 PM
Hello, I'm interested in testing (with a focus on Donkey Kong 64). I have two questions..

1. Is it possible to transfer my saved progress from 2.5 and enable version 3 to load the save files. If so, how is this done?

2. Has the transparency big in Donkey Kong 64 been fixed? This is what I was going to test. This bug is presented in the following ways,
* one of the fairies in gloomy gallon can't be photographed
* special barrels display when they should be invisible
* all blueprints display before they have been collected

Please let me know, hope I can help


1. I think so, you only must copy and paste the savefiles on the new folder, or rename the old filesave with the name new file is created.

2. Yes, donkey kong 64 is fixed.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 05, 2015, 02:22:00 PM
Any chance of overclocking being possible in a similar fashion to Dolphin on Android?

I would really like to see my FireTV run games at a more acceptable speed since the device lags so badly.
Even Banjo-Tooie WITHOUT my "no frameskip" code is beyond laggy at times,while my tablet runs so much better.

It probably relates to Qualcomm Adreno's crappy driver issues with an outdated version on FTV.

Edit: Just checked my info on PPSSPP and I see V@14.0 as my driver version,no wonder it performs so crappily.
This is a load of BS!
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on February 05, 2015, 07:59:42 PM
Can someone confirm that rice now has texture filtering enabled by default, I believe this is the cause of the broken / missing title menu for Doubutsu no Mori with gln64 & glide64 you can see the pixelation and rice looks filtered.
Title: Re: 3.0 Alpha Testing
Post by: rafar on February 06, 2015, 12:44:10 PM
Tested the last build, and mario 64 with glide64 plugin audio has a good sync. However in other games, the sync audio is not as good as mario 64 (tested only banjo kazooie and tooie), this happened in the previous test audio build with rice.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 06, 2015, 02:00:49 PM
As someone mentioned in a thread,Castlevania 64 crashes on x86 devices. :(
On his Nexus Player,the boss scene triggers it,and it crashes even sooner on my Acer Iconia x86 tablet with the first skellyman cutscene.

Edit:Got some logcat entries for the Castlevania 64 crash of my own.

"date and time" 1905: 1956 F/libc
Fatal signal 11 (SIGSEGV) at 0x00000038 (code=1), thread 1956
(CoreThread)

"date and time" 1905: 1905 I/GameLifecycleHandler
onWindowFocusChanged: false

"date and time" 1968: 1968 D/dalvikvm
Late-enabling CheckJNI

"date and time" 1968: 1968 D/dalvikvm
Try to disable coredump for pid 1968

After that,for some reason I get Moga related entries even though I do not even have one of those controllers.
Just listed the ones I thought were the most important to see if they help at all,lazy date placeholders.
Title: Re: 3.0 Alpha Testing
Post by: Donlavon1 on February 07, 2015, 01:27:41 AM
How do you load hi-res textures on the alpha builds?
Title: Re: 3.0 Alpha Testing
Post by: Haz on February 11, 2015, 04:33:41 PM
Hello, I'm interested in testing (with a focus on Donkey Kong 64). I have two questions..

1. Is it possible to transfer my saved progress from 2.5 and enable version 3 to load the save files. If so, how is this done?

2. Has the transparency big in Donkey Kong 64 been fixed? This is what I was going to test. This bug is presented in the following ways,
* one of the fairies in gloomy gallon can't be photographed
* special barrels display when they should be invisible
* all blueprints display before they have been collected

Please let me know, hope I can help


1. I think so, you only must copy and paste the savefiles on the new folder, or rename the old filesave with the name new file is created.

2. Yes, donkey kong 64 is fixed.

Hate to disappoint, but the transparency bug is still present in the latest alpha release. I've tested it with all 3 emulation profiles.

Any chance it could be looked at? Not sure what you class as a priority etc.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 11, 2015, 08:00:45 PM
Must be device or GPU specific,or your polygon offset value is currently a bad one for your device.

Any chance of adding N64 overclocking for the R4300 so games will even run faster on sluggish devices like my FireTV?
The lag on Banjo-Tooie seems identical to an actual system as I recently watched an LP and saw the lag again.
Having the choice for overclocking the emulator itself would indeed help a lot.
Either like this or similar to how "Dolphin for Android" does it would do.
Also just remembered seeing the settings in Retroarch Android for framerate "fullspeed" and the PJ64 "overclock method of "VI Refresh Rate" which gets increased to "2200" for smoothness.

Where has everybody been lately? Just curious...
Title: Re: 3.0 Alpha Testing
Post by: Haz on February 12, 2015, 03:25:32 AM
I doubt it would be the device. It's not that old... HTC One M8. There are several articles on the Internet detailing the bug and they are using a variety of device.

Thanks
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 12, 2015, 09:41:18 AM
R4300 overclocking is a topic better suited for the upstream developers.  There's a lot of code cleanup going on right now, so it might be something they take into consideration.
https://groups.google.com/forum/#!forum/mupen64plus
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 12, 2015, 10:00:51 AM
Alpha 18 released.  See OP for changelog.  No performance improvements or bugfixes are expected.  Upstream developer bsmiles32 has done a TON of code cleanup and refactoring (reorganization) which will make it easier for new devs to contribute and identify defects in the future.

I recommend you backup your entire GameData directory before upgrading to Alpha 18, just to be extra safe.

@xperia64 did the logcats in the latest builds give any more hints about your crashes on exit?  They should be a lot more verbose.

@retroben Been busy in real life, and the time I do have has been spent helping the upstream devs lately, testing changes and tracking their progress on the core refactoring and a possible new core API version 3.0.  Pretty interesting discussions going on right now.  This is the most activity I've seen upstream since I started working on the project 2.5 years ago.  There are some really smart people hammering through stuff, old and new faces, some people from other emu communities jumping in.

https://groups.google.com/forum/#!topic/mupen64plus/M4mNDN-NseY
https://groups.google.com/forum/#!topic/mupen64plus/4rOO7cX0toY

Current pull requests:
https://github.com/mupen64plus/mupen64plus-core/pulls
Title: Re: 3.0 Alpha Testing
Post by: rafar on February 12, 2015, 12:24:25 PM
@Haz  I played for 2 or 3 hour donkey kong 64 few weeks ago and I reached the first level boss, won several minigames, and set free diddy kong. It has several bugs, but in my opinion is almost playable, I cant assert the game is playable 100% because I have not completed it, or at least play hardly.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 12, 2015, 03:01:24 PM
Not sure what to test for,the most painful thing to test is testing if something else did not become broken.
I caught a glimpse of something Gameshark related on the massive commit page,is a module being implemented in the near future?

Still eagerly awaiting patiently :) for a possible real-time cheat menu for GS codes,and hoping a fix can be found for those really stubborn codes that refuse to apply like my alien/ambulance sounds code for Banjo-Kazooie which can't even activate on Pure Interpreter.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 12, 2015, 03:09:06 PM
Thanks for your patience, and I agree, looking for broken things is tedious.  Therefore I wouldn't ask you to go hunting for them.  Just beware that you might encounter a few, and if you do to let us know (as always).  Just game on :)

Regarding cheats, I am not equipped to answer any of those questions, so if you don't hear from me it's not that I'm trying to ignore you.  Just for future reference ;)  xperia64 and Paul and much more familiar with the cheats engine, since they wrote all of the front-end for it.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 12, 2015, 03:47:00 PM
I already know xperia64 is in control of the cheats,I didn't know that Paul also handled that part as well though.

I am not drectly facing only you for everything,it goes to anyone who may decide to respond to whatever it is I happen to mention and also what other testers mention.

I still wonder if there is a way to fix the freeze in TreasureTrove Cove when using the "no frameskip" code.
I can't even begin to tell you how frustrating it is for that one level to cause so much trouble.
I don't remember if it was freezeless on PJ64,but if so,then maybe Gillou could figure something out on the x86 end.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on February 12, 2015, 04:25:07 PM
Regarding alpha 17 on nvidia shield the fps counter dont work on any games. Nuclear strike crashes no matter what a few other games crashed the emulator cant remember the others at the moment one was wwf attitude
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on February 12, 2015, 05:16:45 PM
Interesting log message before the exit crash:
Code: [Select]
E/ae-bridge(11085): Unknown: undefined symbol: Java_paulscode_android_mupen64plusae_jni_NativeExports_unloadLibraries__
I tried playing around with it myself. The function is definitely called so I don't know what that log means exactly (it also complains about NvGlEs2Init being undefined).
mupen64plus-ui-console and mupen64plus-core both seem to unload fine, but unloading SDL2, ae-imports, or both triggers the crash.
Full logcat: http://pastebin.com/HwTwawx3
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 12, 2015, 06:53:45 PM
Excellent, I will take a closer look.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on February 12, 2015, 07:33:03 PM
And I think I realized what that first log message means. Apparently you can define the JNI method
Java_paulscode_android_mupen64plusae_jni_NativeExports_unloadLibraries
as
Java_paulscode_android_mupen64plusae_jni_NativeExports_unloadLibraries__

and both alias to the unloadLibraries() method inside NativeExports.java, so I guess java searches for both function names because some compilers add random underscores at the end. I tried renaming it to have two underscores at the end, and the error message changed to
Code: [Select]
E/ae-bridge(11085): Unknown: undefined symbol: Java_paulscode_android_mupen64plusae_jni_NativeExports_unloadLibraries
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 12, 2015, 08:58:25 PM
Very interesting, I never knew that or would have thought. 

Since you're already building it locally, would you mind changing the mode to debug in jni/Application.mk, capturing the tombstone, and then trying to use ndk-stack and/or addr2line:
http://bytesthink.com/blog/?p=133

I've never done this myself, but I'm hoping with a little effort you may be able to get a meaningful stack trace for the segfault.  Though it looks like the fault may be buried deep inside some system libraries, in which case it might not help.

Edit: You can also try the ndk-stack script in mupen64plus-ae/tools.  It's been a long time, but I think you can just connect your device to your pc, run the script on your pc, then launch mupen on your device.
Title: Re: 3.0 Alpha Testing
Post by: mrbluru on February 13, 2015, 12:10:41 PM
Apologies if this is already known, but Glide64 seems to render many graphical issues with various games on Android 5.0.1 as tested on my Galaxy Note 4 N910F
This is tested on Alpha 18, which ran fine on Android 4.4.4
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on February 13, 2015, 01:51:47 PM
I noticed some oddness with Glide64 in Banjo Kazooie's intro cutscene as well.

And ndk-stack is kind of useless for the exit crash unfortunately. Just the cryptic pthread_exit+80 log. It doesn't crash on my S2.
Edit:
some weirdness. These combinations of libraries can be unloaded without crashing (granted mupen crashes when loading a game):
mupen64plus-ui-console & mupen64plus-core
SDL2 & ae-imports
mupen64plus-ui-console & SDL2
mupen64plus-core & ae-imports

Edit2:
We have a race condition going on or something.
If I usleep for 0.019531 seconds or greater between unloading (mupen64plus-ui-console & mupen64plus-core) and (SDL2 & ae-imports), it doesn't crash (yes I bisected the time quite a bit :P, 0.015625 crashed).
Now the question is, what is racing? Are the dlopen/dlclose calls asynchronous?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 13, 2015, 07:02:35 PM
Excellent!  A race condition is the lesser of two evils, I hope that's it (I'm worried about a shield-specific system library issue).  I'll keep digging.  That is very useful info.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 13, 2015, 07:19:20 PM
@xperia64 I'll post some questions on chat so as not to fill up this thread.
Title: Re: 3.0 Alpha Testing
Post by: Haz on February 14, 2015, 03:16:16 AM
@Haz  I played for 2 or 3 hour donkey kong 64 few weeks ago and I reached the first level boss, won several minigames, and set free diddy kong. It has several bugs, but in my opinion is almost playable, I cant assert the game is playable 100% because I have not completed it, or at least play hardly.

It's at one specific part...trying to photograph a fairy within the gloomy galleon level. I can upload a save state if people want to see instantly what I'm talking about
Title: Re: 3.0 Alpha Testing
Post by: rafar on February 14, 2015, 03:58:56 AM
@Haz  I am a tester, I think devs are trying to improve the UI and fix the regressions respect older versions as 2.4.4 official app. The specific gliches are going to be solved after that.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 14, 2015, 10:53:46 AM
@Haz: Try the other graphics plugins on that fairy,and if one works on it,keep using it.

I think Glide64 is basicly perfect for DK64 because there was no lag for me and the warp pads are properly transparent before activating them.
I actually completed the game at 101% when on Glide64 itself.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on February 14, 2015, 05:53:19 PM
Does the alpha build include all the core / glide64 fixes / updates from the RetroArch repo?
re2 on RetroArch is now showing everything in-game perfect except the fmv and character models, file selection textures,
this includes showing and transitions between the in-game backgrounds, mupen64ae on the other hand
is showing the character models and file selection textures but the in-game backgrounds come up as blank black.

I've mentioned this before as well the osd / speedometer is broken in f1 world rand prix 1 & 2 but displays fine in RetroArch,
mupen64ae is also showing artifacts outside the game window rendering parts of the game window in multiple slices.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on February 14, 2015, 06:01:12 PM
@littleguy: check the chat. I think I found the cause of the crash.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 15, 2015, 11:38:26 AM
@Mikhail mupen64plus-ae is now simply a front-end for upstream mupen64plus.  The native code matches upstream exactly.
http://www.paulscode.com/forum/index.php?topic=1861.0

So if upstream hasn't pulled in Retroarch's changes, then no, mupen64plus-ae doesn't have it.  If you are having issues with particular games, you'd get a better response by posting issues to the upstream devs.  Be sure to state which plugin and that you're running on ARM.
https://groups.google.com/forum/#!forum/mupen64plus

Are you using interpreter or dynarec in Retroarch?
Title: Re: 3.0 Alpha Testing
Post by: pkmaximum on February 15, 2015, 12:12:24 PM
so I copy and pasted this from another thread. However, this post should be in this one as well.

Alright so I have done some pretty extensive testing at this point. Here we go.

Cheats:

The front-end cheat system support seems flawless, the ability to add your own cheats, enter notes, and custom titles made Star Road possible to play for me.

Controller Profiles:

Was a huge fan of this! now when I do multiplayer n64 games from my shield, configuring and setting up controllers is a breeze! I wish all emulators had this built in.

Speed and Performance:

The not so good part, after experimenting with several different video plugins and running my shield at 100% CPU settings, I still experienced a lot of lags and slow-down playing super mario 64 star road. In addition to that there were audio performance issues (out of sync) and latency with inputting controls to output within the game.

Overall I am very happy to see the direction Mupen64 + AE is going, however, there is definitely room for several improvements at this point that I would not mind seeing.

Does anyone have any advice to boost performance more? I imagine that slow-downs are primarily because this is a fairly advanced rom-hack. Please advise.

Thanks to all the developers behind this project and all the forum admins and support-users who help define an unparalleled experience!
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on February 15, 2015, 01:02:04 PM
@Mikhail mupen64plus-ae is now simply a front-end for upstream mupen64plus.  The native code matches upstream exactly.
http://www.paulscode.com/forum/index.php?topic=1861.0

So if upstream hasn't pulled in Retroarch's changes, then no, mupen64plus-ae doesn't have it.  If you are having issues with particular games, you'd get a better response by posting issues to the upstream devs.  Be sure to state which plugin and that you're running on ARM.
https://groups.google.com/forum/#!forum/mupen64plus

Are you using interpreter or dynarec in Retroarch?

Dynarec with the plugin set to auto which I assume sets glide64 as it's default plugin,
it has another setting which sets the precision so I set it as high and the filter set as Bilinear,
I didn't turn on any the shaders. The audio plugin in RetroArch is really laggy though compared mupen64aeplus, it stutters like mad.
Title: Re: 3.0 Alpha Testing
Post by: a on February 15, 2015, 04:38:22 PM
For Xperia Play, the C-buttons do not work when mapped to the right analog stick anymore in the latest version.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 15, 2015, 07:30:59 PM
You're right, thanks for letting us know.  I'll put it on my urgent todo list.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 15, 2015, 08:02:59 PM
@a - This build should fix your issues with the C-pad on the xperia play.
http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201502152002_752a611.apk
Title: Re: 3.0 Alpha Testing
Post by: rafar on February 18, 2015, 12:51:45 PM
Here's a suggestion to what the UI could look like. What do you guys think?

https://www.dropbox.com/s/eczy7od18l6bqfx/Photo%20May%2003%2C%2011%2007%2048%20PM.png?dl=0

Not bad, but n64 game boxes have a differnt form, so I think they would look a little tiny... I really like how they are currenly.
Title: Re: 3.0 Alpha Testing
Post by: rafar on February 22, 2015, 12:40:49 PM
All is quite quiet here... maybe you guys have a lot of work, or social life  ;D
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 25, 2015, 12:59:47 AM
Gex 3 Deep Cover Gecko has many missing polygons on Glide64 in 2.4.4 and the 3.0 Alpha.
It is so bad that the menus are unreadable because of the missing parts.

The other two plugins have broken water graphics and are slow.
Glide64 is ironically the fastest one for this game.
Title: Re: 3.0 Alpha Testing
Post by: Elwood89 on February 27, 2015, 01:56:44 AM
The "refresh roms" dialog is too big in horizontal mode, one has to hold the phone vertically to be able to scroll the folders.  Happens on both my lg g3/ lollipop and Xperia play/gingerbread.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on February 27, 2015, 12:17:36 PM
All is quite quiet here... maybe you guys have a lot of work, or social life  ;D

Work and family.  Social life? Heck no :P

Keeping up with the upstream discussions has kept me busy enough.  BonzaiThePenguin has just joined the android dev team and has already made some welcome fixes and improvements to the UI.  I'll update the OP this weekend when I have a chance to look through the changelog.
Title: Re: 3.0 Alpha Testing
Post by: OnijJoku on February 28, 2015, 08:39:57 AM
Thank you! Thank you! Thank you devs of Mupen64Plus AE on PaulsCode.com! All of you are incredible.
Title: Re: 3.0 Alpha Testing
Post by: retroben on February 28, 2015, 03:42:40 PM
Just installed the "New UI" build but I don't see any changes.
Is it because I am on JellyBean?

Edit:My bad,checked the number commit and saw it is merely an added feature change to search your list of games for quicker access to the title you searched for.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on March 02, 2015, 08:06:58 AM
Alpha 19 released.  See OP for changelog.
Title: Re: 3.0 Alpha Testing
Post by: rafar on March 03, 2015, 09:44:21 AM
the sound sync has improved a lot in the new alpha, now is near to be perfect in many games. Well done guys!
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on March 03, 2015, 05:32:27 PM
When I try to download covers, the logcat spits out a MalformedURLException @ CacheRomInfoTask line 357. Other notable lines are 248, 136, and 52.
Also I can't load any games. PlayMenuActivity crashes @ Gameprefs.init line 229

Edit: Whoops, my fault.
Title: Re: 3.0 Alpha Testing
Post by: OnijJoku on March 03, 2015, 06:39:51 PM
I don't know if this helps, but the framerate isn't displaying on alpha 19.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on March 04, 2015, 05:10:06 PM
The audio sync is still awful for me on Alpha 19. I tried low and ultra low buffer and disabling/enabling audio sync, but nothing worked. In Banjo-Kazooie, by the time the animation for the standard B-Button move has completed, the sound effect has just started playing.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on March 04, 2015, 05:16:44 PM
Yes, the audio sync is very hit-or-miss for me too.  I don't think any of the audio-sync code was touched between 18 and 19, but it may be impacted by changes in the relative efficiencies of the video/audio/core subsystems as the core is being refactored.  I wasn't going to dig too hard until the dust starts to settle on all the current core work.
Title: Re: 3.0 Alpha Testing
Post by: rafar on March 05, 2015, 09:19:31 AM
I tested alpha 19 few days ago and I noticed better sync sound in mario 64 with glide64, I dont remember if I tested other games. I had noticed too that perfect dark was really laggy with this version.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on March 05, 2015, 10:02:19 AM
I couldnt get perfect dark to run for me although nuclear strike runs now on alpha 19 opposed to alpha 17
Title: Re: 3.0 Alpha Testing
Post by: D-Mac on March 17, 2015, 01:55:55 PM
Great works guys!!!
Title: Re: 3.0 Alpha Testing
Post by: jairolas on March 17, 2015, 02:59:44 PM
OMG, the whole time I thought that this project was abandoned because I read somewhere that Paul decided to grow bananas instead until I found this forum lol
Can't believe how far this emu has advanced, now I can play oot at full speed with full graphics effects on hd, donkey kong 64 now works full speed too and I was surprised to see that there is full moga pocket support, profiles and game covers! amazing :)
The only problem now is the choppy audio that some games have (ssb is one of them), anyhow thanks for your amazing work!

Edit: I been testing Majora's Mask and it runs perfectly at full speed too, some screenshots here https://dl.dropboxusercontent.com/u/77354922/zelda_majora's_mask-018.jpg (https://dl.dropboxusercontent.com/u/77354922/zelda_majora's_mask-018.jpg)
Title: Re: 3.0 Alpha Testing
Post by: rafar on March 18, 2015, 12:55:22 PM
Yes, Majoras mask works perfectly. I noticed few bugs with poligons in Ocarina, and very similar in Mario 64, maybe that bug appears in Majoras Mask too. But it is 100% playable.
Title: Re: 3.0 Alpha Testing
Post by: jairolas on March 18, 2015, 01:38:24 PM
More testing,

Animal Crossing:
Works excellent, it runs full speed without audio problems even the internal clock works.
The only problem is the game menu that looks half broken.
(https://dl.dropboxusercontent.com/u/77354922/4.jpg)
(https://dl.dropboxusercontent.com/u/77354922/3.jpg)

Sin and Punishment:
Works full speed, haven't found any bugs.
(https://dl.dropboxusercontent.com/u/77354922/2.jpg)

Pokémon Stadium 2:
Works perfect in battle, game menus are slow and half broken.
(https://dl.dropboxusercontent.com/u/77354922/1.jpg)

Perfect Dark:
It runs ok, the framerate is a little bit unstable and it has few graphical glitches, I had to use rice accurate video plugin because the default one was kinda slow (but it looked better) but the music plays fine and it's perfectly playable.
(https://dl.dropboxusercontent.com/u/77354922/5.jpg)

Super Mario 64:
Works full speed without glitches as expected, music works fine and textures also work excellent.

(https://dl.dropboxusercontent.com/u/77354922/6.jpg)
Title: Re: 3.0 Alpha Testing
Post by: rafar on March 20, 2015, 12:53:47 PM
I did not test with hd resolutions, the most of games are perfectly playable in spite of the glitches in games as pokemon stadium, or donkey kong which make difficult finish them without playable problems. Other games have irrelevant glitchets as mario 64 which have light problems with shadows and poligons stead. This is similar in Perfect Dark, where you could find problems with green triangles created with flaw poligons. Obviously if you play 2 o 3 minutes is difficult to find all the bugs of a game, but if you play intense every game you could find a lot of them.

I dont want to be ungrateful with the devs who work hardly in this project, they created the best emulator for android, but I hope they try to get  their faith back in this project.
Title: Re: 3.0 Alpha Testing
Post by: retroben on March 20, 2015, 01:43:25 PM
They haven't lost faith,they are just held up and really busy with work and various other personal matters.  ;)
Title: Re: 3.0 Alpha Testing
Post by: jairolas on March 20, 2015, 04:14:18 PM
More games tested,

Mario Tennis 64:

This games works full speed with rice video plugin, unfortunately it has a lot of missing textures and graphical glitches but it plays mostly fine.

(https://dl.dropboxusercontent.com/u/77354922/7.jpg)
(https://dl.dropboxusercontent.com/u/77354922/8.jpg)
(https://dl.dropboxusercontent.com/u/77354922/9.jpg)

Conker's BFD:

This game looks beautiful but it runs slow on my device, I tested this on several resolutions but it didn't make any difference, although disabling music resulted in a few more fps on my device this game couldn't run faster than 23fps with drops below 13fps in overworld areas.

(https://dl.dropboxusercontent.com/u/77354922/10.jpg)
(https://dl.dropboxusercontent.com/u/77354922/11.jpg)
(https://dl.dropboxusercontent.com/u/77354922/12.jpg)
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on March 20, 2015, 04:15:53 PM
More testing,

Animal Crossing:
Works excellent, it runs full speed without audio problems even the internal clock works.
The only problem is the game menu that looks half broken.

I wouldn't go that far the translation patch of Doubutsu no Mori
is a broken mess, it crashes as soon as you enter your house or save in-game.
It won't even load a in-game save you have load a renamed in-game save from Doubutsu no Mori
instead to stop it crashing because of the patched text table.
Sorry to be a party pooper but the hacked rom is far from stable and thats a problem with the hacked rom not
mupen64plusae.
Title: Re: 3.0 Alpha Testing
Post by: jairolas on March 20, 2015, 05:08:50 PM
More testing,

Animal Crossing:
Works excellent, it runs full speed without audio problems even the internal clock works.
The only problem is the game menu that looks half broken.

I wouldn't go that far the translation patch of Doubutsu no Mori
is a broken mess, it crashes as soon as you enter your house or save in-game.
It won't even load a in-game save you have load a renamed in-game save from Doubutsu no Mori
instead to stop it crashing because of the patched text table.
Sorry to be a party pooper but the hacked rom is far from stable and thats a problem with the hacked rom not
mupen64plusae.
Mmm that's kind of strange, I've been playing the game for some time now and everything seems to work just fine, I can save and load and enter/leave any house without any problems even Mr. Resetti works lol. The only problem I've found is the menu being half broken and of course, nes games are not playable.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on March 20, 2015, 09:54:06 PM
There is an unstable and there is a stable version of the translation patch.
Title: Re: 3.0 Alpha Testing
Post by: jairolas on March 21, 2015, 05:12:10 PM
More games tested,

Pokémon Puzzle League:
Doesn't work, black screen. (I only tested a US rom)

Paper Mario 64:
Works excellent with full graphics and full speed.

(https://dl.dropboxusercontent.com/u/77354922/n64/paper%20mario/1.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/paper%20mario/2.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/paper%20mario/3.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/paper%20mario/4.jpg)

Quest 64:
Works full speed, without graphical issues.

(https://dl.dropboxusercontent.com/u/77354922/n64/quest%2064/1.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/quest%2064/2.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/quest%2064/3.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/quest%2064/4.jpg)

Yoshi's Story:
This game works beautiful at 60fps (one of the few n64 that ran at that speed)

(https://dl.dropboxusercontent.com/u/77354922/n64/yoshi/1.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/yoshi/2.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/yoshi/3.jpg)(https://dl.dropboxusercontent.com/u/77354922/n64/yoshi/4.jpg)
Title: Re: 3.0 Alpha Testing
Post by: retroben on March 21, 2015, 09:55:17 PM
Have you seen Jungle Puddle and its water surface?
The main thing that no emulator can get right without an extremely slow software plugin is that water surface rendering.

I hope that Gonetz can figure it out if he hasn't already so GlideN64 can render it correctly.

Edit: Paper Mario does have an issue,the stars talking is invisible on Glide64 while the other plugins have text.
Problem is that the other plugins have horrific display issues of their own,even though the star text is visible.
How do I fix this frustrating annoyance with Glide64?
Title: Re: 3.0 Alpha Testing
Post by: retroben on March 22, 2015, 11:46:56 AM
Gonetz has got the Yoshi Story "Jungle Puddle" water working in GlideN64!
Hopefully it will survive the transfer to Android.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on March 23, 2015, 01:05:42 AM
There is an unstable and there is a stable version of the translation patch.

Care to share? I could only find Zoinkitys NAFE-WIP-2_12_2010 patch
http://www.romhacking.net/translations/1581/
md5: 01BDCC854D0AB798500E7BC31A24D94F

zoinkity mentioned editing
Mupen64.ini to

[01BDCC854D0AB798500E7BC31A24D94F]
Good Name=Animal Forest (U) [t1]
Header Code=0290AEB9-67A3B6C1-C45

I guess the Android eqvilant would be to edit the mupen64plus.ini
to? but I haven't been able to find a text editor on Android that doesn't hang or crash when opening / editing
large text files, same thing happens in notepad on windows so you have to use wordpad instead.

[01BDCC854D0AB798500E7BC31A24D94F]
Good Name=Animal Forest (U) [t1]
CRC=0290AEB9 67A3B6C1-C45
Title: Re: 3.0 Alpha Testing
Post by: D-Mac on March 23, 2015, 10:01:43 AM
Guys know some tricks when you are playing?
Title: Re: 3.0 Alpha Testing
Post by: jairolas on March 23, 2015, 02:38:13 PM
Guys know some tricks when you are playing?
What kind of tricks?
Oh and I didn't play the water level in Yoshi's Story im glad it's working now  :)
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on March 23, 2015, 02:49:29 PM
There is an unstable and there is a stable version of the translation patch.

Care to share? I could only find Zoinkitys NAFE-WIP-2_12_2010 patch
The stable one has very little that's actually translated, the unstable being the one you posted above. It's available on some rom sites.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on March 24, 2015, 01:33:05 AM
Would it be possible to add a aspect ratio option for 3d games so characters / models don't look fat when
the screen scaling is set to stretch / fill screen, as far as I know all widescreen hacks do is take
the ingame height value and multiply it by 1.77777778 to achive 16:9 widescreen for the width.
Title: Re: 3.0 Alpha Testing
Post by: retroben on March 28, 2015, 05:05:44 PM
time bump

For lack of a better reason.  :-\
Title: Re: 3.0 Alpha Testing
Post by: jairolas on March 29, 2015, 02:34:08 PM
So I've been playing some Super Mario 64 but I've noticed that the framerate is a little bit weird, it is full speed at 30fps but it seems like it has frameskip even if it doesn't (I'm using accurate glide plugin not the fast one with  fs) maybe it has something to do with the refresh options? mine are set to automatic but games doesn't really feel smooth.
Title: Re: 3.0 Alpha Testing
Post by: rafar on March 30, 2015, 12:03:38 PM
@jairolas

the most 64 games run at 23 fps. Games like smash bros or yoshi story run at 60 fps. Also cbfd runs at very low framerate... I think that it is 16 fps more less.
Title: Re: 3.0 Alpha Testing
Post by: D-Mac on April 03, 2015, 12:57:02 PM
Guys know some tricks when you are playing?
What kind of tricks?
Oh and I didn't play the water level in Yoshi's Story im glad it's working now  :)

To activate cheats in the game. And not before starting this game.

This emulator has gained much respect to earlier versions. Games like The Legend of Zelda OoT looks much better and more beautiful.

Great job guy!
Title: Re: 3.0 Alpha Testing
Post by: Koemans on April 06, 2015, 12:35:43 PM
I guess i have to chime in here after i had a fantastic night playing super mario 64 last night.


Last year, i bought a moga pro controller so i could play oldskool playstation / nintendo games on my mobile.
However, pretty much all games were completely unplayable.

You see, i have a HTC one mini and i have read on this forum somewhere that some devices with a certain graphic chip just could not run most games smoothly not matter which renderer you would use. I quickly gave up hope and just continued playing snes games and playstation games.


After learning that a new nvidia shield console will be shipping in the USA soon for only 199 dollars, with the option to install emulators from the play store i checked the playstore to see if mupen now have a better optimalisation compared to last year. I was rather dissapointed that it still had a similar version number.

I then checked this forum and i downloaded the alpha. First impression on super mario 64 was good. I mean, before the alpha version there were moments in which the game would run very smooth. but the moment a larger area would be displayed or in which combat would start, the FPS would drop dramaticly. By that i mean, 3 FPS... it would be a challenge alone to stay alive since the controls would lag too.

With the new alpha there are some  FPS drops in certain areas in which a large areas and other effects are displayed (ex : first snow level..) but the controles just feel so much better when there are FPS drops that you can continue playing. Also, before the alpha sometimes the FPS could be as low as 3, but i havent even seen that yet.. well, only in ocarina of time and majora's mask. The area's which used to lag now run with about 100% more FPS.


I tried various roms last night on my HTC one mini..

The good :
Mario 64 - Slight FPS drops in large areas and maps with weather effects but controls still feel reponsive. Definately can be completed.
Yoshi's story - 2 plugin's spawn a whole bunch of graphical artifacts that make the game lag like crazy. Rice's quality setting makes the game run very good but lots of audio cracking. I set the audio output to standard instead of ultra low latency to compensate.
Banjo kazooie - Appears to be the same as mario 64.

The  bad :
Zelda : Ocarina of time - Huge FPS drops in large areas and in combat. Can be completed but i dont like to play laggy games.
Zelda : Majora's mask - Same as above... my HTC almost exploded on this one when i entered clock town for the first time, had about 2 fps for a few seconds. Town people make the FPS drop like crazy. Cutscenes lag too.
Snowboard kids - FPS issues on certain levels in certain area's. Otherwise appear fine and can be finished since the controls no longer lag.
WCW vs NWO revenge - Game appears to run in between 90-100% depending on the action. However, as soon as someone is entering melee range or combat (grabbing / kicking, whatever) starts, the sound starts to crack.


All in all, i am glad i can play a few games now.
Title: Re: 3.0 Alpha Testing
Post by: retroben on April 09, 2015, 12:24:55 AM
Really getting irked.

*insert Fawful quote here*

Would it hurt to pop in occasionally to let us know your'e okay?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on April 09, 2015, 09:18:43 AM
I'm not going to waste any more time on this project until Paul fixes the auto build issues.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on April 09, 2015, 09:55:31 AM
Can't you guys move on with out him? Maybe something did happen to him
Title: Re: 3.0 Alpha Testing
Post by: vamman on April 16, 2015, 10:24:38 PM
Can someone please pull the trigger and do a build of what you guys have? I'm currently doing some asm work on Tegra for NVIDIA at this very moment. Happy to offer some assistance/help.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on April 16, 2015, 11:45:41 PM
Hello, I'm having some strange issues with the nexus player. I can't seem to get the action bar to show up, so there is no way to change settings or scan for games. Is there something obvious I'm missing?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on April 17, 2015, 07:20:20 AM
I'm sorry guys and I feel your pain.  I'm not sure what Paul's status is.  In a pinch, we could build the APK files and post them on Dropbox or whatever.  Or create a different buildbot on our own.  The bigger problem is that without Paul we can't publish updates to Google Play, since he holds the keys to that.  We could always create a new app with a different developer signature, but that is pretty much a "nuclear option" last resort -- not something I want to consider at this point.

In all honesty this is the busiest I have ever been in my day job -- four separate software projects, each for a different client, in different languages, platforms, and APIs:
 - embedded C++ app, using an obscure messaging API, developed in Linux Eclipse, running on ARM Linux SBC
 - C# app, using the Unity (3D) framework, developed in Visual Studio/Unity, running on Windows PC
 - C++/CLI/C# app, using Winforms API, developed in Visual Studio, running on Windows PC
 - C# app, using WPF/Windows Store API, developed in Visual Studio, running on Windows Surface

So you see Mupen64Plus-AE represents a fifth major change of mindset, and can only be done in my free time (which I have almost none of right now).
 - Java/C/C++ app, using Android and Mupen64Plus APIs, developed in Windows Eclipse, running on Android device
Title: Re: 3.0 Alpha Testing
Post by: retroben on April 17, 2015, 12:34:16 PM
Good thing Eclipse is still alive with its new tool called Andmore.

What's your opinion on Android Studio? *quickly runs and hides in a corner comically*
Title: Re: 3.0 Alpha Testing
Post by: littleguy on April 17, 2015, 01:02:17 PM
I looked at Android Studio a month or two ago but was unable to get it working with all our native code.  The NDK support might be there by now, but I was unable to find it.  I'm definitely curious about Android Studio, but it will have to be dead simple to switch over before we consider using for this project.
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v on April 23, 2015, 12:48:49 PM
Hello, I'm having some strange issues with the nexus player. I can't seem to get the action bar to show up, so there is no way to change settings or scan for games. Is there something obvious I'm missing?

Same here. I've tested the APK from first post with the same result and version: master "2015-04-20 16:02" - autobuild.

Don't know, if the attached log, from last mentioned version, shows something useful.

edit: and a screen record
http://youtu.be/ZYiTc1-UK6s
Title: Re: 3.0 Alpha Testing
Post by: retroben on April 23, 2015, 01:19:41 PM
Maybe it has something to do with Intel's branch of Lollipop and/or the new Android runtime?
Perhaps something to do with immersive functionality.
Even though my Intel tablet seemed to run a version of Mupen64Plus AE ok in ART mode,but Kitkat instead of Lollipop.
You'll need the latest Alpha (excluding the one in April 20th) to run Banjo-Tooie and DK64 on a Nexus Player and any other Intel device.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on April 23, 2015, 08:23:33 PM
@scorpio - Stick with Alpha 19 for now - the autobuild versions are experimental, and the ActionBar is one of the things that is being redesigned/replaced in the April 20 build.

One thing you might try doing is to copy/create a new controller profile, and map the menu and/or back buttons.  The menu button should allow you to toggle the ActionBar in the game.  Or are you having an issue with the ActionBar in the front-end screens?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on April 24, 2015, 04:45:38 PM
@scorpio - Stick with Alpha 19 for now - the autobuild versions are experimental, and the ActionBar is one of the things that is being redesigned/replaced in the April 20 build.

One thing you might try doing is to copy/create a new controller profile, and map the menu and/or back buttons.  The menu button should allow you to toggle the ActionBar in the game.  Or are you having an issue with the ActionBar in the front-end screens?

I'm personally having issues with the actionbar at the front-end screen. I looked at scorpio's video and mine doesn't seem to get that far. Also, I'm running the alpha 19 version.
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v on April 25, 2015, 01:04:48 AM
Alpha 19 looks like this on Nexus Player.
Another problem is, the NP remote controller has no menu-button. But that problem seems related to the NP firmware and affects other apps too.
Title: Re: 3.0 Alpha Testing
Post by: BonzaiThePenguin on April 25, 2015, 04:31:39 AM
Can someone test the New-Gallery-UI branch? It has some super-experimental stuff, but it also has a lot of bug fixes and functionality that's missing from the latest master build.

http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on April 25, 2015, 07:47:06 AM
It's beautiful. Only issues I encountered that changing settings from the sidebar doesn't appear to be functional yet (cheats, video plugin etc). And I encountered a crash when exiting a game after the first launch, but I couldn't get a useful log, and it's not happening again.
Title: Re: 3.0 Alpha Testing
Post by: retroben on April 25, 2015, 12:16:51 PM
Yeah I get the same thing,but I can access the video settings.
My no frameskip cheat won't enable,and worst of all,when I select restart game,it auto-resumes on me instead. :(

Edit: Whenever realtime cheat access becomes available,I thought of a great idea on how to fix some codes' response time by utilizing savestate buffering to refresh the RDRAM like when loading a savestate normally,but instead hastily saving one and loading it back immediately to refresh said RDRAM and trigger the code as enabled.
I could always add two codes for enabling and disabling one address as such for my B-T "Fly Anywhere" code which lacks proper activator functionality on Mupen64Plus AE's recompiler due to crippling refresh lag.

Interpreter allows the code to work properly,if there is a way to port whatever instruction that makes it work to the recompiler,could someone please do it when they get the chance?
Title: Re: 3.0 Alpha Testing
Post by: retroben on April 25, 2015, 02:18:19 PM
BAD news,Banjo-Tooie keeps exiting randomly when I try to use the split-up pads at HailFire Peaks' entrance the instant I press the "A" button. :( That really sucks. :(
The app itself is not crashing.
I found the settings menu,and could turn on my normally okay "no frameskip" code,but that can't be the cause of it.

Having no way to avoid auto-resume,I can't restart like I want to for normal testing.

Edit:Cheats are even non-functional from the settings page,I still get the jagged 30fps instead of the enhanced 40-60fps from the cheat.
Other split-up pads are working fine,it may just be the status of the area I get auto-resumed in because the Icy Side's pads worked.

Edit2: Menu navigation layering is bugged when navigating with hardware controls,as it highlights games when the sidebar is active if you hit right.
Title: Re: 3.0 Alpha Testing
Post by: retroben on April 25, 2015, 04:54:29 PM
Conker looks fantastic with Glide now!
It even has the speech bubble's shadow!
I wonder if Banjo-Tooie is also working any better.
I deleted all of my auto-saves so I can at least TRY to test some more stuff.

Edit: My mistake for the video settings I can't change a game's selected plugin profile.
The global menu worked,but a game's menu never lets you access anything directly despite the old menu stuff being in the sidebars "settings" button which is the only one that changes menus.

Damn it! I can't test Banjo-Tooie with Glide because I have Rice set to it with no way of changing to test it.

Edit2: Just tried Banjo-Kazooie with Glide and not looking so good. :(
Random bits and pieces are missing from Banjo and friends during the intro and the honey barns look even worse with the whole body portion going missing at some angles for the one at the first note door area in Gruntilda's Lair.
I had to use 1st person view to look at it directly because of the forced camera angle.
Title: Re: 3.0 Alpha Testing
Post by: retroben on April 27, 2015, 03:35:36 PM
Anybody gonna post? (disregarding littleguy and some others due to GlideN64)

I tried the Audio SLES build and it sounds fantastic! (yes,I changed the plugin in global settings to it)
It has the new UI,but without the sidebar options,so I was able to change settings and enable cheats.

Ran Conker again like I did with the other one,but it even had one issue.
His legs are blue on the low resolution model. (easier to notice when hovering)
I also tried Banjo-Tooie,which had corrupted bits of text. (mostly the letter "I")

Finally,the worst offender,Super Smash Bros.which has many missing polygons,and now some misplaced textures.
Just look at Fox's tail and the Fan item colors,also Link's sword was brown in 1P Mode.
I will try to upload an image or two,if I really need to.
Title: Re: 3.0 Alpha Testing
Post by: BonzaiThePenguin on May 01, 2015, 05:04:52 AM
BAD news,Banjo-Tooie keeps exiting randomly when I try to use the split-up pads at HailFire Peaks' entrance the instant I press the "A" button. :( That really sucks. :(

Random crashes in Banjo-Tooie is unfortunately a known problem. There's almost certainly a bug in the dynarec somewhere but the debugging tools available seemed too limited for a newbie like me to bother giving it a try. Temporarily switching to one of the interpreters to get past the crashing part almost always worked fine for me.
Title: Re: 3.0 Alpha Testing
Post by: BonzaiThePenguin on May 01, 2015, 05:07:49 AM
It's beautiful. Only issues I encountered that changing settings from the sidebar doesn't appear to be functional yet (cheats, video plugin etc). And I encountered a crash when exiting a game after the first launch, but I couldn't get a useful log, and it's not happening again.
Yeah, the sidebar is only partially implemented at the moment, especially the cheats system and controller settings. IIRC you can still access those features through the Settings option, which takes you to the old settings panel.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 01, 2015, 12:47:23 PM
Those menus no longer affect anything in your build.

Gillou's audio-sles build uses the new UI without the extra sidebar parts,and works flawlessly.
I kinda like it better like this.

That Banjo-Tooie issue was caused by the broken game start logic forcing it to auto resume,even if I selected restart.
Something is deeply going wrong with your build internally,sorry. :(

The Glide64 issue is in both builds where textures are wrong in Smash Bros. and others like Banjo-Tooie,yet Conker and DK64 look perfect.
What catastrophe caused those other games to get so bad in these new builds?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 01, 2015, 01:06:01 PM
I am in the process of refactoring some front-end stuff so that it integrates nicer with BonzaiThePenguin's new UI.  When that is finished we can rebase the game-sidebar branch onto master and those regressions should disappear.  Fingers crossed, my schedule might be opening up just a bit to allow me to get back into mental sync with the new UI.

There is a known texture regression in one of the upstream modules (I forget which).  It can be seen in Kirby.  That might be related to the texture issues you're seeing retroben.  You can probably dig through the github issues or the google mailing list for the discussion (I forget where I saw it).
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on May 01, 2015, 01:13:07 PM
In terms of the texture I noticed it also seems to occur with banjo kazooie's font. Some letters are either the wrong letter or a completely out of place texture. A squished letter 'K' is the most common
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 01, 2015, 02:18:35 PM
For me with Banjo-Tooie,the letter 'I' is affected most.
So is upstream is responsible for all of the freaky business with Glide64 or a large chunk related to GLES issues?

Would this also explain the broken Rice screen drawing for Smash Bros. too?
Using another type of the Rice plugin (Mudlord 6.1.4) on PJ64 results in Smash Bros. with a clean view.
But that's a different emulator.

Still find it strange that my x86 tablet's Intel has identical graphic issues to the Qualcomm on FireTV,they look exactly the same despite different architectures and processors.
Maybe the GLES implementation is somehow identical regardless of the architecture or processor,excluding Qualcomm's bad ES 3.0 flaws.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 01, 2015, 02:26:36 PM
Correct, graphical bugs in most cases won't depend on cpu architecture.  Most differences created by arm vs x86 will be emulation/core related stuff (i.e. dynarec).

We are using completely standard upstream plugins for
 - mupen64plus-core
 - mupen64plus-rsp-hle
 - mupen64plus-audio-sdl
 - mupen64plus-video-glide64mk2
 - mupen64plus-video-rice
 - mupen64plus-ui-console

So any issues related to those are best directed to the upstream google groups forum.

The plugins that android edition is responsible for are
 - mupen64plus-video-gln64
 - mupen64plus-input-android
 - mupen64plus-audio-sles
 - SDL2

So any regressions related to those are best directed here on the paulscode forum.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on May 02, 2015, 02:42:18 PM
Probably already mentioned but just incase.
http://filthypants.blogspot.co.uk/2014/12/n64-3-point-texture-filtering-in.html
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 02, 2015, 03:59:43 PM
@Mikhail - You're better off posting on the upstream list, since we are using standard upstream plugins now, and there are many more devs there who are in a position to weigh in.  Gillou may be the only active downstream developer with the skills for it, and he follows the upstream discussions too.
https://groups.google.com/forum/#!forum/mupen64plus
Title: Re: 3.0 Alpha Testing
Post by: gdark100 on May 08, 2015, 07:41:02 AM
On the lastest Alpha, everytime I try to re-scan ROMs at the root of my sd card, the emulator crashes. If I try to scan inside my ROMs directory, it works. Below is the log inside the "CrashLogs" folder.

Spoiler: show

Code: [Select]
Uncaught exception in package org.mupen64plusae.v3.alpha

****MESSAGE****
An error occured while executing doInBackground()

****STACK TRACE****
java.lang.RuntimeException: An error occured while executing doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:299)
at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:273)
at java.util.concurrent.FutureTask.setException(FutureTask.java:124)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:307)
at java.util.concurrent.FutureTask.run(FutureTask.java:137)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:230)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
at java.lang.Thread.run(Thread.java:856)
Caused by: java.lang.NullPointerException
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.getAllFiles(CacheRomInfoTask.java:215)
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.getAllFiles(CacheRomInfoTask.java:218)
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.doInBackground(CacheRomInfoTask.java:118)
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.doInBackground(CacheRomInfoTask.java:52)
at android.os.AsyncTask$2.call(AsyncTask.java:287)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
... 5 more

****LOGCAT****


****DEVICE****
Processor : ARMv7 Processor rev 1 (v7l)
processor : 0
BogoMIPS : 4.80

processor : 1
BogoMIPS : 4.80

Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 1

Hardware : SAMSUNG JANICE
Revision : 000e
Serial : XXXX

Board: montblanc
Brand: samsung
Device: GT-I9070
Display: JZO54K.I9070VJLPD
Host: SEP-119
ID: JZO54K
Manufacturer: samsung
Model: GT-I9070
Product: GT-I9070


****PERIPHERALS****

Device: Virtual
Id: -1
Descriptor: a718a782d34bc767f4689c232d64d527998ea7fd
Class: BUTTON

Device: sec_jack
Id: 1
Descriptor: bda7e7374aba7c80dee4f7f0d239c94d5609e45a
Class: BUTTON

Device: gpio-keys
Id: 7
Descriptor: 485d69228e24f5e46da1598745890b214130dbc4
Class: BUTTON

Device: sec_touchkey
Id: 8
Descriptor: af4d26ea4cdc857cc0f1ed1ed51996db77be1e4d
Class: BUTTON

Device: AB8500 POn(PowerOn) Key
Id: 11
Descriptor: 6ecc9411d15f2f29cc10f7afdeaaacc1773c3bfc
Class: BUTTON
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 08, 2015, 08:43:56 AM
I just noticed that last night too... thanks for the info.
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v on May 10, 2015, 07:13:56 AM
Are there any plans to make the alpha 3.0 ui compatible to Nexus Player / ATV in the next time ?
Would be perfect to have all the new fixes and the gallery on TV.
A gamepad profile for the Asus Nexus Gamepad would be nice too.  :)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 10, 2015, 08:15:06 AM
I thought it was compatible with ATV?  We merged a pull request for this: https://github.com/mupen64plus-ae/mupen64plus-ae/commit/449a1781a677c4dce1289b8d1c9580bcddf40012

If you have the nexus gamepad, please create a custom profile for it, and then post the contents of mupen64plusae-v3-alpha/Profiles/controller.cfg back to this forum.  I'll include it in the next alpha.

I plan to post Alpha 20 once everything is converted to material design.  Seems like a good milestone.  Should happen this week.

Edit: Also, if you have a nexus player/ATV, please go to Help -> Hardware info in the main navigation drawer, and post the text to this forum.  That way we can put the UI in leanback mode by default for anyone with those devices.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 10, 2015, 11:14:55 AM
Yeah,the latest master works perfectly fine on my ATV. (FireTV)
It doesn't even randomly crash after exiting a game anymore.
Title: Re: 3.0 Alpha Testing
Post by: scorpio16v on May 10, 2015, 11:49:18 AM
just downloaded the latest master, retroben mentioned, on nexus player. This version didn't resume to home, like the version I testet before.
One big problem is, that I can only choose and start a game from the gallery, if I use a mouse. I can't access the games and the sidebar menu with the remote controller or gamepad.
In the game, it's impossible to go back to menu, because only the upper statusbar opened. No menu access. So I must kill the app and restart it.

Maybe I'm to stupid, but can't copy/share the hardware info on NP. I can't copy to clipboard or have another option. Only option is to ESfile-Explorer, but it isn't saved anything. Any ideas ?

A short video of the menu problem:
http://youtu.be/Ue5wrsq3Qz4
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 10, 2015, 12:26:53 PM
Thanks scorpio.  I noticed that too that controllers don't work to select a game.  I'll put that high on the priority list to fix.  There are a lot of growing pains with such a big UI overhaul and it's easy to forget about some of the edge cases.  Thanks for the controller profile. :)
Title: Re: 3.0 Alpha Testing
Post by: Paul on May 13, 2015, 06:49:22 AM
I'm taking a look at the cheats system.  Any other smallish things I should look at to start getting more familiar with all the changes?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 13, 2015, 06:56:47 AM
I'd say the biggest fundamental change since 2.x is the new profiles system.  Of course the gallery and nav drawer are all brand new as well.  I'll probably move a few things out of the GamePrefsActivity into the game-specific nav drawer, like the wiki link and the multi-player mapping.

Regarding material design, all activities use it now except for Game*Activity.  I have a branch in my personal fork that has some WIP for that.  When that's complete I'll switch all the alert dialogs to material design and we should be done with that.  The only thing holding me back from merging to master is a few corner cases with the action bar for Gingerbread devices and/or devices with menu hard key.

The number of java classes has ballooned for version 3, and I'm not terribly excited about that.  I've tried my best to define sensical subpackages to keep things a bit more organized.  I'm sure there are more places we can refactor to clean things up.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 13, 2015, 06:41:34 PM
@Paul: A good example for how useful Dual Async could be is trying to play SM64 hacks like Shining Stars 2: Mirror Madness.
Course 6 alone is immensely slow while many other areas slow to a crawl with painful stuttering also on SLES and even make the emulator performance judder like crazy,especially with frameskip set to "no more than 5" mode.
Glide64 is not so bad,but just try playing it with glN64 and it might even bring you to tears.

The 1st "Bowser" stage (a monochromatic maze) is so bad it eventually can corrupt the audio and get insane judders.
That is probably because of the massive amount of objects and level size.
(This SM64 hack is also a fine example of why we need at least VI Refresh Rate added.)

Yeah,I know this is a romhack of SM64,but these are always really interesting and fun.
Title: Re: 3.0 Alpha Testing
Post by: Paul on May 13, 2015, 07:42:59 PM
@Paul: A good example for how useful Dual Async could be is trying to play SM64 hacks like Shining Stars 2: Mirror Madness.

The benefits of adjusting audio to match the core speed are obvious -- I don't need convincing :)
I don't really recognize "Dual Async" as an audio algorithm or library, though -- guessing the term is specific to whatever emulator or app you saw that setting in?  Do you have any links related to this?

Anyway, I know of several libraries for changing the tempo of audio output without affecting the pitch.  I was thinking of using one called "Rubber Band" which is probably one of the best open-source libraries for adjusting audio tempo and pitch independently.  I would need to make sure it is light-weight enough for use in the app, of course.

From what I can tell (although I haven't looked at it too closely yet), the existing resampling component of the audio plugins only takes into account what the frequency is supposed to be for the game, and doesn't apply any adjustments for lag.  It also appears to only be designed to initially scale both tempo and pitch to the output format.  Something like Rubber Band would allow you to adjust the tempo and pitch independently, and could be used to scale both for an initial base-line and at the same time to dynamically adjust the just tempo based on the core speed to compensate for lag.

The main unknown I'd need to figure out is how to get a metric from the audio plugin code of the actual core speed compared to what it should be -- without having to add a hack to the core for counting cycles like I was doing for the net-play experiments.  There may be something I missed in the Mupen64Plus API related to this.  I'll ping the upstream devs before I tackle the problem.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 13, 2015, 08:18:05 PM
Awesome.  I know there was some recent upstream discussion about possibly consolidating some of the resampling functionality into a common location.  Perhaps some of these ideas could be inserted into that discussion.
https://github.com/mupen64plus/mupen64plus-core/pull/79
https://github.com/mupen64plus/mupen64plus-ui-console/pull/19

Also, there has been some upstream work on netplay in case you missed it:
https://github.com/mupen64plus/mupen64plus-core/issues/112
Title: Re: 3.0 Alpha Testing
Post by: Paul on May 14, 2015, 06:48:41 AM
I hadn't seen the netplay discussion yet.  ymartel06's commit is a little hard to read as it included a lot of code reformatting (makes it difficult to pull out the important changes).  I'll have to look at it more closely when I have a chance.
Title: Re: 3.0 Alpha Testing
Post by: motawa on May 19, 2015, 11:34:40 AM
can you please bring back the octagonal joystick limits optins and add rom shortcut option for homescreen?
Title: Re: 3.0 Alpha Testing
Post by: ofm05 on May 19, 2015, 06:53:07 PM
Might sound silly, but how do I start a game on alpha 19?

I load the rom and then what? Sorry I just cant figure it our
Title: Re: 3.0 Alpha Testing
Post by: mrbluru on May 20, 2015, 10:33:50 AM
Since updating my n910f Note 4 to Lollipop 5.0.1, Glide 64 gives me weird missing/glitch textures on any of the Alpha builds
Here is an example from Banjo Tooie
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 20, 2015, 12:55:40 PM
So Lollipop has claimed another victim,but with this.
I get minor polygon issues with Glide64 on "custom" 4.2.2 JellyBean with FireTV,and an identical polygon issue on 4.4.4 Kitkat with my x86 Tablet.

Hopefully the Android distributors can update again to a bugfix update for your device.

Rice is a bit faster for Banjo-Tooie,but you got to make sure settings are right to prevent glitchy frame rendering.
Changing the type to "First CI Image" completely stops the glitch,but disables the dynamic shadow while "VI Refresh Change" or "VI Refresh Update" makes the dynamic shadow work with minor consequences of broken frame visuals while pausing emulation via mapped button/hotkey.

Do you know of my 60fps Banjo-Tooie code? "No Frameskip" 8007913F 0001
It doesn't always go full 60fps when CountPerOp is 0 or 2 but 1 can have a few cutscene softlock issues.
But it can still get really smooth on default and improve your experience.
Using 1 is best when the game is beaten and you just wanna mess around.
(and if your device is strong enough to maintain performance)

*epiphany* I just found a reason to add VI Refresh Rate overclocking support! :)

Because of the rendering glitch on Rice,I realized it is similar to the behaviour of choppy
framerates when VI Refresh Rate is the default of 1500.
On PJ64,I had to set it to 2200 in order to fix the choppy framerate when my code was enabled and CF=1 too.

So my reason why we need this option (exists in libretro's Mupen64Plus core on Android,so maybe source port capable) is because somes games may become extra-taxing on the emulator and it needs the extra 700 refresh rate to keep things smooth.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 21, 2015, 03:14:43 PM
Important realization has been made im accordance to lack of code functionality. ;D

What I said in the ShoutBox to preserve it:

I found out why some codes are just not working as intended!
First,I was using my lighting intensity code...

Lighting Intensity (D-pad directions)
D1081084 0800
8110E446 4B80
D1081084 0400
8110E446 C480
D1081084 0200
8110E446 3F80
D1081084 0100
8110E446 4280
Use d-pad to change Banjo and some enemies lighting intensity,works on Pure Interpreter in realtime.

On Dynarec,it obviously fails,while Pure Interpreter works dead-on instantly.
The thing is,I tried Cached Interpreter,lo and behold the code does not work.
Interestingly enough,exiting and switching back to Pure Interpreter makes my lighting change on resume,which means the value is being changed properly while not being read correctly.
So I deduced this to being the issue,and I assume Dynarec is using a "Cached" method and thus breaking code functionality after the boot sequence,and the solution is to make "Pure" Dynarec available as an alternative option.
Cached Interpreter runs slower (30/60fps compared to Pure's 40/60fps on the title seqeunce
both with "no frameskip" code enabled) than Pure interpreter anyway,so maybe Pure Dynarec is faster.

I finally found out about the cause of the issue,and I really want this.
So,who can apply this change for Dynarec so that all activator codes can finally be fully functional on Mupen64Plus AE?
Please,please,PLEASE!,someone do this! I'm begging you! :'( I would be so happy about this. :)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 21, 2015, 05:09:55 PM
@retroben Great diagnosis :D

This is out of my league but Gilles might be up for it.  I wonder if the same issue affects the PC version of mupen64plus.  If so, then there's a lot better chance that the cached interpreter can be fixed (multiple devs with the skills).  And if the flaw in the cached interpreter is fixed, then it might provide a clue for the dynarec.  (Or maybe not.  They both cache instructions, but not necessarily in the same way or at the same level of abstraction.)
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 21, 2015, 06:03:46 PM
I was actually kinda going for a non-cached dynarec. ;)
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 21, 2015, 07:00:58 PM
I think by definition that doesn't exist ;)  The very nature of dynamically recompiling machine code requires you to cache results.  Otherwise you'll just have a slide show. ;D
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 21, 2015, 08:16:36 PM
Then why does Pure Interpreter run identical speed (or even better) than Cached Interpreter? :o

The Pure Interpreter does not run all that slow considering it runs decent on the limited Android OS.

It makes me wonder,what business does PJ64's Recompiler have running under the hood?
A good question to ask zilmar or the other devs about on their forum. :D

I already knew that activator codes worked better on Mupen64Plus AE's Pure Interpreter,but it was recent when I figured out approximately why they fail on the other two choices.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 21, 2015, 08:19:37 PM
Then why does Pure Interpreter run identical speed (or even better) than Cached Interpreter? :o

Very good question indeed.  This might be worth posting to the upstream forum.  Your experiences suggests that (at least in this particular situation) the overhead of caching is actually more expensive than recomputing stuff every time.  Very odd result indeed.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 21, 2015, 09:14:34 PM
At least on Android OS since caching is slower in some cases,especially for outdated Qualcomm drivers like my FireTV's.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 23, 2015, 12:29:16 AM
More things to think on.
What is all being cached on the dynarec?

Excluding performance,what's the purpose of caching all of the RDRAM when you could just read from it directly?
For example,Banjo-Tooie with a chunk of RDRAM from around 80090000-80120000 is unchanging values.
This chunk can be read and yet my codes based on this location fail to work with activators but are still being written.
Since this location is needlessly cached,the toggled code is never read and thus does not function since the cached data is from the boot sequence and not altered like the original copy and is the one being read from.

If you haven't already,I will try to make a post on the upstream Google Groups site to see what they think.

Edit: About the performance,I tried a comparison with Conker's Bad Fur Day and Pure Interpreter is faster than Cached Interpreter on that game as well.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 23, 2015, 02:01:19 PM
(That's what overclocking could be used for!)

Just thought of something,what about non-cached recompiler with alternate overclocking to give it all of the extra needed Mhz to run at top speeds?
Maybe even segregating Mhz (if even possible/please be possible) to 100Mhz normal running and a large extra chunk like 400-600Mhz used by the thousands of instruction calls so that they can be called at maximum force!
(Of course both on the same CPU core.)

Sure this means using extra battery,but it is a trade-off for scary good performance and closer to "accurate" emulation since no cached instructions.
All of the Android devices nowadays have at the very least 1.0Ghz,mediums of 1.5-1.7Ghz and powerful ones with 2.0+Ghz so it would be very easily accomplished.

If none of this can even conceptually work,then a fellow can dream. :(

Edit: But,if at least I can get some info from PJ64 devs,maybe it will be possible to import some functions from their Dynarec's source code so activator codes can all work properly.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 23, 2015, 09:55:28 PM
What is all being cached on the dynarec?
Excluding performance,what's the purpose of caching all of the RDRAM when you could just read from it directly?

It's not RAM that's being cached.  It's the instruction translations.

Here is an analogy.  You speak English (ARM).  The original N64 instructions (i.e. the info stored in the cartridge) are in Spanish (MIPS).  The pure interpreter uses a spanish-to-english dictionary.  Every time it sees a sentence in Spanish (MIPS), it looks up every word in the dictionary and converts it to English (ARM).  Then it reads the sentences (instructions) in English to the hardware to perform the task.

Cached interpreter works almost the same way, but every time it translates a new word, it writes the translation down on a one-page "cheat sheet".  Then whenever it translates the instructions from Spanish (MIPS) to English (ARM) it looks at the cheat sheet first (which is very easy to search) before looking in the full dictionary (which takes a lot longer).  Most of the time, most of the words in the original Spanish (MIPS) instructions are already in the cheat sheet, so the cheat sheet makes the translation process go more quickly.

Dynarec works on a higher level.  Instead of reading a sentence and translating it word for word using a dictionary, it instead understands whole phrases in Spanish, and converts the whole phrase to an equivalent phrase in English.  So where the pure interpreter would translate Spanish "de nada" to English "of nothing", the dynarec translates "de nada" to English "you're welcome" because in a particular context that's actually what "de nada" means at a high level.  The problem is that it takes a lot more up-front effort to translate things by phrase (dynarec) than by word (interpreter) because understanding the context is difficult.  So the dynarec will always need to cache the most common phrase translations, in order for it to pay off.  In practice, there aren't that many phrases to translate in most games, the phrases can be cached, and the up-front cost of translating by phrase pays off because the resulting translations are much easier for the hardware to understand.

So, as William Shipley said in the upstream forum, it would never make sense not to cache the phrase translations that the dynarec performs.  If you didn't cache them, it would be faster to just use a pure interpreter.

All that said, it is always good to isolate which mode (pure intepreter, cached interpreter, and dynarec) the bug occurs in.  Every bit of information from testers is valuable.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 23, 2015, 11:11:19 PM
Aren't the instructions placed in RDRAM?

What I was about to post before re-reading your comment. :(

Code: [Select]
So the optimization route is the only way to go by making it detect the changes a cheat code makes and writing it to the respective place in the cache instead of outright ignoring the change.

One smart way to do this is to take the addresses of enabled cheats and set them to a "watchlist" that allows real time changes to be completely effective by sending them to their matching cache address in realtime and allowing cheats with activators to be fully functional like my example code would do.
Maybe a seperate process can be made in a non-used core to do this function to eliminate any chance of performance loss.

I was told to use the IRC on the PJ64 forum to try to get help from anyone like zilmar,but I can't really grasp how to begin.
If it can be figured out,you could possibly get PJ64's method of handling the more troublesome GS cheats on Recompiler.

A different thought,maybe there can be another approach that reacts to enabled cheats for addresses that are cached and results in forcing an additional write to the equivalent cached addresses.
*ingenius* Or skipping the whole step and writing directly into cache if the address is in that range.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 24, 2015, 12:52:17 AM
Then there is only one viable solution...
We need to find out and implement the function that PJ64's recompiler uses to make all GS codes with activators work.

Just need contact with zilmar to see if he would like to send us in the right direction.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 27, 2015, 01:36:45 PM
Trying to call this to attention again...

Is there a way to fix the issue where rendering has that ugly dot-matrix visual on the game's screen?

I finally decided to upload n image to show this issue as seen in DK64 while all other games also have the ugly dot-matrix filling the screen.

http://www.2shared.com/photo/a_nd8stU/donkey_kong_64-001.html

The blue from the water makes this stick out like a sore thumb,and even DK has it on him.
It is not caused by the water itself,I have seen it in other games away from water,just easier to point out this way.
I recommend using Perfect Viewer to look at the fullsize image at its native resolution.
If you can't see it,look really close and it should be visible.
And if you have a 1080P or better HDTV,and a way to display it on that HD screen,look at it that way as well.
(I am sure Nvidia includes a proper HDMI wire for their BEAST of a Shield tablet for use on a large TV screen)

I really wanna see the visual quality become crystal clear,I hope there is a simple fix for this.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on May 27, 2015, 06:12:25 PM
That would be the dithering. It's used more in older games, especially on the PSX. I don't know how feasible it would be to disable it.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 27, 2015, 09:44:48 PM
Just tried DK64 in a computer on PJ64 (1.7.0.50b23) and I can't see ANY dithering on it. ;D

I can upload a screencap of it if you wanna see what I saw.

Edit: I think its a problem with Android rendering since even some image viewers have dithering on the renderer.
(for example looking at a sharp picture with a lot of orange in it)
It should not be too difficult to find a fix for.

Edit2: Tried an instance in all three emulators I can run on PC.
PJ64,1964,and Mupen64++ with none of them having the dithering.

Edit3: Here is another one I took a while ago on Android,it really points out the dots on the whiter spot.

http://www.2shared.com/photo/2zeuoG3c/banjo_tooie-005.html
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 28, 2015, 02:25:55 PM
I still have that PC image if you want to look at the difference of no dithering on PJ64.
I can still see the dithering of Mupen64Plus AE on GLideN64 with 5xBRZ enhancement. :'(

Meanwhile,I was intrigued by something about ARM assembly/ASM coding...
It is said to run 30x faster than some of the best C code. 8)

How fast would Mupen64Plus AE be if it took full advantage of ARM assembly/ASM code?
(could also make Peach's Christmas Invitation run without crashing and run much faster)
It could even end up running much faster for old low-spec devices.

How fast could the Pure Interpreter run if it adopted Hatcat's fast interpreter method and additionally took full advantage of ARM assembly code?
(interpreter is much easier to port than a recompiler)

Getting Mupen64Plus AE to work with ASM code may bring it to a superb performance on lower end devices. ;D

It turns out that NEON is assembly related and works even faster than standard ARMv7 based assembly!

Here is the awesome page I am reading from that shows detailed results of performance gains...
(despite unfairly using Iphone for an example test :'( )

Stupid Opera Browser leaving out required "hyper transport text protocol" letters.

http://shervinemami.info/armAssembly.html

Speed comparison at the bottom of the page.
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on May 28, 2015, 05:50:59 PM
That dithering appears to be done by your device's GPU, not the app. Nothing like that on my Shield Tab. Using GlideN64-3.0.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 28, 2015, 10:47:30 PM
Errybody's got a shield except me. *comically sad crying face*
What game,where did you go in it,and can you get a screenshot so I can inspect it closely on Perfect Viewer in comparison to mine?

Preferably in the underwater DK Isles spot on DK64 using Glide64mk2 and native resolution with scale set to none.
A lot to ask,but it would be extra helpful so I can see it within the same Polaroid 1080P HDTV.

What about any other plugin,unfair to choose one I can't access. :(
I can confirm seeing dither in Rice and Glide64. (Banjo-Tooie and DK64 respectively)

I wonder if even the most powerful devices are unwittingly set to 24bit color like my FireTV's default is.
I am running in 32bit colors mode thanks to root access and Kernel Tuner,and it looks so much sharper.

Edit: I used "Pimp My Rom" to check the settings and dithering is disabled while a few other non-related features are seen enabled proving no read errors.

Edit2: I added the build prop function for dithering and set it to 0 then rebooted,and it still shows up on AE.
I noticed some minor visual differences on this site with that change though.
Is there any way to force the disabling of dither in Mupen64Plus AE so all devices can have crystal clear visuals?

I would say it is the GameSurface part using dithering,and I want to disable that dither. :P
Title: Re: 3.0 Alpha Testing
Post by: xperia64 on May 29, 2015, 09:24:54 AM
Glide64mk2: http://i.imgur.com/mqGCVep.png

I think I remember some dithering on my older adreno devices like the xperia play.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 29, 2015, 10:17:16 AM
Darn,so I have yet another reason to say Qualcomm sucks. >:( :'(
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 29, 2015, 06:17:51 PM
What da heck is going on? :o

I ran Goat Simulator on FireTV (Google Play installed) and there is no longer ANY of the extra ugly dithering it had,and it looks crystal clear. ;D

Why must Mupen64Plus AE refuse to be clear for me even after all this
with Goat Simulator now looking crystal clear? :(

Is there any other way of rendering the video that kills off all chances of dithering?
I did have a dither-free Banjo-Tooie at least once a few months ago,but I don't know how the heck it managed to happen.
(an image viewer gave me dithering until I set it to fullscreen,which fixed it somehow)
It may have been something to do with enabling fullscreen,can I force fullscreen render mode to always be enabled?

Edit: Used Rice on DK64 with working blue water color and in fullscreen then,BAM! No dithering!!! ;D ;D ;D

Why is Glide64mk2 forcing dithering on for me?
That really sucks because it has the best for performance on DK64 and some other games.
Dithering is said to "improve ::) " quality but cause performance loss.

I found two dither settings set to "-1" on Glide64,what numbers do I use to force them to be disabled?

Edit2: Rice actually still has some dithering left on Banjo-Tooie,but is less noticable though.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 30, 2015, 02:32:56 AM
Can somebody please help me fix this issue with Glide64mk2 dithering?
I've tried setting alpha dithering to 0 and changing stipple modes and the stipple pattern,but nothing remedies the problem.

Both game specific and the Android/data .ini file's stipple including the pattern number.
Still need to know how to get proper fullscreen working since the setting reverts to "False" every time,and no,I don't mean immersive mode.

Rice still does look a lot better with same clean water,but performance is slower than Glide64 on DK64.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 31, 2015, 11:20:42 AM
I have a theory,a gam- ...

I think it has something to do with scaling and "native" resolution versus real native resolution.
From the 1080p screen,it has square gridding much like some older gif player with any non-dithering gif.
If you want to,try to get my ditherless user image gif and view it in an older gif viewer for android. (unless it uses forced dithering on that viewer)

Maybe there is an alternate way to make it scale that doesn't allow square gridding while possibly gaining a few fps of performance.

I still wish to get a less obscure detail than Mikhail's of what manifest to edit with android:dither="false" command.
I can't even view xml files properly on Android,I guess I need to use the computer to read a copy,change the value,get the copy onto the device,and then overwrite the original.
But from what app in root directory?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 31, 2015, 12:56:58 PM
Post a savefile so we can jump right to the part in the scene that's dithered.  If I can reproduce the issue on one of my devices, I'll take a closer look.

Also, what do you mean by fullscreen, if not immersive mode?  Are you editing the mupen config file manually?  If so, which settings?  Just need all the info in order to help.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on May 31, 2015, 01:54:16 PM
I have a theory,a gam- ...

I think it has something to do with scaling and "native" resolution versus real native resolution.
From the 1080p screen,it has square gridding much like some older gif player with any non-dithering gif.
If you want to,try to get my ditherless user image gif and view it in an older gif viewer for android. (unless it uses forced dithering on that viewer)

Maybe there is an alternate way to make it scale that doesn't allow square gridding while possibly gaining a few fps of performance.

I still wish to get a less obscure detail than Mikhail's of what manifest to edit with android:dither="false" command.
I can't even view xml files properly on Android,I guess I need to use the computer to read a copy,change the value,get the copy onto the device,and then overwrite the original.
But from what app in root directory?

The AndroidManifest.xml within the apk, rename .apk to .zip and you'll see it.

http://forum.xda-developers.com/showthread.php?t=2493107

It's been a while since I edited a apk but I believe I used the above tool in the past.
Also have some command prompt / batch commands for extracting apks and repacking / resigning them which is quicker for small edits, I'll try and find them on my comp tommorow for you.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 31, 2015, 02:23:12 PM
So you meant the Mupen64Plus AE apk file?
Thanks for being so helpful to me. ;D *tear slips out*
I still need to use a computer since Android confoundly lacks proper xml viewing support. :(
Can't you just as easily set this as default in the manifest so quality can be fixed?

I found something rather intriguing though.
When I tried Retroarch for Android on the same moment (DK64 DK Isles underwater in front of K. Rools lair),it does not even show a sign of dither and it looks perfect despite missing skybox color.
I even used both 640x480 and 1920x1440 resolutions and even took screenshots.

I got a VERY interesting result!
The Retroarch Android screenshots look EXACTLY identical to my PJ64 screenshots with Glide64 with no dithering yet with missing color depth of actual visuals.
The one I uploaded was a print screeen of PJ64 so I could keep all colors seen on the image.
Why is it so dumb by not keeping all colors as it should?
I may try to use an external screenshot tool if possible on Android,wish me luck.

Somehow Glide64 on Retroarch for Android looks exactly identical to how GLideN64 acts with polygon offsets.
You can see some stuff through walls,Banjo-Tooie is missing dynamic shadow and has a rectangle instead while paths are seen through Jinjo houses.

(it must be something to do with Mupen64Plus AE itself and how it reacts unfairly to some devices)
Either that or Retroarch for Android's manifest has dither set to false already?
If it does,then that should be what Mupen64Plus AE does.

I wonder,where did Retroarch port Mupen64Plus from,particularly where for use on Android?

... What? ... What!
OKAY OKAY,I will try to upload a savestate soon. :D
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 31, 2015, 02:43:59 PM
@retroben I just made a branch to test Mikhail's manifest fix.  It will show up on the auto-builds page under the "test-dither" category when the next hour rolls over.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 31, 2015, 02:56:43 PM
Great. Thanks! ;D

Here is a user savestate for DK64 (U)...

http://www.2shared.com/file/wQnrvWMe/ow_the_edge.html

I put it where it gets REALLY bad on Glide64.

I also already got a screenshot from Retroarch for Android without any dither on their Glide64 plugin.
I wonder if theirs is actually the normal Glide64 instead of the mk2 version?
Let me know if you want the screenshot as well.
It even shows evidence of the Retropad overlay and my FireTV's orange mouse circle/cursor.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 31, 2015, 03:03:01 PM
RetroArch has evolved so much it's hard to say what came from what.  I believe they started roughly with mupen64plus-ae though (before it was fully merged back upstream).

Edit: Oops it looks like it takes an extra full hour for the autobuild script to start building new branches.  This hour it discovered the branch.  Next hour it will build the branch :(
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 31, 2015, 03:43:38 PM
I'm stuck on my daily routine of GS code making anyway,and I can't as easily test it.

Does Logitech F310 Gamepad work well with Mupen64Plus AE,I am thinking about hopefully nabbing one successfully while at Walmart tomorrow (secrecy) and I was wondering if it has been confirmed good for the emulator.
It already reaches out to Android TV users and FireTV is more or less a type of Android TV.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on May 31, 2015, 04:04:04 PM
I have a 710 and it works fine (wireless dongle attached to USB OTG adapter).  I would expect the 310 to be just as compatible.
Title: Re: 3.0 Alpha Testing
Post by: retroben on May 31, 2015, 10:58:45 PM
Darn,still see the dithering.
I tried the fourth build of that branch and it still shows up. :(
And all after you did all this work just to attempt to fix said issue. :-\
I still think it could be something else in the game surface code that acts different on every device for things like DPI.
(my DPI is 320)

Then what is it doing to cause this when Retroarch doesn't have it at all?
Maybe they will be nice enough to let you look at their screen render source to see how theirs does things.
Possibly the different surface type or condition has the necessary part for dither-free visuals.
Couldn't hurt to check.

Edit:I just took a screenshot with Glide64 of DK64 in water in a less recent GLideN64 build on my x86 tablet (not the dither fix branch) and transferred it to my FireTV for viewing.
Upon viewing it,it looks a lot better than the results ON FireTV because the squares are a LOT smaller which means Mupen64PlusAE is treating FireTV wrong by making the squares massive compared to other devices.
Maybe it is OS version/custom differences related.

How do you change the behaviour of this to make the squares smaller though?
But the goal is to completely remove the squares so game visuals can look perfect.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 01, 2015, 12:38:50 AM
Here is a more realistic view of dither from smaller resolution zoomed to fit the screen...

http://www.2shared.com/photo/U8JuNPhz/donkey_kong_64-001.html

I used the smallest resolution to get the well-known dithering like Sega Genesis games.
This screenshot was taken with the dither fix build.
Dithering is like what Sonic 3 & Knuckles looks like normally and in GensPlusDroid with a pixel pattern.
In my native 1080P resolution,I get larger squares instead of pixel sized...umm well,pixels.

I do still see the same other thing in native resolution which is not your typical dithering.

I think I have a better theory,dithering is when something is downsampled from a larger size,thus it is being treated as if the game was originally 1080P and downsampled to what it really is.
So what you may need is to make it treat it as if it was being upsampled or untouched.
Maybe this whole time it has been a form of scanlines and nothing directly to do with dithering?

I don't know what it truly is,but hopefully one of these assumptions are correct.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 01, 2015, 04:20:05 PM
Nabbed the Logitech F310 Gamepad,and set it up...
It works really well and even has working navigation control by default for FireTV's home launcher!

I admit I am jealous of anyone with a Smash4 edition Gamecube controller.
Patrick Star: I'd KILL for a net like that. (net=gamepad)

I think the issue may have nothing to do with dither and it is either scaling commands,or something else mysterious.
Retroarch's scaling can cause performance loss while Mupen64Plus AE has no performance impact whatsoever between 1080P and the smallest resolution. (no performance increase from smaller resolutions either :( )
If you were to do something similar to how Retroarch does it,the smallest resolution could cause a stronger performance increase while larger resolutions could cause a small slowdown.

Then again,other devices don't seem to have this issue,so woe is me. :(
Sorry for making you waste time on this problem. :-\
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 02, 2015, 04:20:36 PM
Anyone PLEASE respond!!!

Sorry,couldn't resist making it the most noticable.

I found the main cause of the issue,it is what the plugins are doing that's causing the visuals to look bad on my end.
I figured it out when the changes on GLideN64 got rid of the same ugly visual that Glide64mk2 has in DK64's water and more importantly the squares Rice has on Banjo-Tooie (noticable in some close-up wall views).
Even the least affected Rice is now beaten out by GLideN64's view method which does NOT have the squares issue.

So,whatever GLideN64 is doing for the screen view in Gonetz's most recent apk is what is needed on the other plugins.
You may have to ask him about the changes.

I set my build.prop to dither=1 then reset,and it still looks the same.
Perfect screen view on GLideN64 while Rice has squares (noticable on close-ups) and Glide64mk2 has the whole screen engulfed in ugly scanlined squares.

This is recent with GLideN64 (GLES2) obtaining the perfect screen view specifically in that apk.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on June 02, 2015, 09:07:58 PM
@retroben Please post the logcat for each plugin so I can compare.  The best way to do it is
 - Open mupen, start game, wait for graphics, then quit to gallery
 - In gallery open global nav drawer, select About -> Logcat then click share

In particular I'm looking for messages about the GL context creation process after the emulator launches.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 02, 2015, 09:34:56 PM
I have a dilemma,my FireTV doesn't write into Mupen's logcat for some reason. :(
Normal logcat apps can read from it,but can make things a bit more tedious.

I guess I will have to make it through that and upload some text files.
Or maybe even copy and paste a small portion inside a codebox that I believe to be the difference.

Edit: I had to run GLideN64 shorter because some other annoying audio log data kept overflowing it.

Glide64mk2 run:
Code: [Select]
I/Core    (23684): Goodname: Donkey Kong 64 (U) [!]
I/Core    (23684): Name: DONKEY KONG 64     
I/Core    (23684): MD5: 9EC41ABF2519FC386CADD0731F6E868C
I/Core    (23684): CRC: EC58EABF AD7C7169
I/Core    (23684): Imagetype: .z64 (native)
I/Core    (23684): Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
I/Core    (23684): Version: 1449
I/Core    (23684): Manufacturer: Nintendo
I/Core    (23684): Country: USA
D/UI-Console(23684): Cheat codes disabled.
I/UI-Console(23684): using Video plugin: 'Glide64mk2 Video Plugin' v2.5.0
I/UI-Console(23684): using Audio plugin: 'Mupen64Plus OpenSLES Audio Plugin' v2.0.0
I/UI-Console(23684): using Input plugin: 'Mupen64Plus Android Input Plugin' v1.0.0
I/UI-Console(23684): using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.5.0
I/Video   (23684): opening /storage/emulated/0/Android/data/org.mupen64plusae.v3.alpha/Glide64mk2.ini
I/Video   (23684): Using TEXUMA extension.
I/Core    (23684): Setting video mode: 1440x1080
I/GameSurface(23684): Creating GL context
V/GameSurface(23684): Found EGL display connection
V/GameSurface(23684): Initialized EGL display connection
V/GameSurface(23684): Found compatible EGL frame buffer configuration
V/GameSurface(23684): Created EGL rendering context
V/GameSurface(23684): Created EGL window surface
V/GameSurface(23684): Bound EGL rendering context to EGL window surface
I/GameSurface(23684): Created GL context OpenGL ES 3.0 V@14.0 AU@04.02.02.073.175 PDAVID_AU_LINUX_ANDROID_JB_2.5.4.04.02.02.073.175+PATCH[ES]_msm8960_JB_2.5.4_CL3406509_release_ENGG (CL@3406509)
I/Video   (23684): Your video card doesn't support GL_ARB_texture_env_combine extension
I/Video   (23684): Your video card doesn't support GL_ARB_multitexture extension
I/Video   (23684): Your video card doesn't support GL_ARB_texture_mirrored_repeat extension
I/Video   (23684): use_fbo 1
W/Adreno200-ES20(23684): <core_glTexImage2D:478>: GL_INVALID_VALUE
I/Video   (23684): InitCombine()
I/Video   (23684): extensions
I/Video   (23684): initialized.
I/Video   (23684):
I/Core    (23684): Starting R4300 emulator: Dynamic Recompiler
I/Core    (23684): Init new dynarec
I/Core    (23684): ARM CPU Features: SWP, Half, Thumb, FastMult, VFP, ESDP, NEON, VFPv3, TLS, VFPv4, IDIVa, IDIVt
D/WindowManager(  654): Send Logs not enabled!
I/GameLifecycleHandler(23684): onWindowFocusChanged: false
I/GameLifecycleHandler(23684): onPause
D/Core    (23684): Emulation paused.
I/GameLifecycleHandler(23684): surfaceDestroyed
D/Core    (23684): Stopping emulation.
D/Core    (23684): Saved state to: yyyy-mm-dd-hh-mm-ss.sav
I/Core    (23684): R4300 emulator finished.
I/GameSurface(23684): Destroying GL context
V/GameSurface(23684): Unbound EGL rendering context from EGL window surface
V/GameSurface(23684): Destroyed EGL window surface
V/GameSurface(23684): Destroyed EGL rendering context
V/GameSurface(23684): Terminated EGL display connection
D/Core    (23684): Rom closed.
I/ae-bridge(23684): Unloading native libraries
I/GameLifecycleHandler(23684): onStop
I/GameLifecycleHandler(23684): onDestroy

GLideN64 run:
Code: [Select]
I/Core    (10179): Goodname: Donkey Kong 64 (U) [!]
I/Core    (10179): Name: DONKEY KONG 64     
I/Core    (10179): MD5: 9EC41ABF2519FC386CADD0731F6E868C
I/Core    (10179): CRC: EC58EABF AD7C7169
I/Core    (10179): Imagetype: .z64 (native)
I/Core    (10179): Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
I/Core    (10179): Version: 1449
I/Core    (10179): Manufacturer: Nintendo
I/Core    (10179): Country: USA
D/UI-Console(10179): Cheat codes disabled.
I/UI-Console(10179): using Video plugin: 'GLideN64' v2.0.0
I/UI-Console(10179): using Audio plugin: 'Mupen64Plus OpenSLES Audio Plugin' v2.0.0
I/UI-Console(10179): using Input plugin: 'Mupen64Plus Android Input Plugin' v1.0.0
I/UI-Console(10179): using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.5.0
I/Core    (10179): Setting video mode: 1440x1080
I/GameSurface(10179): Creating GL context
V/GameSurface(10179): Found EGL display connection
V/GameSurface(10179): Initialized EGL display connection
V/GameSurface(10179): Found compatible EGL frame buffer configuration
V/GameSurface(10179): Created EGL rendering context
V/GameSurface(10179): Created EGL window surface
V/GameSurface(10179): Bound EGL rendering context to EGL window surface
I/GameSurface(10179): Created GL context OpenGL ES 3.0 V@14.0 AU@04.02.02.073.175 PDAVID_AU_LINUX_ANDROID_JB_2.5.4.04.02.02.073.175+PATCH[ES]_msm8960_JB_2.5.4_CL3406509_release_ENGG (CL@3406509)
W/Adreno200-ES20(10179): <process_gl_state_enables:470>: GL_INVALID_ENUM
I/Core    (10179): Starting R4300 emulator: Dynamic Recompiler
I/Core    (10179): Init new dynarec
I/Core    (10179): ARM CPU Features: SWP, Half, Thumb, FastMult, VFP, ESDP, NEON, VFPv3, TLS, VFPv4, IDIVa, IDIVt
D/WindowManager(  654): Send Logs not enabled!
I/GameLifecycleHandler(10179): onWindowFocusChanged: false
I/GameLifecycleHandler(10179): onPause
D/Core    (10179): Emulation paused.
I/GameLifecycleHandler(10179): surfaceDestroyed
D/Core    (10179): Stopping emulation.
D/Core    (10179): Saved state to: yyyy-mm-dd-hh-mm-ss.sav
I/Core    (10179): R4300 emulator finished.
I/GameSurface(10179): Destroying GL context
V/GameSurface(10179): Unbound EGL rendering context from EGL window surface
V/GameSurface(10179): Destroyed EGL window surface
V/GameSurface(10179): Destroyed EGL rendering context
V/GameSurface(10179): Terminated EGL display connection
E/libEGL  (10179): call to OpenGL ES API with no current context (logged once per thread)
D/Core    (10179): Rom closed.
I/ae-bridge(10179): Unloading native libraries
I/GameLifecycleHandler(10179): onStop
I/GameLifecycleHandler(10179): onDestroy

Glide64mk2 throws missing GL-ARB extension errors while GLideN64 does not have any extension error there.
Should I also get log data for Rice since it does not have the scanlined square gridding issue that Glide64mk2 has on DK64,but does have minor visual issues as seen with Banjo-Tooie?

GLideN64 doesn't have the minor Banjo-Tooie square gridding issue found on Rice.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 02, 2015, 11:56:33 PM
Went ahead and did Rice with Banjo-Tooie.

Rice:
Code: [Select]
I/Core    (32085): Goodname: Banjo-Tooie (U) [!]
I/Core    (32085): Name: BANJO TOOIE         
I/Core    (32085): MD5: 40E98FAA24AC3EBE1D25CB5E5DDF49E4
I/Core    (32085): CRC: C2E9AA9A 475D70AA
I/Core    (32085): Imagetype: .z64 (native)
I/Core    (32085): Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
I/Core    (32085): Version: 144A
I/Core    (32085): Manufacturer: Nintendo
I/Core    (32085): Country: USA
D/UI-Console(32085): activated cheat code 32: no fskip
I/UI-Console(32085): using Video plugin: 'Mupen64Plus OpenGL Video Plugin by Rice' v2.5.0
I/UI-Console(32085): using Audio plugin: 'Mupen64Plus OpenSLES Audio Plugin' v2.0.0
I/UI-Console(32085): using Input plugin: 'Mupen64Plus Android Input Plugin' v1.0.0
I/UI-Console(32085): using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.5.0
I/Video   (32085): Disabled SSE processing.
I/Video   (32085): Found ROM 'BANJO TOOIE', CRC 9aaae9c2aa705d47-45
I/Video   (32085): Enabled hacks for game: 'BANJO TOOIE'
I/Video   (32085): Initializing OpenGL Device Context.
I/Core    (32085): Setting 32-bit video mode: 1440x1080
I/GameSurface(32085): Creating GL context
V/GameSurface(32085): Found EGL display connection
V/GameSurface(32085): Initialized EGL display connection
E/GameSurface(32085): Failed to find compatible EGL frame buffer configuration
V/GameSurface(32085): Terminated EGL display connection
E/GameSurface(32085): Failed to create GL context
W/CoreInterfaceNative(32085): Retrying GL context creation without EGL_BUFFER_SIZE=32
I/GameSurface(32085): Creating GL context
V/GameSurface(32085): Found EGL display connection
V/GameSurface(32085): Initialized EGL display connection
E/GameSurface(32085): Failed to find compatible EGL frame buffer configuration
V/GameSurface(32085): Terminated EGL display connection
E/GameSurface(32085): Failed to create GL context
W/CoreInterfaceNative(32085): Retrying GL context creation using legacy settings
I/GameSurface(32085): Creating GL context
V/GameSurface(32085): Found EGL display connection
V/GameSurface(32085): Initialized EGL display connection
V/GameSurface(32085): Found compatible EGL frame buffer configuration
V/GameSurface(32085): Created EGL rendering context
V/GameSurface(32085): Created EGL window surface
V/GameSurface(32085): Bound EGL rendering context to EGL window surface
I/GameSurface(32085): Created GL context OpenGL ES 3.0 V@14.0 AU@04.02.02.073.175 PDAVID_AU_LINUX_ANDROID_JB_2.5.4.04.02.02.073.175+PATCH[ES]_msm8960_JB_2.5.4_CL3406509_release_ENGG (CL@3406509)
W/Video   (32085): Failed to set GL_SWAP_CONTROL to 0. (it's 16)
W/Video   (32085): Failed to set GL_BUFFER_SIZE to 32. (it's 16)
W/Video   (32085): Failed to set GL_DEPTH_SIZE to 32. (it's 16)
I/Video   (32085): Using OpenGL: Qualcomm - Adreno (TM) 320 : OpenGL ES 3.0 V@14.0 AU@04.02.02.073.175 PDAVID_AU_LINUX_AND
I/Core    (32085): Starting R4300 emulator: Dynamic Recompiler
I/Core    (32085): Init new dynarec
I/Core    (32085): ARM CPU Features: SWP, Half, Thumb, FastMult, VFP, ESDP, NEON, VFPv3, TLS, VFPv4, IDIVa, IDIVt
W/Adreno200-ES20(32085): <process_gl_state_enables:470>: GL_INVALID_ENUM
I/GameLifecycleHandler(32085): onPause
D/Core    (32085): Emulation paused.
I/GameLifecycleHandler(32085): surfaceDestroyed
D/Core    (32085): Stopping emulation.
D/Core    (32085): Saved state to: yyyy-mm-dd-hh-mm-ss.sav
I/Core    (32085): R4300 emulator finished.
I/GameSurface(32085): Destroying GL context
V/GameSurface(32085): Unbound EGL rendering context from EGL window surface
V/GameSurface(32085): Destroyed EGL window surface
V/GameSurface(32085): Destroyed EGL rendering context
V/GameSurface(32085): Terminated EGL display connection
D/Core    (32085): Rom closed.
I/ae-bridge(32085): Unloading native libraries
I/GameLifecycleHandler(32085): onStop
I/GameLifecycleHandler(32085): onDestroy
I/Adreno200-EGL(31894): <qeglDrvAPI_eglInitialize:265>: EGL 1.4 QUALCOMM build: PDAVID_AU_LINUX_ANDROID_JB_2.5.4.04.02.02.073.175+PATCH[ES]_msm8960_JB_2.5.4_CL3406509_release_ENGG (CL3406509)
I/Adreno200-EGL(31894): Build Date: 01/06/14 Mon
I/Adreno200-EGL(31894): Local Branch: master
I/Adreno200-EGL(31894): Remote Branch: quic/jb_2.5.4
I/Adreno200-EGL(31894): Local Patches: 8eb510a221aaeae58c0ecdd202385ce404871588 PROFILER: Added proper handling of partially filled mipmaps
I/Adreno200-EGL(31894):                  2e6d0a734aa661addd942fe6f373d55a407591a6 PROFILER: CL3406509:  Compressed texture support.
I/Adreno200-EGL(31894):                  fdfb486203fdd417c56d12d68e6997ebd0ae8726 PROFILER: Check fo

How do I get 32bit working in Rice and avoid getting kicked to the legacy version?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on June 03, 2015, 06:50:41 AM
Thanks, very helpful :)  I will look into what config parameters are being passed to the GL context creation process by each video plugin.  It's probably a coin toss whether that is it.  Will have to wait until tonight though.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on June 03, 2015, 09:43:36 AM
Anyone else seeing major slowdown in fcube in every plugin except glide64?
glide64 runs it 60fps all the over plugins struggle to reach 10-16fps, rice manges 20fps+as next fastest.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 04, 2015, 01:10:19 AM
New details found!

I ran Banjo-Kazooie with my custom profile for GLideN64 with FBEmulation disabled,5xBRZ shading,and no caching (menu prone to crashing after exiting game with shader),then I went to Treasure Trove Cove.
after reaching the ramp near the ledge of the Orange Jinjo,I noticed the screen visual minorly had the scanlined square gridding.
Seeing this,I was immensely frustrated by the fact and took some screenshots in case.
Edit: Useless screenshots,forgot screenshots are broken with GLideN64.

Then I backed out to run the game with default GLideN64 profile and then custom profile with most defaults like FBEmulation,and also with 5xBRZ shading and default cache settings checked.
Then,even with shading,it looked perfect on the same wall free of scanlined squares.

Summarized: GLideN64's FBEmulation enabled makes the screen visual perfect while disabled makes the squares appear.
Glide64mk2 with framebuffer has horrendous scanlined square gridding as seen on DK64,though it has "FB Read Always" disabled.
Rice lacks any proper frame buffering.

From my newly found details,how can this be fixed?
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 04, 2015, 01:35:31 AM
Got screenies of best example!!!

I set the resolution to the lowest with zoom mode and ran DK64 on GLideN64 with and without FBEmulation.

DK64 with framebuffer:
http://www.2shared.com/photo/mfRYtfpu/GLideN64_framebuffer.html

DK64 without buffering:
http://www.2shared.com/photo/rkH80MrS/GLideN64_no_buffer.html

So this is what perfection looks like? (framebuffer)

Edit: Turns out GLideN64 actually runs faster on lowest resolution while other plugins didn't go any faster.
Even HWLighting runs at 60fps on Super Smash Bros. with lowest resolution while at a painfully slow 18-20fps in Native resolution 1080P.

Banjo-Tooie with "no frameskip" code enabled reaches 60fps on lowest resolution while it is slow at 36-38fps in Native resolution.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on June 07, 2015, 09:15:31 PM
Alpha 20 released.  It's a huge update from Alpha 19.  See the first post of this thread for the link and release notes.
Title: Re: 3.0 Alpha Testing
Post by: storm20200 on June 17, 2015, 06:40:37 AM
Great to see this still in development, had some great fun playing Pokemon Stadium with a house mate using this and a MyDP adapter on my Nexus 5. Would it be better to just use the latest alpha or stick with the stable Play Store build? I don't mind bugs here and there.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 17, 2015, 10:39:53 AM
You can always try it out since it installs right next to the other one and doesn't alter it.
You get the cheat editor,DK64 collisions/Banjo-Tooie support,GLideN64 access,also recently available real-time based activator Gameshark code support,and some other stuff all in the alpha.

So much extra stuff. ;D

Only latest master build has realtime cheat support with Conker fixed.

http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201506161103_14f135d.apk

Thanks to Gillou for fixing the Conker issue.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on June 17, 2015, 10:33:13 PM
Thanks Gilles for the CBFD fix, and thanks retroben for finding it right away :)

I updated the OP to Alpha 21.  Identical to Alpha 20 but fixes CBFD.
Title: Re: 3.0 Alpha Testing
Post by: studiosound on June 18, 2015, 12:47:41 PM
I've been going through my catalog to see if everything works, and I can't get Turok 2 (u)1.0 or Turok 3 (U) to boot in this new alpha 21. I've tried several different versions of the files to no avail. They worked previously in current Mupen64+ and 2.5 beta as well as previous 3 alphas. Anyone else have that issue? Every other game that previously worked still boots and the new file selection process is nice.
I also can't get the new GlideN64 2 settings to go to anything other than a black screen, including changing my audio to the new sles version. Is there a trick to it, or is it the x86 of my tablet the culprit? I understand it's bleeding edge stuff, but I may be doing it wrong.
Dell Venue 3830 x86 4.4.2
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 18, 2015, 02:47:49 PM
It's an x86 issue for GLideN64 because my x86 tablet also fails to run that plugin.

The Turok crashing might be related to x86 differences since Castlevania crashes on x86 while my FireTV runs it fine via ARM.

According to the logcat,GLideN64's non-running black screen is caused by the GL Context immediately being destroyed just after creation,halting the boot process.
The other GFX plugins work fine though.
Maybe Gillou can try to find a fix for this?
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on June 19, 2015, 01:51:52 AM
I just tested turok, turok2 and castlevania with new dynarec on windows x86 with no issues. @retroben could you test again all 3 games with latest autobuild?
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 19, 2015, 12:14:10 PM
I was talking about my Android x86 tablet.

Castlevania still crashes on Android x86 with "unfortunately" error box on the latest build.

In logcat I get:
Code: [Select]
Fatal signal 11 (SIGSEGV) at 0xffffff2d (code=1), thread 2529 (CoreThread)
Also this neat sentence...
Hello, this is UFO GRALLOC/Intel Corporation
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on June 19, 2015, 02:07:26 PM
I was talking about my Android x86 tablet.

Sure, me too ;)

I'd like to understand why it crashes an android x86 while it works just fine on windows x86 (still need to check on linux x86)

Could you send me castlevania's rom md5?

Where does it craches exactly?

Also could you test with pure interpreter just to be sure it's dynarec related?

Last question do you recall if this was also happening with old dynarec?
Title: Re: 3.0 Alpha Testing
Post by: alexei_gp on June 19, 2015, 08:36:09 PM
Where is the alpha 21?  i cant find it ...i m asking this because i tested this apk named mupen64 master  version 2015-06-18 09:03(commit a9b9e1e) and i cant access on the emulator mupen the microsd storage on my nvidia shield portable.I get that apk in this link http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/ (http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/)

Another bug with the apk mupen64 master  version 2015-06-18 09:03(commit a9b9e1e) the emulator doesnt detect any buttons on the nvidia shield portable.only works the touch screen.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 19, 2015, 10:29:25 PM
Castlevania crashes in the same place it always has,at the first skeleton cutscene.

The MD5 checksum via ES File Explorer is: 1cc5cf3b4d29d8c3ade957648b529dc1

I've tried running it in the past when on an older version of Mupen.

Can't test interpreter until a little later.
Title: Re: 3.0 Alpha Testing
Post by: studiosound on June 20, 2015, 12:07:16 AM
To be clear, Turok 1 boots. It's Turok 2 (U) 1.0 and Turok 3(u) that either don't boot or boot to black and freeze in the current listed Android build posted by the dev at the very top of this thread. Both dynarec and  interpereter have the same result of booting to black for me. The earlier posted Android MupenAE+ builds from the original post booted those particular clean roms.

Turok 3 (U) MD5
1211c556d77b169d81a666a9661e1777

Turok 2 (U) 1.0 MD5
fad4da8e17ce12f68cdf29180cdd4a90

Dell Android x86 4.4.2
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 20, 2015, 12:18:35 AM
Are you using GLideN64 on the profiles by any chance?
You might have accidentally had them set to it,as I have done that a few times myself.

Make sure they are both using Glide64,Rice,or glN64 to make sure you didn't have the silly things on GLideN64.

I wonder what is causing GLideN64's issues to begin with.
Why is it destroying GL Context immediately after creation?
Title: Re: 3.0 Alpha Testing
Post by: studiosound on June 20, 2015, 08:21:27 AM
I'm using using the Glide64 accurate, or any of the other, usually working emulation profile. I've defaulted my settings, I've changed profiles...note that every other rom using the same settings that previously worked still boots as expected. The only two games that don't boot like they used to are Turok 2 (u) and 3 (u), and only on my Dell Venue 3830 Android tablet. Files unzipped. Older versions of the Android Mupen ae+ still boot Turok 2 and 3 just fine.

I'm not bothering with the GlideN64 GLES as no games boot using it on my x86 tablet, running Android 4.4.2.

My last attempt later will be to clear out the beta and do a clean install. We shall see.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on June 21, 2015, 04:46:11 AM
Quote
Older versions of the Android Mupen ae+ still boot Turok 2 and 3 just fine.

If you can find which version exactly introduced this issue this will be very helpfull ;)
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on June 22, 2015, 08:07:52 PM
Hi iam just starting to learn about texture packs can anyone tell me a good place to download some perhaps for goldeneye are shadows of the empire i have a few for super mario 64 i havent seen any for those games yet
Title: Re: 3.0 Alpha Testing
Post by: Donlavon1 on June 23, 2015, 01:03:27 AM
just google 'N64 textures' and you should find them. I don't think you can use textures on the latest beta builds yet.
Title: Re: 3.0 Alpha Testing
Post by: marc on June 25, 2015, 02:47:07 AM
good morning,
is there any solution for the crash of banjo tooie?
I tried in every way but nothing, always crash!
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 26, 2015, 01:38:11 AM
Man,so much absence lately.

The crashing is fixed and otherwise alleviated on the Alpha Builds.
There's also GLideN64 to try out with both GLES2 and GLES3.
If it still crashes for you,tell us your device and its specs so the devs can assist you.

Meanwhile,I have an issue myself.
Glover 2 now as I know,fails to boot on Dynarec,but runs on Interpreter.
The problem is that everything is frozen in place and you can't intereact with them properly.
For example,the magic cookbook is completely missing.

But on 2.4.4,everything works fine,but it runs slower than the Alpha's Interpreter.
Is there any chance this can be fixed? (maybe something upstream related is causing this issue)
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on June 26, 2015, 06:53:28 AM
Here s some issues ive encontered on the latest auto build using gliden64 when i exit out it sometimes crashes the app during autosave or takes longer than 30 seconds to autosave no matter what game other plugibs seem fine during autosave.i have a nvidia shield portable tegra 4.turok 2 and 3 wont run no matter what plugin.goldeneye has missing textures on the soldures guns might be a setting thing not sure.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on June 26, 2015, 07:12:47 AM
Goldeneye texture issue is on gliden64 not a expert on settings so not sure if its the plugin are me not using correct setting oh its on gles 2 version frame buffer emulation setting on.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on June 26, 2015, 07:26:48 AM
Perfect dark hasn't run on my shield since alpha 18 are before dont remember what build it started on but it did run at one time hope some of this info helps.
Title: Re: 3.0 Alpha Testing
Post by: retroben on June 26, 2015, 10:46:05 AM
Well the 30 seconds and crashing autosave issue with GLideN64 is a mix with texture caching and enhancements which Android really dislikes,so it acts up and crashes.
You'll have to copy a profile and disable those texture caching and compressed cache options to stop it from doing that.

Android OS just really hates some types of cache files,not sure why it is so aggressive.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on June 26, 2015, 01:44:25 PM
Ok cool any idea what setting i should try for goldeneye to fix texture on soldures guns the rest of the game plays fine with frame buffer emulation on.007 gun texture work fine.
Title: Re: 3.0 Alpha Testing
Post by: marc on June 26, 2015, 03:59:44 PM
with my s3 with android 4.1.2 crash persist also with last alpha build, is there  some specific settings to limit them?
Title: Re: 3.0 Alpha Testing
Post by: marc on June 28, 2015, 03:07:16 AM
it's dynarec problem, on interpreter i havent crash
Title: Re: 3.0 Alpha Testing
Post by: danny19901 on June 28, 2015, 11:10:31 AM
Latest Alpha is pretty great so far i tested Resident evil 2 but although it gets in game with Glide64 accurate. But still unplayable but it's progressed more than before can't wait to finally get to play. Issues Are flickering in game, Very Dark can see zombies and player but not much also crash doesn't happen anymore. I have Xperia Z1 on 5.1.1 But loving the new Test alphas will test more
Done more testing on my Tab S 8.4 LTE T705 i have been playing Resi 2 with cheats due to graphic issues. i have however took some screenshots
(http://s30.postimg.org/psnhp4ae5/Screenshot_2015_06_28_20_31_58.png) (http://postimg.org/image/psnhp4ae5/)

(http://s30.postimg.org/kc4tuqh0d/Screenshot_2015_06_28_20_32_06.png) (http://postimg.org/image/kc4tuqh0d/)

(http://s30.postimg.org/fssl97z4t/Screenshot_2015_06_28_20_33_29.png) (http://postimg.org/image/fssl97z4t/)

(http://s30.postimg.org/h943rd21p/Screenshot_2015_06_28_20_37_51.png) (http://postimg.org/image/h943rd21p/)

(http://s30.postimg.org/bidxdmu1p/Screenshot_2015_06_28_20_38_22.png) (http://postimg.org/image/bidxdmu1p/)

(Gliden64 crashes for me on Resi2 also tried Gliden64 3.1 and same i also tried changing settings for it)
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on June 28, 2015, 11:31:46 AM
^ I couldn't get in-game with gliden64-gles 2.0 it kept crashing, managed to get in-game with 3.1 but had to do it resuming from a rice save state, I managed to make it into the kendo shop with the blank backgrounds so now have a gliden64-gles save state from the shop, the kendo / zombie scene played without issues which bodes well, I later died on the street just before the bus zombie group :-)
Title: Re: 3.0 Alpha Testing
Post by: Daeymon on June 29, 2015, 07:47:57 AM
Alpha 21 is looking amazing. Good to see such solid improvements.

Have noticed some changes in how the Intents now work. The game will now automatically Resume when launched through an Intent. On the stable release, with a combination of two intents, we got to a menu to choose to Resume or Restart. Getting rid of the menu is definitely the right direction, and the majority would indeed want to Resume. But I actually prefer to Restart instead of Resume.

Could the choice be returned to the user? But instead of a menu, have the choice in the intent itself via an Extra parameter? Keep the default as is, as that will work for the majority, but the minority could provide this Extra parameter to get the game to launch as a Restart instead of a Resume.
Title: Re: 3.0 Alpha Testing
Post by: The MAZZTer on June 30, 2015, 06:43:28 PM
Alpha 21 looks great. Couple of issues I noticed... some may be old, I haven't used mupen too much in the past.

- If you have a game configuration (even if you reset game settings to defaults), the game will fail to launch and mupen crashes. Workaround is to manually jump into the /data/data folder for the app and purge the game configuration file (and if you're not rooted... you gotta wipe data I guess) then the game starts working again. Specifically what I was doing to cause this was running Goldeneye (U) [!], messed with the preset config setting for it, ran it, it crashed, tried to reset game config, still crashed, found and deleted the game config file and then it ran fine.
- The touchscreen analog stick feels odd to me. If I touch it on the edge, for example, the game immediately registers a stick press in that direction. It's probably working as designed, but it would be nice to have a type of analog stick where I press down and the stick automatically centers under my finger. That way I can be less precise with my finger. I think such designs also tend to move the stick when the player's finger reaches the edge of it and keeps going, so the player doesn't have to move as far back to center. Some experimentation is needed here I think.
- On a similar theme it would be nice to scale individual controls in a touchscreen config. I noticed you can scale them all at once, I'm gonna try that and see if it helps me with my analog stick problems but we'll see. Might still be valuable to scale individual controls.
- It's a bit odd in the touchscreen config and in game to pull down the toolbar using the back button. I suggest you try Chrome Desktop and see how they handle pulling down a toolbar in fullscreen immersive mode... specifically, when you enter immersive mode, swiping to show the status bar/nav bar disables immersive mode and shows the toolbar (which is permanently visible and not overlapping the main view). This solves the issue with the inaccessible more button and the status bar overlapping the toolbar. Also makes it one less action to show it (no back button needed). Since we want to be in immersive mode most of the time, maybe the toolbar can go back to hiding and immersive mode comes back on if you tap inside the game.

The game browser is great, most of my games show up and it pretty much looks like what I wish all emulators did.

Could the choice be returned to the user? But instead of a menu, have the choice in the intent itself via an Extra parameter? Keep the default as is, as that will work for the majority, but the minority could provide this Extra parameter to get the game to launch as a Restart instead of a Resume.

Could always use a setting set in advance in the application. Default run mode for intent: Resume, Restart, Ask.
Title: Re: 3.0 Alpha Testing
Post by: Mikhail on June 30, 2015, 08:31:18 PM
I'd propose the change of the analog stick moving to wherever you placed your finger within the outer circle rather than having to drag it from it's central point outwards to move in all directions with a white touch input dot showing it's current location, gradual analogue movement doesn't feel right on a touchscreen and having your thumb pressed down in the same area tends to hurt after a few minutes it's like the old plastic controllers that had rock hard a and b buttons that left an imprint.
Basically what i'm refering too is using the analogue stick more like an eight way d-pad.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 05, 2015, 09:36:59 PM
I'm getting a crash when configuring input in TV mode in latest autobuild. Here is a core dump file from an earlier build.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 05, 2015, 09:52:16 PM
I can see what is wrong. In arrays.xml resource, the inputMapActivity_values needs one more entry. I can see what the fix is, is there an easy way to check in a fix if I get it to work?
Title: Re: 3.0 Alpha Testing
Post by: littleguy on July 05, 2015, 10:07:11 PM
Just submit a pull request on github.  Sorry I'm on vacation and away from my computer right now.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 05, 2015, 11:39:00 PM
Should I be able to push my change to master before creating the pull request? I'm not too familiar with how things are done in this project.

By the way, I tested the fix and it seems to work ok. No more crashing in TV mode and the screenshot functionality in TV mode works now.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on July 06, 2015, 12:33:03 AM
You need to fork the repo first, then push your change to the fork (master or a new branch) and finally open the pull request from there ;)
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 06, 2015, 09:47:16 PM
Ok, that took me a bit to figure out, but I think I got it. Git is very new to me, we use all SVN where I work.
Title: Re: 3.0 Alpha Testing
Post by: littleguy on July 06, 2015, 11:08:45 PM
Thanks fzurita!   :D
Title: Re: 3.0 Alpha Testing
Post by: retroben on July 14, 2015, 12:42:18 AM
After the recent post about Yabause AE and the async feature,I have come to a harsh realization in light of slow performance on Android Shield TV running my mentioned Banjo-Tooie 60fps test,the emulator is actually what is slow,not the box.
I say this because I just saw a comparison video using Yabause with normal sync and the new async,and the results of the slower sync method show it running a game at 39-49fps/60fps on an Nvidia Android Shield TV while async runs at full 60/60fps.

https://www.youtube.com/watch?v=Og11R6-b_T4

Now obviously,we sadly can't get improved N64 emu speed using async with CPU and GPU via asynchronous because of how the real N64 hardware is designed,or am I wrong?
(If so,then awesome if async can be done for a really great speed boost!)

And yes,I probably should of said this upstream instead of here,just getting desperate since the excessive lack of activity on the forums lately.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 14, 2015, 09:27:06 AM
Retroben, the new 3.0 auto build has an x86 workaround. Can you see if that works for you? It allows the GlideN64 plugin to start, but it's not really a true fix.
Title: Re: 3.0 Alpha Testing
Post by: retroben on July 14, 2015, 12:27:39 PM
Thanks.

Possibly the part making them run is causing slowdown.
The GLES 3.0 variant is indeed slower while the GLES2 variant is really good.
I can run Super Smash Bros. with four DKs on Hyrule VS. Mode at a full smooth 60fps the entire time on it.
Yet I get the same exact frame-dip problems on the intro sequence for some split-second moments.

Also a mention about noise,the locked character slots in SSB use it too,so another thing for Gonetz to be able to look at easily for proof of working noise emulation on GLES2.
Title: Re: 3.0 Alpha Testing
Post by: OnijJoku on August 02, 2015, 01:46:39 AM
It appears gles2 is buggy on my myTouch 4G (4.1.1). When it was Jellybean, it was just black screen. Now that it's gingerbread (2.3.5), it displays the game the first time, but the second time I load the same rom I get a black screen from then. I just brought this up for compatibility reasons. It works great on my Note 3 and this device called a Rockchip rk31sdk. Thanks for these great updates.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 02, 2015, 10:40:54 PM
I think the performance issues in OpenGL ES 3.0/3.1 are GLSL related. The more shader code gets added the slower it seems to get. Also, each a shader is compiled, games end up stuttering. From logging I added, it seems that shader re-compilation is happening a lot in Android.
Title: Re: 3.0 Alpha Testing
Post by: retroben on August 11, 2015, 02:01:21 PM
Something I think should have immediate attention.
Can an option be added to use aspect ratios so we can actually use 16:9 widescreen for the correct filled screen size on widescreen capable games?
I can't stand how useless it is for Banjo-Tooie and DK64 with widescreen enabled,as it has the large black bars on the left and right.

Additionally,I must again mention that GLideN64 has scaling glitches when you use stretch,it has glitched edges instead of scaling to the stretched width like it is supposed to,which kinda sucks when you want to see the beauty of native resolution on a 1080P screen combined with stretch (or pending 16:9 mode) to fill in the black border space.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 11, 2015, 10:15:47 PM
Something I think should have immediate attention.
Can an option be added to use aspect ratios so we can actually use 16:9 widescreen for the correct filled screen size on widescreen capable games?
I can't stand how useless it is for Banjo-Tooie and DK64 with widescreen enabled,as it has the large black bars on the left and right.

Additionally,I must again mention that GLideN64 has scaling glitches when you use stretch,it has glitched edges instead of scaling to the stretched width like it is supposed to,which kinda sucks when you want to see the beauty of native resolution on a 1080P screen combined with stretch (or pending 16:9 mode) to fill in the black border space.

The 16:9 mode sounds like a difficult thing to do. I think it would have to be done on a plugin by plugin basis.
Title: Re: 3.0 Alpha Testing
Post by: grayman on August 12, 2015, 01:54:03 AM
Now that it's gingerbread (2.3.5), it displays the game the first time, but the second time I load the same rom I get a black screen from then.
I've got the same problem with gilden64 3.1 on my galaxy s6. When I play a game the first time it works perfectly, but when i play it the second time the picture is just static. all else works but except for that.
note that the problem happened both on 5.1 and 5.1.1 android versions so I'm  not sure if it's that that's causing the problem. I've  also got opengl es 3.1 exactly as specified so I'm  stumped as nothing I've tried (basic fidgeting with available options on the 2.1 alpha build and trying some methods that were said on the forum) has allowed me to open a game the second time
If this is resolved,  well conker's bad fur day does play on 30fps as does majora and banjo kazooie. And I've seen no notable glitches if any at all.
Played games all perfect:
banjo kazooie
majora
smash
conker 28-34 fps (rare 43fps)
yoshi story
paper mario (it was perfect on this and i played it before on n64oid on 25 fps on my galaxy s4 with glitches and crashes so major improvement.)
and i just tried banjo tooie which doesn't  seem to show it at all on gliden64 3.1 which is odd.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 12, 2015, 10:49:11 PM
Something I think should have immediate attention.
Can an option be added to use aspect ratios so we can actually use 16:9 widescreen for the correct filled screen size on widescreen capable games?
I can't stand how useless it is for Banjo-Tooie and DK64 with widescreen enabled,as it has the large black bars on the left and right.

Additionally,I must again mention that GLideN64 has scaling glitches when you use stretch,it has glitched edges instead of scaling to the stretched width like it is supposed to,which kinda sucks when you want to see the beauty of native resolution on a 1080P screen combined with stretch (or pending 16:9 mode) to fill in the black border space.

The 16:9 mode sounds like a difficult thing to do. I think it would have to be done on a plugin by plugin basis.

Ok, so apparently you can already do this. It doesn't work with GLideN64 though, but it does work with other plugins. Just set the "Rendered Resolution" to native and the "Screen Scaling" to stretch.
Title: Re: 3.0 Alpha Testing
Post by: retroben on August 12, 2015, 11:45:47 PM
Is "stretch" just a confusing scale-type name for the 16:9 aspect?
I wouldn't think so since it is only stretching it instead of squeezing and stretching it,I dunno.
Unless that is what 16:9 is,I can't help but get confused about this... :-\

Okay,I think I figured it out.
Normally,on a TV with the actual console,the game fills the entire screen in both modes,but when enabling the widescreen mode on it,you see it become squished to fit completely,revealing the missing part of the game visual.

I'd really like to see that GLideN64 issue fixed though. ;)
Title: Re: 3.0 Alpha Testing
Post by: SuperL on September 11, 2015, 12:09:17 PM
I'm in need of some real help.

I have an x86 android tablet with Lollipop. It most definitely has OpenGL ES 3.1. because I've checked it with (with an app). But I can't get any of the GlideN64 plugins to display anything.

There's some quirk with x86. Someone worked around it by inserting code into the Opengl.cpp. https://github.com/gonetz/GLideN64/issues/604

How can I fix this?
Title: Re: 3.0 Alpha Testing
Post by: Rare Rian on September 19, 2015, 04:53:24 PM
This isn't a bug report or anything I was just wondering if there's a set date or at least a prediction on when this will officially update on Google Play and great work on this app
Title: Re: 3.0 Alpha Testing
Post by: Rare Rian on September 19, 2015, 07:49:11 PM
Don't know if this is new or not but I'm on the Alpha 21 and on Legend of Zelda Ocarina of Time when I enter the cave where you blow up a big rock for the gorons on death mountain about halfway in the entrance room it becomes really choppy anything I can do
Title: Re: 3.0 Alpha Testing
Post by: Rare Rian on September 19, 2015, 07:51:58 PM
Don't know if this is new or not but I'm on the Alpha 21 and on Legend of Zelda Ocarina of Time when I enter the cave where you blow up a big rock for the gorons on death mountain about halfway in the entrance room it becomes really choppy anything I can do

I fixed it embarrassing I didn't try this but you have to exit the app fully or go into another app already opened without exiting the rom
Title: Re: 3.0 Alpha Testing
Post by: nscxp2005 on September 22, 2015, 09:05:30 AM
I'm loving the new updates to this Emulator. I have followed this from the beginning.

I would like to request the puzzle pieces not showing correctly we going to the title screen of Banjo Kazooie can be fixed using the Glide64 plug in.

It would be fantastic for that game to be perfect.

Keep up the amazing work guys.
Title: Re: 3.0 Alpha Testing
Post by: astanners on September 27, 2015, 09:33:06 PM
Hey I am running the emulator on a Fire TV and using a Nyko Play Pad Pro. First off I wanted to say I love the emulator you did a great job and I am seeing almost everything run great! (Resident Evil 2 didn't seem to render properly)

The only issue I am running into is the controller does not seem to have start mapped to it. Is there somewhere I can map this? I would rather have the "select" button on the controller mapped to act as start then show a quick look at the game speed, etc.

Thanks in advance!
Title: Re: 3.0 Alpha Testing
Post by: fzurita on September 28, 2015, 06:45:18 AM
Do you have the latest alpha build? Here it is just in case you don't:

http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/

Grab the one from September 8th.

In that build, you can go to the top left menu, which brings up the side bar. From there, go to controller profiles. Click on the Nyko profile (if there is one) and then hit copy. From there you can click on the copy, hit edit, and adjust the mappings.

Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on October 05, 2015, 02:35:14 PM
http://www.jxd.hk/game-console/s192/ new device powered by nvidia tegra k1 2gbs ram 13mp and 5mp camera 7 inch screen 1080p 10000mah battery looks like it was made to compete against shied
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on October 14, 2015, 08:03:07 AM
Hello everyone, first post here.
I just registered to thank the developer(s) for this great project and congratulate them on a job well done. Ever since discovering the
3 α debug versions, i playtested them extensively on my phone and tab. I really like the multiple plugin support, makes all the difference in the world when playing a game like Perfect Dark , having the light coronas or the camspy rendered correctly like a real N64.

I also like the cover gui (the initial rom scan however misses some games if they are in .zip form) and especially the sidebar that is accesible in game, in the last 3 apk updates. Really useful and handy addition, well done!

I also have a couple of suggestions
1. Could there be an option to turn off auto save upon exiting a rom?
2. The touchpad editor having an option for A and B buttons to be side by side (like N64oid) instead of like a real N64 controller, useful for small screened smartphones

Finally,  on my phone (xperia E1) and tablet (LGV490), if i setup the mupen64 folder to be located on the external SD, some games like Turok 2 or 3 do not load. If i setup mupen64 folder to be located on internal storage, they play no problem.

That's all for now, again sincere thanks for this emu!
Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 14, 2015, 09:24:40 AM
Hello everyone, first post here.
I just registered to thank the developer(s) for this great project and congratulate them on a job well done. Ever since discovering the
3 α debug versions, i playtested them extensively on my phone and tab. I really like the multiple plugin support, makes all the difference in the world when playing a game like Perfect Dark , having the light coronas or the camspy rendered correctly like a real N64.

I also like the cover gui (the initial rom scan however misses some games if they are in .zip form) and especially the sidebar that is accesible in game, in the last 3 apk updates. Really useful and handy addition, well done!

I also have a couple of suggestions
1. Could there be an option to turn off auto save upon exiting a rom?
2. The touchpad editor having an option for A and B buttons to be side by side (like N64oid) instead of like a real N64 controller, useful for small screened smartphones

Finally,  on my phone (xperia E1) and tablet (LGV490), if i setup the mupen64 folder to be located on the external SD, some games like Turok 2 or 3 do not load. If i setup mupen64 folder to be located on internal storage, they play no problem.

That's all for now, again sincere thanks for this emu!

Yeah, I'm aware of the external SD card issues. I haven't tried to address them yet though since there are still so many other issues.

Also, why would you like to disable auto saves? Do you think it's affecting performance in your device? are you concerned about how much room the auto saves take?
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on October 14, 2015, 12:49:36 PM
 Yes that is correct, space is an issue on my part (at least on the phone, it has 4GB internal storage, of which 2gb are usable). I do have a 64GB HCSD ofcourse, but i had to put the mupen64 folder in the internal storage to avoid issues (btw i forgot to mention that even after tampering with foldermount to have the mupen64 folder on the SD and linked to internal storage, Turok 2 & 3 still didn't load).

 Performance is not affected (afaik at least) from auto saves, it's purely a room issue, as you describe.

Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 14, 2015, 02:56:11 PM
Ok, I will make the number of auto saves configurable in the future and also, definitely fix the bug with having the mupen64plus-ae folder in external storage. Hopefully I can track that one down.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 14, 2015, 02:57:46 PM
Also, eventually I want to revamp the cheat editor since it needs a little bit of work, but that is last priority at this point. These bugs are more important.
Title: Re: 3.0 Alpha Testing
Post by: retroben on October 14, 2015, 03:47:20 PM
Hopefully,after dealing with these bugs,maybe you can team up with Gillou and/or xperia64 to attempt to get realtime cheat management support working,complete with editing,enabling,disabling,and maybe deleting.
Maybe looking at PJ64's source code for how it does cheats can help for understanding how to make a non-windows equivalent of what it does for realtime management.

I love how on PJ64,I can hop in the cheat list,edit values of a code,and test the changes immediately,hopefully this can be achieved on Mupen64Plus AE in the near future.
Though one thing I doubt (but wish to have on Android) is adding a memory viewer and maybe also a cheat search for instant value changing or the chance to find new codes easily.
The extra entertainment that could bring with many people being able to search for new cheats and mess around with stuff,and I guess one main concern would be the onscreen keyboard usage for memory viewer and search.
The memory viewer should of course be an optional feature to sustain less RAM usage in normal situations.

I just really want this extra layer of control if possible,as I greatly enjoy messing around with cheats and a memory viewer with modifying capabilities would be the funnest way to do that.
Even if it requires root,it could be added for us fortunate enough to have root like myself.

Sorry for the great wall of text. :D
Title: Re: 3.0 Alpha Testing
Post by: littleguy on October 14, 2015, 07:00:02 PM
@retroben - I might be wrong here, but I'm not entirely sure the mupen64plus core supports real-time cheat loading.  AFAIK it only occurs when the core is first started (i.e. when game first launches).  I may be wrong though... I've never understood the cheat stuff that well.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 14, 2015, 07:40:41 PM
@retroben, you wouldn't need root for a memory viewer for a game running inside an emulator.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on October 14, 2015, 08:54:17 PM
I think I found a bug on nvidia portable perfect dark won't run with all guns player 1 cheat enabled i tried version 1.0 and 1.1 of the ROM glide64 accurate and glide64fast plugin tried other cheats with and without seems to be that specific cheat that causes it not to run and then crashes the app tried rice accurate it won't run at all with cheats enabled rice fast game won't run at all game wont run with all guns player 1 cheat on gln64 fast will run with other cheats I am running kit kit os hope this helps are spurs ideas
Title: Re: 3.0 Alpha Testing
Post by: retroben on October 14, 2015, 11:25:07 PM
Could be an accuracy sensitive code,is it the D0 activator one or the 5000xxxx code for all guns.

It would be nice if that core design could be modified to fully support realtime cheat list management/changes if it can't already do that.
I think xperia64 already proved that a code can be toggled realtime without restarting in his custom build for testing it via altering the UI,but it only works for the single SM64 code he hardcoded into it,and maybe since the recent cheat changes for alphabetical order and unchanged scroll positions for adding or deleting codes,it can be all the more possible.
Title: Re: 3.0 Alpha Testing
Post by: Gillou68310 on October 15, 2015, 01:21:21 AM
@littleguy I think realtime gameshark cheat code is now possible, see here:
https://github.com/mupen64plus/mupen64plus-core/commit/44fb3c3670f59dfa0a51c6c5db1d585eb4bba5ea (https://github.com/mupen64plus/mupen64plus-core/commit/44fb3c3670f59dfa0a51c6c5db1d585eb4bba5ea)
Title: Re: 3.0 Alpha Testing
Post by: retroben on October 15, 2015, 03:49:09 AM
Brainstorm magic done below... ;D

That's been done and added to Android actually and the issue is only for ASM related codes while the codes like most infinite stats codes would always work if they are for the current values instead of the executed ones.

The thing needed is a realtime change of what actual cheats are enabled and disabled or the cheat being changed.
This is different than using activators since you are modifying the cheat itself instead of the activator reading and writing the command you already placed for it,meaning something different needs to be done.

Maybe a fast list of the one game's entire list of codes and the function to refresh that list while the time you are editing codes is when you are actually editing the main cheat file ingame but like you normally would which is then copied to the fast list and thus refreshing it. :isanerd

While editing,adding,or deleting codes,the enabling or disabling of codes should be linked to both lists,so when you enable a code in the fast list,it is enabled in the main list and vice versa.
Simply put,the cheats loaded up should be the entire list for that game with indicators whether or not codes are enabled. (the way DS homebrew carts do it with ds games and action replay codes)
The biggest part is reprogramming the way cheats are done to support this style.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 15, 2015, 06:48:18 AM
I tried the All weapons for player 1 cheat and it does cause the game to not boot. I tried it on interpreter and didn't work either. I'm not sure what's up with that one specific code.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on October 15, 2015, 01:52:15 PM
I just triet turning on the code during gameplay and it worked iam using alpha build 0281802 october 12 forgot to mention that
Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 15, 2015, 03:00:48 PM
I just triet turning on the code during gameplay and it worked iam using alpha build 0281802 october 12 forgot to mention that

It seems that you can't start the game with it.
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on October 16, 2015, 01:29:09 PM
4 commits today! Whoa, you are unstoppable!
The auto save issue has been fixed as i can see. THANK YOU!! :)
Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 16, 2015, 02:03:59 PM
The dialog stating that game progress will be lost is a little misleading. We are still auto saving on exit.
Title: Re: 3.0 Alpha Testing
Post by: OnijJoku on October 20, 2015, 06:28:10 PM
Those automated builds are quite great. Pokemon Stadium with GlideN64-GLES-2.0 on my Note 3 is very accurate now. Thanks for the links!
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on October 20, 2015, 07:56:35 PM
Just thought I would report this not sure if anyone checked in a while but Turok 2 now works I know littleguy checked out a few games a while back to see it they where running and that was one that didn't so some good news
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on October 20, 2015, 08:00:43 PM
Just tried bomberman64 that also works now
Title: Re: 3.0 Alpha Testing
Post by: fzurita on October 20, 2015, 08:47:36 PM
Sounds like Gillou's dynarec fixes fixed more than one game.
Title: Re: 3.0 Alpha Testing
Post by: OnijJoku on October 22, 2015, 11:47:31 AM
Just tried bomberman64 that also works now

Thank you for this news!
Title: Re: 3.0 Alpha Testing
Post by: mikau1802 on October 24, 2015, 03:20:07 PM
I have a GPD xd.. a try tester Banjo.Toie .. but not work.... allways freez whien the game start... i try many video plugins.. but i dont know why...


someone can help me ? (maybe i have a worng apk .. i have 3.a.0 Code Version 37)
Title: Re: 3.0 Alpha Testing
Post by: retroben on October 24, 2015, 03:53:44 PM
The about menu is useless in this case,grab one of the latest alpha builds from the autobuilds and try it out.

www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/

Edit: Also,change "DelaySI" to "False" in the game's core config after the folders for the game are created.
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on October 24, 2015, 07:21:24 PM
Thank you for letting us configure the amount of autosaves per game i the 22/10 build :)
Title: Re: 3.0 Alpha Testing
Post by: rafar on November 12, 2015, 09:24:41 AM
I have noticed many improvements on many games... but some regressions too. When I have a bit time I will edit this post with that regressions, maybe it can help developers to fix these problems.

Perfect dark runs really fast,  but when I finish the first level, it get freeze the screen waiting to continue to the next level...and you need to reboot the game.

Mario tennis runs much better, it is almost playable and other games like pokemon stadium get fixed many of their bugs.


Congratulations to the devs for this great emulator.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 13, 2015, 07:11:35 AM
I have noticed many improvements on many games... but some regressions too. When I have a bit time I will edit this post with that regressions, maybe it can help developers to fix these problems.

Perfect dark runs really fast,  but when I finish the first level, it get freeze the screen waiting to continue to the next level...and you need to reboot the game.

Mario tennis runs much better, it is almost playable and other games like pokemon stadium get fixed many of their bugs.


Congratulations to the devs for this great emulator.

Thank gonetz for his great work on the GLideN64 video plugin
Title: Re: 3.0 Alpha Testing
Post by: vyktym on November 15, 2015, 06:42:48 PM
After a long run with the old 2.4 version, I decided to give the most updated alpha 3.0 version a spin; it looks great! All the hard work is appreciated!!

One question, and my apologies if I missed this (or if it hasn't been implemented yet), but how do I enable a second controller for multiplayer support? It's easy enough in the 2.4 version, but I can't seem to find it in the new alphas.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 15, 2015, 08:29:29 PM
It's game dependent. Click on a game and then go to settings and then from there you can setup a controller profile for each player.

I'm not sure how well it works since I haven't tried it. Feel free to report back though.
Title: Re: 3.0 Alpha Testing
Post by: Blurbsanime on November 16, 2015, 05:50:52 AM
Wow 3.0 is looking nice! There are some massive improvements.

One problem though. On the latest build, I am having some trouble with immersive mode. The navigation buttons do disappear but for some reason there is a black bar at the bottom of the screen to replace the buttons. I have tried everything in order to fix it, even trying to use gmd immersive mode but it seems to be plastered onto the screen. It cuts off part of the game (the bottom strip)

I thought that I should inform you so here ya go. Keep up the great work, it's coming along very well!

I can't attatch a screenshot because the file is too large  :P
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 16, 2015, 05:42:09 PM
Wow 3.0 is looking nice! There are some massive improvements.

One problem though. On the latest build, I am having some trouble with immersive mode. The navigation buttons do disappear but for some reason there is a black bar at the bottom of the screen to replace the buttons. I have tried everything in order to fix it, even trying to use gmd immersive mode but it seems to be plastered onto the screen. It cuts off part of the game (the bottom strip)

I thought that I should inform you so here ya go. Keep up the great work, it's coming along very well!

I can't attatch a screenshot because the file is too large  :P

What Android version do you have?
Title: Re: 3.0 Alpha Testing
Post by: Blurbsanime on November 17, 2015, 12:34:07 AM
Wow 3.0 is looking nice! There are some massive improvements.

One problem though. On the latest build, I am having some trouble with immersive mode. The navigation buttons do disappear but for some reason there is a black bar at the bottom of the screen to replace the buttons. I have tried everything in order to fix it, even trying to use gmd immersive mode but it seems to be plastered onto the screen. It cuts off part of the game (the bottom strip)

I thought that I should inform you so here ya go. Keep up the great work, it's coming along very well!

I can't attatch a screenshot because the file is too large  :P

What Android version do you have?

I have android 5.0
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 17, 2015, 04:26:03 PM
Wow 3.0 is looking nice! There are some massive improvements.

One problem though. On the latest build, I am having some trouble with immersive mode. The navigation buttons do disappear but for some reason there is a black bar at the bottom of the screen to replace the buttons. I have tried everything in order to fix it, even trying to use gmd immersive mode but it seems to be plastered onto the screen. It cuts off part of the game (the bottom strip)

I thought that I should inform you so here ya go. Keep up the great work, it's coming along very well!

I can't attatch a screenshot because the file is too large  :P

What Android version do you have?

I have android 5.0

Strange, I have 5.1 and I don't have that problem? What device do you have? I can see if it has any issues with immersive mode.
Title: Re: 3.0 Alpha Testing
Post by: Blurbsanime on November 18, 2015, 01:31:23 AM
Wow 3.0 is looking nice! There are some massive improvements.

One problem though. On the latest build, I am having some trouble with immersive mode. The navigation buttons do disappear but for some reason there is a black bar at the bottom of the screen to replace the buttons. I have tried everything in order to fix it, even trying to use gmd immersive mode but it seems to be plastered onto the screen. It cuts off part of the game (the bottom strip)

I thought that I should inform you so here ya go. Keep up the great work, it's coming along very well!

I can't attatch a screenshot because the file is too large  :P

What Android version do you have?

I have android 5.0

Strange, I have 5.1 and I don't have that problem? What device do you have? I can see if it has any issues with immersive mode.

My device is an Asus Memo Pad 7. It seems that the problem is only for the newer builds. I installed one of the older builds and noticed something odd. In one of the older builds, when I open the emulator menu when in game, the game doesn't pause.

If I scroll all the way to the bottom of the menu, the bar disappears. On the latest build, the game pauses when I open the menu and if I scroll to the bottom of the menu the black bar doesn't disappear.

I lowered the resolution of the screenshots so I could attarch them. The top screenshot is an older build and the bottom is the latest build.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 18, 2015, 04:23:20 PM
Wow 3.0 is looking nice! There are some massive improvements.

One problem though. On the latest build, I am having some trouble with immersive mode. The navigation buttons do disappear but for some reason there is a black bar at the bottom of the screen to replace the buttons. I have tried everything in order to fix it, even trying to use gmd immersive mode but it seems to be plastered onto the screen. It cuts off part of the game (the bottom strip)

I thought that I should inform you so here ya go. Keep up the great work, it's coming along very well!

I can't attatch a screenshot because the file is too large  :P

What Android version do you have?

I have android 5.0

Strange, I have 5.1 and I don't have that problem? What device do you have? I can see if it has any issues with immersive mode.

My device is an Asus Memo Pad 7. It seems that the problem is only for the newer builds. I installed one of the older builds and noticed something odd. In one of the older builds, when I open the emulator menu when in game, the game doesn't pause.

If I scroll all the way to the bottom of the menu, the bar disappears. On the latest build, the game pauses when I open the menu and if I scroll to the bottom of the menu the black bar doesn't disappear.

I lowered the resolution of the screenshots so I could attarch them. The top screenshot is an older build and the bottom is the latest build.

Can you make sure that you have immersive mode enabled under settings?
Title: Re: 3.0 Alpha Testing
Post by: Blurbsanime on November 19, 2015, 12:32:01 AM
Wow 3.0 is looking nice! There are some massive improvements.

One problem though. On the latest build, I am having some trouble with immersive mode. The navigation buttons do disappear but for some reason there is a black bar at the bottom of the screen to replace the buttons. I have tried everything in order to fix it, even trying to use gmd immersive mode but it seems to be plastered onto the screen. It cuts off part of the game (the bottom strip)

I thought that I should inform you so here ya go. Keep up the great work, it's coming along very well!

I can't attatch a screenshot because the file is too large  :P

What Android version do you have?

I have android 5.0

Strange, I have 5.1 and I don't have that problem? What device do you have? I can see if it has any issues with immersive mode.

My device is an Asus Memo Pad 7. It seems that the problem is only for the newer builds. I installed one of the older builds and noticed something odd. In one of the older builds, when I open the emulator menu when in game, the game doesn't pause.

If I scroll all the way to the bottom of the menu, the bar disappears. On the latest build, the game pauses when I open the menu and if I scroll to the bottom of the menu the black bar doesn't disappear.

I lowered the resolution of the screenshots so I could attarch them. The top screenshot is an older build and the bottom is the latest build.

Can you make sure that you have immersive mode enabled under settings?

Immersive mode is enabled in the settings.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 19, 2015, 05:35:06 PM

Immersive mode is enabled in the settings.

Can you try different graphics plugins and see if you still get there issue?

Also, under display settings for a specific game, can you try playing around with resolution and scaling? That was something that was changed recently that could be causing that issue.

Try playing with display settings under the general settings as well.
Title: Re: 3.0 Alpha Testing
Post by: Blurbsanime on November 20, 2015, 02:01:12 AM

Immersive mode is enabled in the settings.

Can you try different graphics plugins and see if you still get there issue?

Also, under display settings for a specific game, can you try playing around with resolution and scaling? That was something that was changed recently that could be causing that issue.

Try playing with display settings under the general settings as well.

I have tried everything. Changed the plugins, resolution, I even changed the screen scaling back to original. I also tried switching the screen orientation to reverse landscape to see if it was still there but still no luck.

I tested everything and am still getting the bar at the bottom of the screen. :/ I wonder what is causing it.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 20, 2015, 04:58:03 PM
Just to help us narrow down the problem, do you get it in portrait mode?
Title: Re: 3.0 Alpha Testing
Post by: SuperL on November 20, 2015, 08:10:22 PM
I just got a Shield tablet in my hands the other day, and have only now been able to reap the benefits of the new GlideN64 plugin. I'm using the latest autobuild.

For the most part, the games run fantastic. I have never seen Donkey Kong 64 running so good on Android, and Mario 64 and Mario Kart are just about flawless.

However, Smash Bros., Paper Mario and Yoshi's Story seem to have regressed. They're not running as fast as they used to, and audio is suffering. Even with all the relevant settings turned down, and with the CPU usage at its highest.

IS there a setting I can tweak? Or will this be fixed in a future autobuild?
Title: Re: 3.0 Alpha Testing
Post by: retroben on November 20, 2015, 10:01:33 PM
GLideN64 can be intensive on performance when in higher resolutions,so if you set it to 640x480 for all games,it should run much faster.
Also,if you use HW Lighting or Bloom,they will also hurt performance,and in some games,HW Lighting will trigger a crash.
The 3.0 and 3.1 variants are a bit slower due to more functionality and perfection while the 2.0 variant is faster and lacks the better rendering and has many issues.

I just realized,why isn't there an extra checkbox type for using the defaults for all games in a custom profile?
Such as unchecked is off and checked is on like they normally are,and a filled square uses the ROM Default.
Title: Re: 3.0 Alpha Testing
Post by: Blurbsanime on November 21, 2015, 12:16:20 AM
Just to help us narrow down the problem, do you get it in portrait mode?

I don't seem to get the problem with portrait mode, only landscape mode.
Title: Re: 3.0 Alpha Testing
Post by: SuperL on November 21, 2015, 12:36:28 AM
GLideN64 can be intensive on performance when in higher resolutions,so if you set it to 640x480 for all games,it should run much faster.
Also,if you use HW Lighting or Bloom,they will also hurt performance,and in some games,HW Lighting will trigger a crash.
The 3.0 and 3.1 variants are a bit slower due to more functionality and perfection while the 2.0 variant is faster and lacks the better rendering and has many issues.

I just realized,why isn't there an extra checkbox type for using the defaults for all games in a custom profile?
Such as unchecked is off and checked is on like they normally are,and a filled square uses the ROM Default.

That's the problem. Smash, PM, and Yoshi are slower compared even to GlideN64 3.0 and 3.1 on earlier builds. Even by the standards set by past autobuilds, they're running particularly slow.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 21, 2015, 01:20:05 AM
GLideN64 can be intensive on performance when in higher resolutions,so if you set it to 640x480 for all games,it should run much faster.
Also,if you use HW Lighting or Bloom,they will also hurt performance,and in some games,HW Lighting will trigger a crash.
The 3.0 and 3.1 variants are a bit slower due to more functionality and perfection while the 2.0 variant is faster and lacks the better rendering and has many issues.

I just realized,why isn't there an extra checkbox type for using the defaults for all games in a custom profile?
Such as unchecked is off and checked is on like they normally are,and a filled square uses the ROM Default.

That's the problem. Smash, PM, and Yoshi are slower compared even to GlideN64 3.0 and 3.1 on earlier builds. Even by the standards set by past autobuilds, they're running particularly slow.

Try making a custom profile and playing around with the frame buffer settings. Enabling certain frame buffer settings can really slow things down. Also make sure that "EnableCopyColorToRDRAM" is set to "2"
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 21, 2015, 06:01:28 PM
Hmmm, it seems like a few people on Reddit are complaining about performance issues as well, even with the Glide64 fast profile. See here:

https://www.reddit.com/r/EmulationOnAndroid/comments/3tpawv/speed_issues_with_mupen64ae/

The performance issues go away if they role back to the July version of the app.

I wonder if something in the core of slowing things down since changing the graphics plugin has no effect.
Title: Re: 3.0 Alpha Testing
Post by: retroben on November 21, 2015, 09:33:29 PM
Ya gotta love reddit. ;D (and the unexpected CENA thread too)
...

One big change after the July 7th master build is the new sidebar merging.
Maybe there is a wait trigger for sliding it into view or something else making emulation slower.
Or the remaining ghost menu on the right side if you press the menu key a few times is causing it.
It might be some changes to code like constant checking of certain conditions,impacting performance.

Could the Castlevania,Glover,or Bomberman crash fixes be the cause of excessive slowdown?
Sadly,fixing game crashes will mostly always cause a steep drop in performance,especially when related to a global function.

I think its time to increase performance with heavy optimizations,tweaks,and possibly some optional and potentially unstable speed hacks.
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on November 22, 2015, 12:19:50 PM
  IDK, i tried the July version linked in the reddit topic mentioned above, and then compared it to the 2015-11-04 build.
On the same device, with the same settings (global and per game) and don't see a speed increase?

IMHO people should just experiment with the settings.

For me, i get the best speed with settings like
- rendering resolution (should be @640X480 for heavier games, or if you are on a small screen phone, for all games, really... for conker i set it 360X480, looks ok on my 4 inch phone screen...)
- Flicker reduction hack (OFF for better performance)
- Audio plugin (mupen64plus-audio-sdl, 2.0)
- Audio buffer size (Default for better speed)
- Visual feedback (animate joystick OFF)

To add to the above, programs like GL Tools can also give a small boost if you know how to mess with them and have a rooted device.

IDK...
Title: Re: 3.0 Alpha Testing
Post by: retroben on November 22, 2015, 02:38:10 PM
I tried it with "Flicker Reduction" disabled,and it did not help the fps.
Also,I am stuck on buggy Qualcomm/Adreno,so visuals clip through walls,and it actually went slower on Banjo-Tooie (GLideN64 2.0 variant) in some spots due to more stuff being shown.
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on November 27, 2015, 11:58:39 AM
 Why do you use GLideN64 GLES 2.0 variant, it's buggy.

 Glide64-Fast (10th anniversary) is better for the vast majority of games, and even on my crappy phone (1.2 GHZ dual core. Adreno 302) , many games are playable and enjoyable. Great work!

Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 27, 2015, 12:12:09 PM
Why do you use GLideN64 GLES 2.0 variant, it's buggy.

 Glide64-Fast (10th anniversary) is better for the vast majority of games, and even on my crappy phone (1.2 GHZ dual core. Adreno 302) , many games are playable and enjoyable. Great work!

Wow, that sounds pretty old, what phone is that?
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on November 27, 2015, 04:34:52 PM
http://www.gsmarena.com/sony_xperia_e1-5966.php

and my tab is
http://www.gsmarena.com/lg_g_pad_8_0_lte-6575.php
Title: Re: 3.0 Alpha Testing
Post by: fzurita on November 28, 2015, 11:37:28 AM
At least the Android version is greater than 4.0. It seems like we are planning to drop support for less than 4.0 pretty soon.
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on December 09, 2015, 05:18:58 PM
New update 12/09 is out. I tested it and it seems smoother to me (i get higher fps count in games like Conker & Top Gear Rally)
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 09, 2015, 11:35:10 PM
I seem to be getting better speeds using 12/09 on Banjo-Tooie (with lag fix and no frameskip codes) as it is staying at 60fps on Rice in every area except that oil rig ledge,even HailFire Peaks' entrance runs at a full 60fps!

For anyone else wanting to perhaps test on a rooted Shield TV with the GPU boosted to full power (1Ghz),the codes are 8003F4F2 000D and 8007913F 0001 respectively.

GLideN64 3.0 and 3.1 run quite slow with Tooie in comparison to Rice on an unrooted Shield TV.
I can't remember if more updates have been made to GLideN64 somewhat recently,but I think there is updates.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 10, 2015, 09:35:41 AM
I find this odd because the only change made to the 12/9 build was an updated auto build script. No code changes. :o
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2015, 08:07:30 PM
what about the dependencies added on the earlier build that same day?

Maybe just using my Shield TV device broke it in and made stuff run more smoothly.

I still hope we can see if Yongzh would ever help with Mupen64Plus AE,at least teaching how to make native coding for plugins work with a huge performance increase or if donations could be made for him to work on it upon agreement and whatever amount for the goal is achieved.

Also,knowing that N64oid is no longer on SlideMe makes this an opportunity to get funded in return for his skills of improving performance and visual stability for applying native plugin coding to Mupen64Plus AE.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 10, 2015, 10:51:06 PM
I don't see how since that auto build script doesn't do anything until Paul copies it to his auto build server.

Were you running with the Nov 15 build before by any chance?
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 10, 2015, 11:10:03 PM
Yeah,the November 15th build before getting that 12/09 update.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 14, 2015, 01:40:28 AM

Immersive mode is enabled in the settings.

Can you try different graphics plugins and see if you still get there issue?

Also, under display settings for a specific game, can you try playing around with resolution and scaling? That was something that was changed recently that could be causing that issue.

Try playing with display settings under the general settings as well.

I have tried everything. Changed the plugins, resolution, I even changed the screen scaling back to original. I also tried switching the screen orientation to reverse landscape to see if it was still there but still no luck.

I tested everything and am still getting the bar at the bottom of the screen. :/ I wonder what is causing it.

I think I found your problem. I have committed a fix.

My son got a tablet for his birthday which experienced very similar symptoms to yours.

Please try the latest build and make sure immersive mode is enabled.
Title: Re: 3.0 Alpha Testing
Post by: Blurbsanime on December 15, 2015, 01:48:16 AM

Immersive mode is enabled in the settings.


Can you try different graphics plugins and see if you still get there issue?

Also, under display settings for a specific game, can you try playing around with resolution and scaling? That was something that was changed recently that could be causing that issue.

Try playing with display settings under the general settings as well.

I have tried everything. Changed the plugins, resolution, I even changed the screen scaling back to original. I also tried switching the screen orientation to reverse landscape to see if it was still there but still no luck.

I tested everything and am still getting the bar at the bottom of the screen. :/ I wonder what is causing it.

I think I found your problem. I have committed a fix.

My son got a tablet for his birthday which experienced very similar symptoms to yours.

Please try the latest build and make sure immersive mode is enabled.

Yes the problem is fixed. Thanks and good work :D
Title: Re: 3.0 Alpha Testing
Post by: Haz on December 17, 2015, 02:09:52 AM
@Haz  I played for 2 or 3 hour donkey kong 64 few weeks ago and I reached the first level boss, won several minigames, and set free diddy kong. It has several bugs, but in my opinion is almost playable, I cant assert the game is playable 100% because I have not completed it, or at least play hardly.

It's at one specific part...trying to photograph a fairy within the gloomy galleon level. I can upload a save state if people want to see instantly what I'm talking about

Appreciate all the developers are super busy - but was wondering if this bug has been addressed in the new Alpha release?
Title: Re: 3.0 Alpha Testing
Post by: codequest on December 20, 2015, 06:21:38 PM
Just tried the latest alpha.
I can't seem to add games to the library? I go and select the zip, scans, but they don't display in the library.
(I'm using nvidia shield tV)

Also, can you explain how to enable the texture pack option, and where to load them?

thank you.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 20, 2015, 06:24:44 PM
Just tried the latest alpha.
I can't seem to add games to the library? I go and select the zip, scans, but they don't display in the library.
(I'm using nvidia shield tV)

Also, can you explain how to enable the texture pack option, and where to load them?

thank you.

Are you selecting a single zip file?

Also, could you share a log cat right after this happens? You can do this on the main app menu under about->logcat->share.
Title: Re: 3.0 Alpha Testing
Post by: codequest on December 20, 2015, 08:24:39 PM
hmmm.
doesnt seem to save..
once i click on share, it goes to select the path on es file explorer.. once done, the file is not there.
another bug?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 21, 2015, 12:08:32 AM
hmmm.
doesnt seem to save..
once i click on share, it goes to select the path on es file explorer.. once done, the file is not there.
another bug?

I don't think it's a bug. Don't share with ES File explorer. Try sharing with GMail instead and then e-mail it to yourself. Then from a desktop web browser, copy and paste the contents of your e-mail in this thread.
Title: Re: 3.0 Alpha Testing
Post by: huyn54 on December 24, 2015, 01:48:25 PM
Is there a way to revert the multi controller menu to the way it was before. It seems like the program automatically decides how many controllers the games need. An example would be zelda games and showing only one controller in the settings. For games like golden eye, four controllers do show up to be mapped and set up. However, when I try pokemon stadium games, the program only shows two controllers will work in the game. The old mupen let me turn on each individual controller so I could turn on 2-4 controllers, but now it is automatic. Is there a way to fix this?
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 24, 2015, 06:17:45 PM
One way to fix it would be to edit a file in the Android directory under each game name with the controller count you desire to make that many appear,it can be annoying because the text length is pretty large.
I had to do this for the debug versions of Zelda Ocarina and Majora's Mask before since they require detecting all four controllers to use all P1 debug features,for example,L+R+Z on the P1 controller is for selecting areas and needs the other controllers enabled,but only requires you to make a dud profile for the three other controllers to be activated.
Title: Re: 3.0 Alpha Testing
Post by: huyn54 on December 24, 2015, 09:50:50 PM
May I ask which file? I go to gamedata and coreconfig folder. I then try to look for the multi controller setting in the mupen64plus.cfg file but am unable to find anything. Do I add a line that forces 4 players?
Title: Re: 3.0 Alpha Testing
Post by: retroben on December 25, 2015, 02:49:41 AM
Sorry for not responding for so long,it is in the mupen64plus.ini found in
/sdcard/Android/data/org.mupen64plusae.v3.alpha/

The first game visible has the "Players" command with"=4" as the value,so it should be easy to understand what to do for the game of choice after finding it in the large list.

You type in...

Players=4

Under the game and under the last option and save changes,then it should work for making the controller slots appear.
Title: Re: 3.0 Alpha Testing
Post by: huyn54 on December 25, 2015, 12:32:44 PM
Took me a couple tries, but I just replaced all of the players=2 to players=4 with a text editor so I didn't have to look. Thank you for your help. I never post on forums for help because I can usually find it somewhere, but I had to this time. So thank you again.  :D
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on January 30, 2016, 05:45:32 PM
  Hello and a great 2016 to everyone.

I have been downloading new autobuillds and playtesting them for the past 2 months or so and the work being done, tinkering and improving this emulator is evident. From small nooks and crannies (per game config, number of auto savegames per game, menu slider) to improved performance, i want to thank all the developers for their contributions and improvements.
Even hacks play very well on this emu, which is great in its' own right, as there is a large number of Mario 64 and GoldenEye projects worth playing.


  I would also like to propose a couple of suggestions:

1. Have the menu slider be optional. Personally, i have assigned my camera button to trigger the menu and since i game on a 4 inch screen, i sometimes accidentaly trigger the menu slider while touching the left side of the screen (analog and z are assigned there by me). Having an option on the "display" options to disable the slider if you can enter the menu via a button would be nice imho.

2. Have an ''audio off'' option in each game's separate options. While many games play very well speedwise, it would help in some lagging ones like Top Gear Rally.

  Thanks again and keep up the good work!
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on February 03, 2016, 08:03:31 AM
  Could Jabo Direct3d plugin be supported by mupen64?

 I find it faster in some games on Project64 compared to other plugins. It also does not freeze in some romhacks (e.g. SM64 Green Stars) unlike all other plugins.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on February 03, 2016, 08:26:30 AM
That would be a tough plugin to port over since Android doesn't support Direct3D.
Title: Re: 3.0 Alpha Testing
Post by: nakata6790 on February 03, 2016, 03:32:31 PM
Oh, i see.
Thank you for answering my question.
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on February 14, 2016, 04:32:47 PM
On the newest alpha Feb 14 build the app crashes when I try to go into manage plugins menu and try to change the plugin so i can edit the configurations of  it I am on nvidia shield portable tegra 4 kit kat
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on February 14, 2016, 04:40:43 PM
Here screenshots
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on February 14, 2016, 04:42:06 PM
One more pic
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on February 14, 2016, 04:44:13 PM
Also turok 2 and bomberman64 don't run again
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on February 14, 2016, 04:48:10 PM
Scratch bomber man that works but turok 2 does not
Title: Re: 3.0 Alpha Testing
Post by: fzurita on February 14, 2016, 04:57:45 PM
Thanks for the report, I'll look into the crash, in the mean time, you can revert to an older build.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on February 14, 2016, 05:21:12 PM
One more pic

Can you send me your crash log files? They are at this location /sdcard/mupen64plusae-v3-alpha/CrashLogs/
Title: Re: 3.0 Alpha Testing
Post by: fzurita on February 14, 2016, 05:38:32 PM
Ok, I think I see the issue already. Can you try the next auto build within a couple of hours?
Title: Re: 3.0 Alpha Testing
Post by: Metalmusic3000 on February 15, 2016, 01:35:29 PM
Works now no crashing sorry didn't see the message

Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 04, 2016, 07:38:23 PM
Hi all -

I recently bought a new fire tv 2 and tried to setup a multiplayer game of mario kart with no success.  For some reason, the multi-player profiles are not saving and it is maddening.  I will access the multi-player menu, define the controllers, restart and nothing is saved (receive menu about defining controllers).  If I used just on controller it works fine.  For your reference, I am using a fire tv controller and a usb n64 controller (generic).

I've also disabled controller 3/4 with no success.  Any ideas  Using the latest auto build from 3/3.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 04, 2016, 10:04:49 PM
I have tried this recently with no issues. Nothing has changed as far as I know. After assigning a controller to each player under general settings, are you sure you are clicking ok instead of just backing out of the screen?
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 06, 2016, 03:15:39 PM
Yep, definitely clicking ok and not just backing out of the screen.  I've defined the controllers in the general settings and also before starting the emulation with no luck.

I've uninstalled the app, deleted all the data via es file explorer and re-installed but still no luck.  Whats odd is that the app will recognize the controllers individually in single player mode but for some reason won't save the setting when defining multiple.  Maybe this is a fire tv issue?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 06, 2016, 04:19:30 PM
Maybe it's a fire TV issue. Can you share your logcat? Click on help on the side bar and then click on logcat.
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 06, 2016, 04:59:13 PM
Hm.. well that's odd.  When I try to save the logcat through app using es file explorer it doesn't save to the directory chosen.  Is the logcat stored somewhere?  If so, I can try to pull it using adb.
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 06, 2016, 05:29:05 PM
Never mind, found out how to do it through adb but it's too large to attach (700kb).  Any preference on how to share?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 06, 2016, 08:52:23 PM
Pastebin or google drive
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 07, 2016, 06:35:47 PM
Pastebin or google drive

Here ya go
Code: [Select]
https://drive.google.com/file/d/0B2lept674o6oekxJUGFNTmJRTmM/view?usp=sharing
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 07, 2016, 07:57:28 PM
Thanks, I'll take a look at this.
Title: Re: 3.0 Alpha Testing
Post by: asturias3636 on March 09, 2016, 08:24:15 AM
 :DHello, I'm using mupen64 (autobilds) in a xiaomi redmi note2, I do not get it to work the impossible mission ..., the emulator improved a lot!, greetings.

EDIT: sorry, if it works the game Mission Impossible, was the problem of rom was wrong ... great job !!! :)
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 12, 2016, 09:21:05 AM
Thanks, I'll take a look at this.

Hi fzurita, have you had a chance to look at the log yet? 
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 12, 2016, 10:55:31 AM
Yep. Your logs didn't show anything unusual. Although, I just committed a fix that may fix the issue. It should show up in the master  branch auto build within 30 minutes. When you get a chance, can you try it out and let me know how it goes?
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 12, 2016, 08:01:25 PM
Eh, sadly the same problem.  I uninstalled the previous version via the fire tv interface, reinstalled using db - same issue when trying to save in global settings and at the game level. 
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 12, 2016, 08:57:49 PM
Hmmm, this will be a tough one to investigate without the actual device. I suspect it's something specific to the Fire OS and shared preferences.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 12, 2016, 11:15:43 PM
Eh, sadly the same problem.  I uninstalled the previous version via the fire tv interface, reinstalled using db - same issue when trying to save in global settings and at the game level.

I made another commit. I'm really throwing darts and hoping something sticks. Please give it a shot when you get as chance and let me know how it goes.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 17, 2016, 06:27:41 PM
Eh, sadly the same problem.  I uninstalled the previous version via the fire tv interface, reinstalled using db - same issue when trying to save in global settings and at the game level.

I was able to borrow a Fire OS tablet and it exhibited the exact same issue. I was able to borrow it for long enough to fix it. Try the latest auto build, it should be fixed.
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 18, 2016, 11:23:17 AM
Quote
I was able to borrow a Fire OS tablet and it exhibited the exact same issue. I was able to borrow it for long enough to fix it. Try the latest auto build, it should be fixed.

You are my hero, thank you very much. Can you share what the solution was?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 18, 2016, 03:05:33 PM
Quote
I was able to borrow a Fire OS tablet and it exhibited the exact same issue. I was able to borrow it for long enough to fix it. Try the latest auto build, it should be fixed.

You are my hero, thank you very much. Can you share what the solution was?

The way we were identifying controllers was the issue. When we were getting the device descriptor for a gamepad in the fire OS, it had a ":" character in it. We were using that exact same character as a delimiter when saving the mappings into settings. That was causing issues when we were trying to read back saved controller mappings.

To fix, I replaced the ":" delimiter when saving mappings with a "$". This should work fine as long as there are no device descriptors that use the " $" character.
Title: Re: 3.0 Alpha Testing
Post by: d3n3 on March 20, 2016, 11:22:41 AM
Very interesting.. Well thank you again for troubleshooting the issue.  I'm now able to beat the wife in mario kart without having to hook up a pc!  Thanks again.
Title: Re: 3.0 Alpha Testing
Post by: the COOL Dad Man on March 28, 2016, 07:55:18 PM
Using the latest nightly (maybe the 2nd latest) and can ALMOST get Paper Mario working perfectly. It's the damn "star dialogue" problem I'm sure a lot of you are aware of. The only plugin that seems to work with their special stupid "twinkly" font is Gliden64 alpha. But as soon as you pull up a menu, the screen goes crazy with plaid corruption artifacts.

On my PC, Mupen64plus with the default Rice plugin on default settings seems to work perfectly. Are there any settings or tweaks I can copy from the PC version to my Android config on my Fire TV (gen1)?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on March 28, 2016, 09:29:57 PM
Fire TV may be limited to GL ES 2.0. That may make things difficult since the GLideN64 plugin for GL ES 2.0 is not as well maintained as the 3.X versions.

Your best bet is to keep trying different video plugins until you find one that works the best. Also, you could file a bug report upstream here for GLideN64:

https://github.com/gonetz/GLideN64/issues

Although, it may take a while to get fixed since GL ES 2.0 is so limited. If you do file a bug report, please make sure you specify that it's the 2.0 variant and what device you are using.
Title: Re: 3.0 Alpha Testing
Post by: rafar on March 31, 2016, 01:57:55 PM
Exists the possibility that transfer pack works and it could load a gbc rom to play pokemon stadium? it would be amazing, on project 64 for pc, this can do it.

Title: Re: 3.0 Alpha Testing
Post by: grmilbrand on April 01, 2016, 09:12:25 AM
Hi Paul and all!
I installed the Mupen64 3.0 nightly from 3/31/16 on my Shield Android TV. I love it! The UI is so perfect on the Shield. And the mappings have worked flawlessly so far on the few games I've played.
Only thing I can't figure out is what the launch argument to use in Rom Collection Browser would be. I'm using the code from the previous install(2.4.4) from the Google Play store:
Code: [Select]
-c 'am start --user 0 -n paulscode.android.mupen64plus.free/paulscode.android.mupen64plusae.MainActivity -a android.intent.action.VIEW -eu Uri "file://%rom%" &amp;&amp; am start --user 0 -S -n paulscode.android.mupen64plus.free/paulscode.android.mupen64plusae.PlayMenuActivity'It says launching but then just stops.
Could anyone help me solve this, please?
Thanks!
Title: Re: 3.0 Alpha Testing
Post by: fzurita on April 01, 2016, 02:59:14 PM
Try this:

-c 'am start --user 0 -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%" &amp;&amp; am start --user 0 -S -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity'

Let me know how it works. If it doesn't I'll dig further to find the right activity to use.
Title: Re: 3.0 Alpha Testing
Post by: grmilbrand on April 03, 2016, 09:05:07 AM
OK, so I tried these:

-c 'am start --user 0 -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%" &amp;&amp; am start --user 0 -S -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity'

-c 'am start -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%" &amp;&amp; am start -S -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity'
(without user 0)

&

start -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%"
(my Shield is non-root version)

*all just said launching without any further action.
Title: Re: 3.0 Alpha Testing
Post by: av777 on April 04, 2016, 12:30:40 AM
How about testing gamepad response time from hadware to emulator. Show some specs.
Title: Re: 3.0 Alpha Testing
Post by: King3 on May 22, 2016, 11:01:32 AM
im using the latest build from auto builds, Tsumi to Batsu (Sin and Punishment) japan works just fine but when i use the english patched rom http://www.epforums.org/showthread.php?94613-Nintendo-N64-Mod-Sin-And-Punishment-(T-EN_Zoinkity)-v1-0   Glide64-Accurate runs perfect just missing some intro segments but all audio play, GlideN64-GLES-2.0 runs flawless no missing into segments nothing, just the framerate stutters really bad.thanks for any feedback
Title: Re: 3.0 Alpha Testing
Post by: fzurita on May 22, 2016, 09:31:07 PM
Have you tried turning off frame buffer emulation?
Title: Re: 3.0 Alpha Testing
Post by: King3 on May 23, 2016, 12:44:10 PM
under what menu is frame buffer unchecso i can check
Title: Re: 3.0 Alpha Testing
Post by: fzurita on May 23, 2016, 12:58:04 PM
You would have to create a new emulation profile from the side bar. You can click on GlideN64-GLES-2.0 from there, select copy, then adjust the parameters from there. If you want, you can set it as the default from there or select that profile from each game.
Title: Re: 3.0 Alpha Testing
Post by: King3 on May 23, 2016, 02:00:24 PM
i unchecked frame buffer as you said game runs fine just graphic glitches and missing textures
Title: Re: 3.0 Alpha Testing
Post by: King3 on May 26, 2016, 01:48:11 PM
the original japan sin and punishment works fine just the english mod messes up most likey because it a mod,ill start testing confirmed roms from here on out.
Title: Re: 3.0 Alpha Testing
Post by: Shodan09 on June 29, 2016, 02:51:04 PM
Hi guys, thanks for all the work you've put in to this project. I'm not sure if this will be of any help to you but I just wanted to let you know that on a galaxy s7 the new 3.1 plug in gives a black screen error. Music and sound still work fine and the games are actually running in the background - you just can't see anything.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on June 29, 2016, 03:44:13 PM
Try the 3.0 version. I think that one works.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 28, 2016, 03:12:12 AM
Hey everybody! I've been following this forum for a while now and have been testing all the different builds up to this point. This emulator has really come a long way and I hope to see an official update released to the Play Store soon. Is there anyway I can help the project progress any further?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 28, 2016, 06:22:12 AM
I have placed a beta version in the playstore: https://play.google.com/store/apps/details?id=org.mupen64plusae.v3.fzurita

I'm keeping it up to date with the latest changes.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 28, 2016, 07:38:41 PM
That's good. I was also curious to know if constant frame drops are common (despite having frameskip on or off with all plugins)? I'm using an LG G4 with Marshmallow if that helps. Games seem to run pretty good otherwise.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 28, 2016, 11:29:15 PM
It depends a lot on the plugin. Which plugin is giving you frame drops?
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 29, 2016, 04:51:53 AM
All video plugins give me frame droping on the ALPHA version of the emulator. When I switch sound plugins though (switching from sles to sdl), the frame dropping improves quite a bit. To be honest, the sound latency is unfortunately really noticeable with sdl. It seems to be an almost 1 second delay no matter how I tweak the settings. I am used to sound latency when dealing with Android emulation, but this seems to be a bit abnormal.

I then decided to switch to the BETA version on the Play Store. Instead of getting frame drops with the sles sound plugin, I just got major slowdown. Switching to the sdl sound plugin along with putting the latency at default improved performance just like in the ALPHA version of Mupen. The sdl plugin seems to have a problem with not changing latency, at least at first. When I keep going in the menus to tweak the the plugin, the latency eventually does change. The latency is just as exaggerated in this BETA version of Mupen (feels like almost a second).

Another thing to note with this BETA of Mupen is that the Glide 64 video plugin seems to only work the very first time I install the app. After I run a game one time and come back to it, the graphics are a garbled mess. The only solution it to switch to Glide N64. Not a huge deal, but it should be noted.

So it seems that the ALPHA version of Mupen is more stable for me at this time. However, all the issues I'm experiencing could just be  on my particular phone.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 29, 2016, 06:38:07 AM
Interesting, so SDL audio fixes frame drops but has mayor latency issues. This seems to be specific to your phone.

Using the beta version, can you go into sound settings and disable synchronize audio and video?
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 29, 2016, 10:29:42 PM
Disabling audio and video sync just makes the sound skip constantly. It gets more frequent depending on the latency settings.

The latest BETA version still has the garbled graphics issues with the Glide 64 video plugin. Gln 64 has the same problem, which means I'm limited to using Glide N64 and Rice.

Here's what GoldenEye looks like using Glide 64:
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 30, 2016, 06:44:32 AM
I think I may have clue as to what is up with your phone with the corrupt graphics in other plugins,

Also, as for the audio, can you try SLES ”FP audio” mode? It's under audio settings.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 30, 2016, 06:47:38 AM
UPDATE: I found a solution!!

Ok, so I finally found out how to get Glide 64 working properly again. I originally had my video resolution set to 360p so I could get the best performance possible. Apparently, Glide 64 doesn't like that particular resolution for some reason, so I set it back to 480p and it's back to normal again! Now that I have Glide 64 working again, I'm able to play games without hearing any skipping sound. The way I did that was by disabling video/audio sync (while using the SDL sound plugin), setting the latency to "Low-latency,"and using the frameskip option provided in Glide 64! I now have reasonably smooth gameplay with only minimal sound latency!

Glide N64 doesn't have a frameskip option, so I was forced to hear all the skipping sounds (or set the latency REALLY high). Now that I figured out how to get Glide 64 working again, the plugin's frameskip option just skips over whatever slowdown was originally there!

Moral of the story is to leave the resolution at 480p.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 30, 2016, 06:51:34 AM
OK, that's good. I'm still curious about what is going on with your phone, it's so much different than other phones.

While using GLideN64, does using FP audio make a difference?

Also,  can you try this  early build? http://www.paulscode.com/source/Mupen64Plus-AE/AutoBuilds/Mupen64PlusAE_master_201602150102_9239aa0.apk

This build is before we added threaded SLES audio. I'm curious if that is what is causing the issues with your phone. Make sure you try it with SLES and GLideN64.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 30, 2016, 07:03:11 AM
Also, while in game. Can you try setting the speed limit to 250% with GLideN64. Is it able to speed up go faster? And one final question, what game are you using to try this out with?
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 30, 2016, 07:42:45 AM
FP audio doesn't seem to really make a difference as far as I can tell.

It is able to speed up when it's set to 250%. It does seem to fluctuate a little bit though (music/tempo goes faster and slower). There were small fluctuations even before I messed with the speed too. That's one of the reasons why I changed the sound plugin. It didn't matter if I had the audio synced or not either.

I've been testing mainly on GoldenEye and Rush 2. I also did a bit of testing on Starfox 64.

I'll be sure to try out that build as soon as possible and let you know. Oh by the way, GLN64 is working properly again too since I bumped the resolution back up to 480p.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 30, 2016, 08:28:28 AM
Cool
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 30, 2016, 07:36:25 PM
Ok.

So with that earlier ALPHA build using SLES audio and Glide N64, I was getting a lot of crackling/skipping. It didn't matter if I had the audio synced or not. I also tried tweaking the buffer size and number, but it didn't seem to make a difference. I tested it using GoldenEye, Rush 2, and Banjo Kazooie.

I'm not sure if this matters or not, but with GoldenEye (using Glide N64), some of the textures were just plain white.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 30, 2016, 10:47:16 PM
I really appreciate you testing the older version. With the older version with SLES audio, if you set the number of buffers to maximum and the buffer size to the maximum as well, do you get audio crackling/skipping?

Also, with this older version, does the game itself skip or is it just the audio skipping?

I'm starting to think that it's the threaded SLES audio that is causing the problem. I can add an option to not use the threaded audio in the newer version.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 30, 2016, 11:40:22 PM
LarryL please try this test build with non-threaded SLES audio:

https://drive.google.com/file/d/0B57Ioy26LWegbXZLbXluZE9lLUE/view?usp=sharing

Can you tell me if it improves issues?

Please try GLideN64 with it.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 31, 2016, 02:02:28 AM
Ok.

So I tweaked the SLES plugin buffer size and number (2048 and 5) while using Glide N64. There's no skipping or crackling at all as long as the sound is not synced. When I sync the sound, I start to hear crackling. If I had to guess whether it was the game or just the sound skipping, I'd say it was the game since frameskip (using the other plugins) is able to skip over it. Basically, if the sound latency is set to as high as possible, there doesn't appear to be much slowdown and no need for frameskipping.

I'll try that test build and let you know ASAP.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 31, 2016, 03:00:40 AM
fzurita, the test app version is still code 46, correct? I got confused because I didn't see any difference to the Play Store version lol.

Anyway, if that's the case, there is still the slowdown/skipping when using SLES with Glide N64. To be honest, there's similar slowdown while using all the video plugins. It's just that Glide 64 and GLN 64 can actually hide it thanks to the frameskipping function. I don't really see or hear any slowdown then. When I switch to SDL and Glide N64, the slowdown seems to decrease a little bit (at least with GoldenEye), but not enough to be all that enjoyable.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on July 31, 2016, 05:52:55 AM
OK. Goldeneye is one of those games that is slow in GLideN64. What about super Mario 64?
Title: Re: 3.0 Alpha Testing
Post by: LarryL on July 31, 2016, 07:21:16 AM
Yes, Super Mario 64 runs great with Glide N64.
Title: Re: 3.0 Alpha Testing
Post by: retroben on July 31, 2016, 12:15:05 PM
Great to see another tester and finally the option to disable threaded on SLES for more customization,maybe that will fix the erratic pacing where music speeds up and slows down even with no lost fps,Zelda Ocarina is mostly apparent with this issue causing music to turbo occasionally.

I really need to push myself to get the Play Store copy now so I can stay up to date with less trouble for ya,fzurita.
Edit: I left a (5 star) silly review for you to enjoy.
Title: Re: 3.0 Alpha Testing
Post by: retroben on July 31, 2016, 01:02:14 PM
Edit: Play Store version BTW before the choice of single thread SLES.
Found something that causes dreadful frame-drops at least on GLideN64 with Banjo-Tooie! 8o Just set SLES to synced smallest buffer size and count (128 size and 2 buffers) and try 800154E3 0001 8003F4F2 000D 8007913F 0001 with the following GLideN64 profile settings for best performance...

Legacy Blending=on
Noise,LOD,LightingPerPixel=off (or LOD on might be faster)
Framebuffer=on (needed for textures)
Color to RDRAM=off (faster from less of a load to deal with such as effects and zoomed egg shots)
Depth Buffer=off

Just move the camera around and it drops frames like crazy. Also try to get into an area with the fastest performance so it doesn't cause slowdowns,such as the Jinjo Village corner with the sand,against the wall for much less level polygon drawing which reaches 200% speed (120fps/120VI) for me on fast forward.

Smooth 60fps Hack "Banjo-Tooie (U)"
800154E3 0001
8003F4F2 000D
8007913F 0001
Prevents CountPerOp frame chops and prevents the slowdown then forces 60fps to ensure max smoothness.

Edit2: Buffer settings don't matter,it still drops frames all the same at 2048 and 50 for maximum buffers when synced,and even still desyncs by a lot with that enabled.

Edit3: Guessing LLE doesn't have Vulkan for obvious reasons,hope it can be figured out and run tremendously fast.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 01, 2016, 08:58:22 AM
Nope, LLE mode is VERY slow with GLideN64. It's not optimized at all. I'm trying to port the libretro Angrylion over, maybe it will run faster.

After I port the libretro Angrylion, I will port over paraLLEl.
Title: Re: 3.0 Alpha Testing
Post by: retroben on August 01, 2016, 01:41:14 PM
There's a problem in your plan for porting Angrylion.
I can't get that plugin to ever run on RetroArch regardless of my settings,it just causes hanging on my end.
The LLE mode may ironically be missing on Android despite the plugin being selectable and CXD4 running fine on its own.

Edit: Just tried it again and it still refuses to work,SM64 was the game I tried for maximum compatibility.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 01, 2016, 02:43:26 PM
I was able to get LLE mode working with CXD4 and GLideN64. I don't see why it wouldn't work with CXD4 LLE and Angrylion.

It may be a problem on how retroarch decided to do things. I'm going to keep going until I get stuck.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on August 02, 2016, 04:15:28 AM
Hey retroben, did I read correctly that you have a 60fps hack of Banjo Tooie? I'm guessing I'd have to input those numbers into the cheat section, correct? Sorry if I sound ignorant lol. I was just curious on how that works.
Title: Re: 3.0 Alpha Testing
Post by: retroben on August 02, 2016, 10:04:39 PM
;D
No Frameskip (60fps)
8007913F 0001

It makes it indeed run at 60fps but not without its issues making much of the missions unplayable,so its only good for a mostly complete game where all of the cutscenes have played out,but its still really great for messing around with other Gameshark codes to do various extra things for added fun.

There's also a couple other codes that make it even stronger such as the "lag fix" address which messes up the JiggyWiggy Challenge timer and another code that forces it to not drop frames if any slowdowns do occur without using the lagfix code.

Lagfix
8003F4F2 000D

Smoother Framerates
800154E3 0001

Enjoy!

Edit: Go to manage cheats,add new or advanced cheat,enter them in the correct fields,then hit OK when done entering each code,it saves automatically after exiting the cheat manager,then you enable that cheat in the list with its checkbox.

Warning: there is a bug when updating that cause the wrong cheats to be enabled which could cause unwanted results.

Edit2: Yeah,please fzurita,try to get this issue fixed,its why I ended up with Chunky Kong having infinite coins,spoiling it when I collected another one and saw that I had hundreds,other much worse things could happen if certain cheats become enabled such as trashing a save file with the item codes for both Zelda games.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 03, 2016, 08:57:58 AM
Hmm.... Interesting. It only happens when updating? It doesn't happen when creating a new cheat?

I thought I made it so that if you added/modified a new cheat, all existing cheats got cleared. That didn't happen?
Title: Re: 3.0 Alpha Testing
Post by: retroben on August 03, 2016, 10:38:03 PM
Enabled codes stay enabled between updates,so it happens because they are still checked and the positions are re-arranged,so it makes the enabled positions end up off-set from their original spots.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on August 04, 2016, 02:08:11 AM
I'll have to try that hack out at some point. Thanks!
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 04, 2016, 03:00:53 AM
Enabled codes stay enabled between updates,so it happens because they are still checked and the positions are re-arranged,so it makes the enabled positions end up off-set from their original spots.

Ok, that's an easy fix.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 06, 2016, 05:29:12 AM
I just checked it and it already works correctly. If I edit a cheat title then go back to the cheat selection, all cheats get unselected.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on August 07, 2016, 03:01:17 AM
Hey fzurita.

I was testing out some more games and thought I'd report back some results of glitches/strange behavior. Luckily, these are all pretty minor for the most part.

•Army Men: Sarge's Heroes-- The game's sound completely cuts out in the beginning of the second level. Restarting the game brings the sound back, but it just quickly cuts out again after you reload the second level and play it for about 30 seconds to a minute. I decided to keep playing until I made it to the third level. I then restarted the game again and loaded up the third level where I left off. The sound was there for about 30 seconds and then quickly cut out again. Changing the graphic and audio plugin didn't fix it.

• Blast Corps-- Crashes at the title screen using both Glide 64 and GLN 64. The game only seems to work with Glide N64. Luckily, it seems to work pretty good (some slowdown in the menus, but the actual gameplay is at normal speed with hardly a stutter). This is all with the current update.

• Starfox 64--  On the previous update, Glide N64 had a strange rainbow boarder after I would beat a level. It would go away after I left the game and came back to it. As of this current update, the boarder doesn't seem to be there anymore. It might come back though because I still do see a random freeze frame of a rainbow blob just after I beat a level. Also GLN 64 will glitch out and show double in some parts of the game (going through a warp zone and battling the final boss). By the way, thank you for including the gamma correction in Glide N64. It's needed for the colors in Starfox 64 to look normal on that particular plugin. Without the gamma correction, the game looked very washed out.

I apologize in advance if all of these issues are already known.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 07, 2016, 06:50:00 AM
Thanks for the report. The only plugin that is actively being maintained is GLideN64.

For Army men, can you try changing the RSP to CXD4 HLE in your emulation profile? It may fix the audio. It's a more accurate RSP but it fits run a little slower so it may not be full speed in your device.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on August 07, 2016, 08:00:00 AM
I tried changing the RSP, but it didn't fix the audio. Should I try CDX4 LLE?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 07, 2016, 05:14:51 PM
You can try it, it will be very slow though. I doubt it will fix it. My guess is that it's a core issue. You could try switching the R4300 Emulator to cached interpreter and see if that fixes it.

If it's a core cycle accuracy issue. Then they're is not much we can do.
Title: Re: 3.0 Alpha Testing
Post by: LarryL on August 08, 2016, 01:41:46 AM
Switching the R4300 Emulator to cached interpreter did the trick. I played the entire third level without the sound cutting out. It was super slow though.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 08, 2016, 03:23:44 PM
I'll make a bug report upstream about this issue.

Bug report created: https://github.com/mupen64plus/mupen64plus-core/issues/174
Title: Re: 3.0 Alpha Testing
Post by: LarryL on August 10, 2016, 04:21:20 AM
Cool, thanks.
Title: Re: 3.0 Alpha Testing
Post by: Mithrot on August 21, 2016, 05:13:05 PM
I hope I'm posting in the right place. This is regarding the latest buildbot APK on the top banner of this website.

I own a Nvidia Shield Portable and Mupen64 on this thing is absolutely abysmal. I have no idea whats going on, but any video plugin thats not exactly "gln" has the game stutter and skip horribly with bad FPS regardless of what settings you use. GlideN64 is specifically noteworthy.

Am I doing something wrong here? The Nvidia Shield Portable uses a overclocked Tegra 4 chip.
Title: Re: 3.0 Alpha Testing
Post by: RogerSmith on August 21, 2016, 05:28:10 PM
I hope I'm posting in the right place. This is regarding the latest buildbot APK on the top banner of this website.

I own a Nvidia Shield Portable and Mupen64 on this thing is absolutely abysmal. I have no idea whats going on, but any video plugin thats not exactly "gln" has the game stutter and skip horribly with bad FPS regardless of what settings you use. GlideN64 is specifically noteworthy.

Am I doing something wrong here? The Nvidia Shield Portable uses a overclocked Tegra 4 chip.

I'm also running the nvidia shield handheld, and I've been using mupen AE on it for a long time and I've had those kinds of serious problems. Almost every game for me is playable, and with the FZ branch there's been improvement.
Title: Re: 3.0 Alpha Testing
Post by: Mithrot on August 21, 2016, 07:09:06 PM
I'm also running the nvidia shield handheld, and I've been using mupen AE on it for a long time and I've had those kinds of serious problems. Almost every game for me is playable, and with the FZ branch there's been improvement.

I think a large part of these issues stem from the fact that the Tegra 4 isn't a popular chip, especially in 2016.

FZ branch? I'm not sure which one you are referring to.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 21, 2016, 08:14:17 PM
Search the playstore for mupen64plus fz. It's the version I'm keeping up to date.
Title: Re: 3.0 Alpha Testing
Post by: Mithrot on August 23, 2016, 01:13:04 AM
Without derailing this thread too hard, I'd like to thank you two (especially fzurita) for letting me know about the FZ branch of Mupen64ae. I have no idea what kind of black magic you performed, but the stuttering I always encountered on Mupen64ae on any Tegra 4 device is completely gone! GlideN64 (GLES 2.0) is also far more stable.  ;D

Perhaps this is something worth merging back into the main branch? I'm not exactly sure what the cause of it is specifically (on the Nvidia Shield Portable), but I can try to help.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 23, 2016, 05:58:54 AM
I have been keeping the main branch up to date. The build server is just not working so the auto builds are not showing up.
Title: Re: 3.0 Alpha Testing
Post by: Mithrot on August 23, 2016, 02:44:56 PM
Oh, alright thanks!
Title: Re: 3.0 Alpha Testing
Post by: Bradleyw801 on August 24, 2016, 06:09:36 PM
Search the playstore for mupen64plus fz. It's the version I'm keeping up to date.

Looks like it's not up anymore? I managed to download it and leave a review, but now I can't find it anymore.
Title: Re: 3.0 Alpha Testing
Post by: fzurita on August 24, 2016, 07:04:25 PM
Yeah, Google took it down. The email said I was accepting payments from a non Google based payment system. I don't understand why since I only accepted Google play in-app purchases.
Title: Re: 3.0 Alpha Testing
Post by: casiragi on December 09, 2016, 02:22:56 AM
Hello, i know i'm late. The last update is Long available, but now I tried to test Gamepad Support..

I just installed the 3.0111 beta on my fire tv 4k and configured my Fire TV Controller. Then i tried to start Wave Race, but the game tells me, that no Controller ist connected. Ok, i tried Mario Kart and everything worked fine. then i tried Mario 64 und there are many texture Problems (greend ground) in the 1st world and the framerate is really really bad. So i installed Version 2.4.4. Mario 64 runs fine and Wave Race makes no more Problems.

Am I the only one with those Problems? The 3.x release has a really nice Interface, but if not many games will work ist useless for me :-( Is somebody still working on the emulator?

Best Regards
Title: Re: 3.0 Alpha Testing
Post by: grmilbrand on December 15, 2016, 03:57:28 PM
Quote
Try this:

-c 'am start --user 0 -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%" &amp;&amp; am start --user 0 -S -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity'

Let me know how it works. If it doesn't I'll dig further to find the right activity to use.

Quote
OK, so I tried these:

-c 'am start --user 0 -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%" &amp;&amp; am start --user 0 -S -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity'

-c 'am start -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%" &amp;&amp; am start -S -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.GalleryActivity'
(without user 0)

&

start -n org.mupen64plusae.v3.alpha/paulscode.android.mupen64plusae.SplashActivity -a android.intent.action.VIEW -eu Uri "file://%rom%"
(my Shield is non-root version)

*all just said launching without any further action.

@fzurita, i was never able to figure out the launch command. Now that I installed the version you provided, are you able to provide a launch command for use in Rom Collection Browser?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 15, 2016, 04:15:43 PM
Here is the command:
<emulatorParams>start --user 0 -n org.mupen64plusae.v3.fzurita/paulscode.android.mupen64plusae.SplashActivity  -a android.intent.action.VIEW -eu Uri "file://%rom%"</emulatorParams>
Title: Re: 3.0 Alpha Testing
Post by: grmilbrand on December 15, 2016, 06:19:35 PM
Thank you very much for that, although it's not working for me. Are there some troubleshooting steps I can take to make sure it isn't my system. I'm running Kodi on Android TV on a Shield.
Where in the file system could I look for the package org.mupen64plusae.v3.fzurita?
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 15, 2016, 06:37:51 PM
Interesting, are you using the Mupen64Plus FZ app in the play store? That command is for that.
Title: Re: 3.0 Alpha Testing
Post by: grmilbrand on December 16, 2016, 07:56:29 AM
Yes, I just downloaded prior to inputting that command.it runs fine out of the leanback launcher and opens games. Runs perfect. It's just when I go into Kodi and use that command in Rom Collection Browser. I input the command just as you have it. checked it twice, and it just states launching with no further activity.
I'll mess with it again tonight. I didn't know if there was someway to check the file structure of the org.mupen64plusae thru ESFileExplorer or something like that, to make sure it's installed in the same place. Do you have the Shield, or does anyone else with a Shield/Kodi/RCB/Mupen wanna test and make sure it's not just me?

Thanks again. I enjoy using it as standalone, just wish I could get the launcher to work like NESemu. It's soothing to play old video games. Must be the nostalgia!
Title: Re: 3.0 Alpha Testing
Post by: fzurita on December 16, 2016, 04:57:03 PM
I'll have to give it a try to see if I can get it to work. All I can tell you for sure is that SplashActivity is the entry point.