3.0 Alpha Testing

[xperia64]

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

[littleguy]

Thanks much, that's "progress" of some sort.  I'll keep digging.

[littleguy]

@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)?

[xperia64]

Last crash report was from Jan 13th. Do I have to enable crash reporting, or is that just ACRA related?

[littleguy]

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.

[littleguy]

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

[xperia64]

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.

[rafar]

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

[retroben]

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.

[littleguy]

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.

[retroben]

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.

[rafar]

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.

[littleguy]

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?

[littleguy]

I'll do it tonight. Checking the logs, it's crashing in libEGL 
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...

[retroben]

@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.