PaulsCode Forum

Mupen64Plus AE => Support => Topic started by: Grantious on May 11, 2013, 09:06:00 PM

Title: HTC one FPS
Post by: Grantious on May 11, 2013, 09:06:00 PM
Hey guys, i've been reading the forum and i've found that there are issues with the HTC one galaxy s3 s4 ect ect, but i'm wondering if there has been any progress in fixing these issues, the resolution build helped a little, most games are playable with the frame skip set at no more than 5, little skippy but what can you do, but it'd be nice to turn that down a tad :P, Also with majora's mask the glide64 plugin did fix a lot of the flashing but it was unplayable slow, but i suppose that's progress :P
Title: Re: HTC one FPS
Post by: Paul on May 13, 2013, 10:22:50 PM
There are a couple of things that are holding back progress on this bug.  The main issue is that we need to get lots of logcat outputs from testers to be able to rule out different theories.  A combination of factors (not just a low number of testers) has made getting these logs very difficult, and progress on the issue has thus been at a standstill.

The first roadblock comes from the fact that Android has recently changed so that one app can no longer read the logcat output from another.  This means we can no longer have folks use the simple aLogcat method for collecting logs for us to read.  In combination with the low number of testers means it is unlikely any have a tester with one of these devices who also has enough development experience to work with the Android SDK to read logcat output.  Clearly, an alternative is necessary.

That alternative to aLogcat is reading the logs from the app itself.  For this purpose we are using Acra.  It is great for detecting crashes, but it is at its core a crash-reporting system.  Meaning it activates when there is a crash.  To collect the logs we are after we must simulate a crash, so that the chunk of log output before the simulated crash is sent along with the report.  This function for simulating a crash is activated through an option in the Advanced settings menu.

The problem with that is there is another issue we have been referring to as the "Activity Stack Double-Pop" (ASDP) bug.  This was caused by the way SDL 1.3 shut down, causing two activities on the stack to close rather than just the top one.  The workaround for this bug was to force-close the game activity by calling System.exit(0) to bypass the normal shutdown sequence.  This has the unfortunate side effect of also killing all logcat output from that Activity from being picked up when a crash test is activated afterwards from the advanced menu.

The upgrade to SDL 2.0 has provided a light at the end of the tunnel.  There is still one more problem to work out, but hopefully it won't be too much longer before testers will actually be able to provide the log output we need to begin ruling things out and hopefully zero in on a solution.
Title: Re: HTC one FPS
Post by: littleguy on May 14, 2013, 11:47:48 AM
Good synopsis of the issues.

Just a reminder, if we're desperate for logcat data in the short-term, the fix-asdp branch (https://github.com/paulscode/mupen64plus-ae/commits/fix-asdp) will allow you to collect in-game data through acra by submitting a test crash.  I.e. the logcat isn't lost when the emulator shuts down and returns you to the menu.  That branch isn't ready for release (it effectively post-pones the hard-crash until the next time you try to launch the emulator, which would confuse most users) but it would work perfectly well with informed testers.
Title: Re: HTC one FPS
Post by: Paul on May 18, 2013, 08:11:26 PM
Here is a Test Build (http://www.paulscode.com/source/Mupen64Plus-AE/18MAY2013/Mupen64Plus-debug.apk) of that fix-asdp branch littleguy mentioned.

You will need to uninstall any previous tests.  Also, there is a bug in this build which will let you only run a game once (second run will crash, and you may have to force-stop the app or reboot the phone if it keeps crashing after that).  Here are the steps I'd like you to run:

1) Uninstall any previous tests and install this one
2) Enable crash reporting in Advanced settings, and enter your user name
3) Start Mario 64 (wait for some game graphics to show up)
4) Quit and quickly go back to the advanced settings and press Test to send the report
5) Post here with your username you used when you are done, so I can look up the report

I mention doing step 4 quickly, because the logs tend to fill up fast, so the useful piece of the log might not show up in the crash report if other messages flood the log before you can press Test.
Title: Re: HTC one FPS
Post by: mikethebigo on May 18, 2013, 08:51:04 PM
Paul,

I'd like to help with testing however I can, I'd love for this to get fixed.  Just switched to a AT&T Galaxy S4 so I can be your Adreno 320 guinea pig.


Just sent you a test report, let me know if there's anything else I can do.

Also, would you happen to know if Moga Pro support is on the horizon?

Thanks!
-Mike
Title: Re: HTC one FPS
Post by: Paul on May 18, 2013, 09:00:05 PM
Excellent, we finally got one  ;D  Posting the useful bit here so we can find it easily later:

(Galaxy S4)
Code: [Select]
131 I/GameSurface(12907): Config[0]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1445
132 I/GameSurface(12907): Config[1]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1445
133 I/GameSurface(12907): Config[2]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1445
134 I/GameSurface(12907): Config[3]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1445
135 I/GameSurface(12907): Config[4]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1445
136 I/GameSurface(12907): Config[5]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1445
137 I/GameSurface(12907): Config[6]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1413
138 I/GameSurface(12907): Config[7]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1413
139 I/GameSurface(12907): Config[8]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1413
140 I/GameSurface(12907): Config[9]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1413
141 I/GameSurface(12907): Config[10]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1413
142 I/GameSurface(12907): Config[11]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1413
143 I/GameSurface(12907): Config[12]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1509
144 I/GameSurface(12907): Config[13]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1509
145 I/GameSurface(12907): Config[14]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1509
146 I/GameSurface(12907): Config[15]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1509
147 I/GameSurface(12907): Config[16]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1509
148 I/GameSurface(12907): Config[17]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1509
149 I/GameSurface(12907): Using Config[0]
Title: Re: HTC one FPS
Post by: littleguy on May 18, 2013, 09:00:16 PM
Re: Moga Pro - I'll do my best.  Do you have any info on it?  If you own one, please check out this FAQ and post there and I'll see what I can do.
http://www.paulscode.com/forum/index.php?topic=877.0
Title: Re: HTC one FPS
Post by: littleguy on May 18, 2013, 09:02:37 PM
@mikethebigo - Do you see any change in FPS when you enable RGBA8888 mode (Settings->Video)
Title: Re: HTC one FPS
Post by: mikethebigo on May 18, 2013, 09:11:15 PM
It seems like there is slight improvement however the lag is definitely still there.

And thanks for the link to the controller FAQ - it had all the info I needed!
Title: Re: HTC one FPS
Post by: littleguy on May 18, 2013, 09:34:38 PM
I'm going to go out on a limb and guess that these new high-end devices would prefer to use 24-bit depth buffer (and RGBA8888).  They may be using partial software emulation to achieve 16-bit depth buffer.  I can't remember if we tested that theory already.  If not, it would be easy to make a one-off test build that just extends this condition check (https://github.com/paulscode/mupen64plus-ae/blob/master/src/paulscode/android/mupen64plusae/GameSurface.java#L195) to find the first config with 24-bit.

Edit: 24 bit depth may throw a wrinkle into the polygon offset stuff, but we could cross that bridge if we get there.
Title: Re: HTC one FPS
Post by: Paul on May 18, 2013, 10:01:47 PM
Here is a second Test Build (http://www.paulscode.com/source/Mupen64Plus-AE/18MAY2013/Mupen64Plus-debug_B.apk) with that logic in place (finds the first match with caveat EGL_NONE, depth 24, and RGBA8888).  Let me know if it runs any faster, and also please repeat the above crash report steps so I can see which config it picked (if the logic worked)
Title: Re: HTC one FPS
Post by: mikethebigo on May 18, 2013, 10:16:44 PM
Not a very significant difference.  Mario runs only slightly laggy, other games like smash bros still really laggy.  Sent another test report.
Title: Re: HTC one FPS
Post by: littleguy on May 18, 2013, 10:24:02 PM
Is it measurably faster,.or might it just be your imagination? I'm not trying to sound rude -- just trying to verify if we're on to something real :)
Title: Re: HTC one FPS
Post by: mikethebigo on May 18, 2013, 10:36:43 PM
I'd say mostly imagination, honestly it seems the same. (and no worries about sounding rude haha), you guys are doing something for me here!
Title: Re: HTC one FPS
Post by: Paul on May 19, 2013, 09:51:45 AM
I cant seem to find the second crash report.  I find two reports in the queue with your username, but they both say in the logcat "Using Config[0]", which means they must both be from the first test.  I'd like to see which config it picked in the second test to make sure the logic is working.

Could you run those steps again?  But first, to be sure the correct one is installed and set up:

1) Uninstall the test app you have installed now
2) Reinstall the second test from the link above
3) Go to Advanced settings and reenable crash reporting and enter your username

Then run through the steps of starting Mario64 then quitting and going back to Advanced to click Test.
Title: Re: HTC one FPS
Post by: mikethebigo on May 19, 2013, 12:57:33 PM
OK, done.  Hopefully its what you need :)
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 01:21:52 PM
Looks like maybe the selection code didn't work.  Should be picking Config[13]:
Code: [Select]
190 V/GameSurface(20383): Starting up OpenGL ES 2.0
191 I/GameSurface(20383): Config[0]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1445
192 I/GameSurface(20383): Config[1]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1445
193 I/GameSurface(20383): Config[2]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1445
194 I/GameSurface(20383): Config[3]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1445
195 I/GameSurface(20383): Config[4]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1445
196 I/GameSurface(20383): Config[5]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1445
197 I/GameSurface(20383): Config[6]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1413
198 I/GameSurface(20383): Config[7]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1413
199 I/GameSurface(20383): Config[8]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1413
200 I/GameSurface(20383): Config[9]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1413
201 I/GameSurface(20383): Config[10]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1413
202 I/GameSurface(20383): Config[11]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1413
203 I/GameSurface(20383): Config[12]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1509
204 I/GameSurface(20383): Config[13]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1509
205 I/GameSurface(20383): Config[14]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1509
206 I/GameSurface(20383): Config[15]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1509
207 I/GameSurface(20383): Config[16]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1509
208 I/GameSurface(20383): Config[17]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1509
209 I/GameSurface(20383): Using Config[0]
Title: Re: HTC one FPS
Post by: Paul on May 19, 2013, 04:22:24 PM
Weird.  Looks like it should work.  Let me do a clean build.
Title: Re: HTC one FPS
Post by: Paul on May 19, 2013, 04:50:52 PM
Oops, I found the problem (simple logic error).

Try this build (http://www.paulscode.com/source/Mupen64Plus-AE/19MAY2013/Mupen64Plus-debug.apk).  Also do the above steps again to send another report, so I can make sure I got the picker right this time.
Title: Re: HTC one FPS
Post by: mikethebigo on May 19, 2013, 05:15:23 PM
Ok, done!

Unfortunately still no noticeable difference.

I don't know if it helps but here is some additional info:
- The lag is not just visual, the audio also stutters quite significantly, slowing down or hopping in certain spots, especially in games like zelda and super smash brothers.
- The lag actually seems to improve when I decrease the game speed to 70-80% however obviously everything is moving slower.
- The lag is for some reason worse on same games than others, zelda in particular has a pretty rough time vs super mario which isn't nearly as bad.
- The controls still work fine.
Title: Re: HTC one FPS
Post by: Paul on May 19, 2013, 06:11:59 PM
Oh, well.  At least it picked the config I wanted it to:

Code: [Select]
172 I/GameSurface(29976): Config[0]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1445
173 I/GameSurface(29976): Config[1]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1445
174 I/GameSurface(29976): Config[2]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1445
175 I/GameSurface(29976): Config[3]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1445
176 I/GameSurface(29976): Config[4]: BS16 R5 G6 B5 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1445
177 I/GameSurface(29976): Config[5]: BS16 R5 G6 B5 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1445
178 I/GameSurface(29976): Config[6]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1413
179 I/GameSurface(29976): Config[7]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1413
180 I/GameSurface(29976): Config[8]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1413
181 I/GameSurface(29976): Config[9]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1413
182 I/GameSurface(29976): Config[10]: BS24 R8 G8 B8 A0 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1413
183 I/GameSurface(29976): Config[11]: BS24 R8 G8 B8 A0 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1413
184 I/GameSurface(29976): Config[12]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1509
185 I/GameSurface(29976): Config[13]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC|NONE RT71 NR0 NVT0 SB0 Sa0 ST1509
186 I/GameSurface(29976): Config[14]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1509
187 I/GameSurface(29976): Config[15]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa2 ST1509
188 I/GameSurface(29976): Config[16]: BS32 R8 G8 B8 A8 D16 S0 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1509
189 I/GameSurface(29976): Config[17]: BS32 R8 G8 B8 A8 D24 S8 AM0 CC12369 RT71 NR0 NVT0 SB1 Sa4 ST1509
190 I/GameSurface(29976): Using Config[13]

@littleguy, what do you think we should do next, try a few other configs to see if any of them are better, or do you think we are probably on the wrong track?
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 06:15:58 PM
@mikethebigo  Thanks for the detailed feedback.  If you disable the video plugin and resume a game that has a lot of audio stuttering, does the audio get better?  And vice versa, if you disable the audio plugin, does the video get an better?

@paul  Well we could continue down this path, running it all the way to ground, checking stencil buffer enabled/disabled and some of the others (I forget what all the codes refer to)... but that may be a lot of work for no gain.  I'll have to think some more...
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 06:45:40 PM
@Paul - Remind me again, does this lag issue affect all Adreno 320 devices, or just the HTC One?  How about Adreno 305?  Which version/carrier of the GS3 shows the lag?

I'm downloading some Adreno dev literature, going to scan to see if anything obvious jumps out at me....
Title: Re: HTC one FPS
Post by: xperia64 on May 19, 2013, 06:57:55 PM
@Paul - Remind me again, does this lag issue affect all Adreno 320 devices, or just the HTC One?  How about Adreno 305?  Which version/carrier of the GS3 shows the lag?

I'm downloading some Adreno dev literature, going to scan to see if anything obvious jumps out at me....

I'm pretty sure its most American S3's so sprint, Verizon etc. The chips in the American ones have to be different because of the different 3G/4G frequencies or something Those S3's have Adreno 225's. I can verify that the sprint S3 at least with an Adreno 225 is slower than my S2 with a mali 400MP
Title: Re: HTC one FPS
Post by: Garrett on May 19, 2013, 07:08:18 PM
I have the T-Mo Galaxy S4, it uses the Adreno 320. Most games I've tried are too laggy to play.
Title: Re: HTC one FPS
Post by: xperia64 on May 19, 2013, 07:19:01 PM
Random thought: I know its probably due to the gfx components, but on the off chance its the dynarec, someone switch plugins->R4300 emulator to cached interpreter
Title: Re: HTC one FPS
Post by: Garrett on May 19, 2013, 07:23:18 PM
dropped my fps by about 8 when I did that.

One thing I just came across though is that if I hold my finger on the screen my fps increases
Touch input is disabled - I'm using a ps3 sixaxis controller.

I can actually get ~25-30 fps in mario64 with frame-skipping set to never skip

Edit:
Not touching screen ~17fps
when touching screen 27-32
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 07:24:45 PM
So is it safe to say we've narrowed this down to Adreno 320/225?  All devices with these chipsets?
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 07:29:07 PM
One thing I just came across though is that if I hold my finger on the screen my fps increases
Touch input is disabled - I'm using a ps3 sixaxis controller.
....
Not touching screen ~17fps
when touching screen 27-32

Wow, that's really helpful, that indicates something entirely different than video.  Two possibilities come to mind immediately - weirdness with the input plugin or weirdness with Android event handling.

What happens when you disable the input plugin (you won't be able to control anything, but does your FPS change)?
Title: Re: HTC one FPS
Post by: xperia64 on May 19, 2013, 07:35:55 PM
It could also be something with the refresh rate e.g. refreshing more when the screen is being touched. I know that retroarch recommends tapping on the screen when it calculates FPS
Title: Re: HTC one FPS
Post by: Garrett on May 19, 2013, 07:39:44 PM
No change in fps when disabling input

I'm thinking it has something to do with updates on the screen
Even opening a menu will do the same fps increase temporarily.

One thing to note that I just tested -
In developer options, I have "Show Touches" enabled.
It only does the fps increase with that enabled (shows a white dot where you are touching)
I tried turning it off and my fps stays the same (around 17), even if I touch the screen
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 08:01:25 PM
Ok, so when you first said the FPS increased when you touched the screen, did the lagginess/audio stutter get any better?  Or did the numerical value simply change without any noticeable change in gameplay?
Title: Re: HTC one FPS
Post by: Garrett on May 19, 2013, 08:07:40 PM
Everything is better. Audio is smooth and the game is actually playable - well, other than it requiring me to keep my hand on the screen  haha

Pretty much makes it run at full speed with no errors/hiccups.
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 08:11:14 PM
Awesome, so there's definitely something to it.  This may be the best clue we've gotten to date on the issue.

@Paul - Perhaps this has something to do with the window compositing with the GL surface and the virtual gamepad overlay.  Something to do with focus and maybe Adreno has some optimizations to detect loss of focus that are too aggressive.  I'll make a branch that doesn't have the GameOverlay object (i.e only contains the GL surface) and see if that helps...
Title: Re: HTC one FPS
Post by: Garrett on May 19, 2013, 08:14:30 PM
Glad I could help some. I just got the app yesterday! :p

Hopefully you guys can figure out a way to fix it.
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 08:15:56 PM
Yeah it really kills me to think that some super incredible new devices are running like dogs with mupen.  But this is the best I've felt about the issue in a while.  Hopefully we're on the right track now.
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 08:27:29 PM
@Paul - I just posted a test branch that removes the GameOverlay.  Testers will only be able to use peripheral/hardware controllers and FPS won't be shown, but they can at least tell us if audio stutter and video lag are any better.
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 08:54:58 PM
@Paul - nevermind, Garrett just privately tested the build over PM.

@Garrett - Is there any way you can manually disable the adreno speed governor?  It looks like it's trying to optimize power but is shooting itself in the foot.  I think there may be some root apps, if you're rooted.  Or maybe there's an app/setting that came with the phone to put it in 'performance mode' or something?
Title: Re: HTC one FPS
Post by: Garrett on May 19, 2013, 08:59:44 PM
I've already tried messing with some of the GPU developer options, but nothing helped.
I am rooted, if you know of something I can install to change it, I'd be glad to try. But there are no settings to disable the governor.

Power-saving mode is also off.
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 09:16:24 PM
In another post on the forum (http://www.paulscode.com/forum/index.php?topic=532.msg7848#msg7848), Paul recommended setCPU (http://www.setcpu.com/).  It's $1.99 on google play, but an older version can be downloaded from the developer for free here (http://forum.xda-developers.com/showthread.php?t=505419).  I won't ask you to drop money on an app just for diagnostic purposes, but if you do try it, let us know if "Performance" mode for the governor changes the lagginess.
Title: Re: HTC one FPS
Post by: xperia64 on May 19, 2013, 09:21:33 PM
https://play.google.com/store/apps/details?id=com.antutu.CpuMasterFree&feature=search_result#?t=W251bGwsMSwyLDEsImNvbS5hbnR1dHUuQ3B1TWFzdGVyRnJlZSJd
A custom rom may be needed to access governor and stuff. If only chainfire3d worked with newer versions of android...
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 09:27:22 PM
Thanks xperia64!

So I went back and re-read the SGS 3 thread (http://www.paulscode.com/forum/index.php?topic=532.msg5605#msg5605) again, because I knew we went through all this already.  Interestingly I noticed this:

Also, a strange thing I noticed. Whenever I hit the menu button to bring the pop up menu, the audio and game runs at a stable 30FPS with no audio skipping [gles2n64].
...
But I had the same strange solution when I press the menu button. The audio skipping completely stopped. Albeit, it still runs at the 15FPS with frameskipping on [gles2rice].

It might not be the governor by itself, but this again seems to point to lagginess being a function of (lack of) user input....
Title: Re: HTC one FPS
Post by: xperia64 on May 19, 2013, 09:44:29 PM
You could always try what i call the inherently evil method: forcing the java surface to refresh/redraw/invalidate every 20ms or something like that
Title: Re: HTC one FPS
Post by: Garrett on May 19, 2013, 10:03:13 PM
I just tried the app that Xperia64 linked. I couldn't access the gpu settings with it, but I did set my cpu to max and gave that a shot. It increased my fps to ~25, audio was still a bit choppy and so was the game. but it increased it by almost 10fps.

Btw - the menu thing works the same way as if I touched the screen... basically if you spam the menu open/closing it the game runs at 30 fps.
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 10:05:37 PM
You could always try what i call the inherently evil method: forcing the java surface to refresh/redraw/invalidate every 20ms or something like that

Interesting idea, worth trying in a test build at least to help diagnose the issue.  Have you done this before for some reason?
Title: Re: HTC one FPS
Post by: littleguy on May 19, 2013, 10:43:39 PM
 :) :D ;D

Just sent Garrett another test build and he confirmed that he's getting full speed without hiccups!  The build is from an experimental branch I've been working on to solve a completely different issue (http://www.paulscode.com/forum/index.php?topic=1029.0).  I haven't pushed the source yet (still have a few bugs to fix), but should be able to get something out this week.
Title: Re: HTC one FPS
Post by: mikethebigo on May 19, 2013, 11:57:06 PM
Sorry I didn't see all the updates in this thread until now!  If you'd like to test the experimental build on the AT&T S4 as well send it my way and I'll let you know.  I would be very stoked if the problem was fixed!
Title: Re: HTC one FPS
Post by: scorpio16v on May 20, 2013, 12:34:30 AM
OC the device doesn't bring better performance on my Adreno 320 powered Nexus 4.
The N4 is clocked to max/min 1512 MHz / governor "performance".
The other device is my Onda v812 clocked to max/min 1200 MHz / governor "performance".
MP64+ae version is the latest test build with glide plugin. Benchmarked the intro sequence from "Super Smash Brothers".

The device runs with stock kernel, so I can't test GPU OC.

http://youtu.be/v_BLhcGua4o
Title: Re: HTC one FPS
Post by: Grantious on May 20, 2013, 05:11:47 AM
Oh wow lots of buzz :) seems like progress is there anything that you need me to do? Like with error reports or anything or is all well :)
Title: Re: HTC one FPS
Post by: xperia64 on May 20, 2013, 07:29:56 AM
@littleguy i used that in timidity at one point when the label wouldnt refresh on its own. Another theory: the gpu thinks the input layer is the main gfx layer and seeing how it isnt changing,  it slows down.  I guess someone should try to rewrite the touchscreen controls to be drawn in gles or something. Also,  if the 'animated' control scheme is still in there,  i wonder if that would cause more refreshes
Title: Re: HTC one FPS
Post by: littleguy on May 20, 2013, 07:34:03 AM
I was thinking that too about the animated touchscreen, but then realized we had optimized that code to be lazy so that it wouldn't force unnecessary refreshes... so probably wouldn't change much.

I'm making some final tweaks to the version that worked for Garrett and will be pushing shortly.  I think you're right, it has something to do with the GameSurface and GameOverlay objects fighting over focus, and Adreno trying to optimize power consumption based on focus.  The version I'm about to push changes some things about those two objects that apparently fixed the issue for Garrett.
Title: Re: HTC one FPS
Post by: xperia64 on May 20, 2013, 08:08:13 AM
I can probably test on my friend's s3 today
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 08:12:23 AM
Nice work on diagnosing the problem, guys (and extra thanks to Garrett for noticing that important tidbit of info!)  I have a whole bunch of email addresses for folks who have reported this problem, so I'll blast out some spam once littleguy's new branch is ready.  I haven't had much luck getting many of them to be excited about helping with the tests, but I suspect they'll be more enthusiastic if we have something that actually solved the problem at least on one device.
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 01:44:15 PM
Ok, I built littleguy's two test branches, to help zero in on the solution.  I built these on a different computer, so be sure to uninstall any previous test builds before installing these (or you'll get a signature mismatch error).

We need feedback from anybody with an HTC One or other device that has the Adreno lag problem:


Test #1: GameOverlay Test (http://www.paulscode.com/source/Mupen64Plus-AE/20MAY2013/mupen64plus-ae_adreno-test.apk).  For this test, just interested in seeing if the lag problem still exists (using GameOverlay behind the scenes to handle touch events instead of GameSurface)


Test #2: Screensize Test (http://www.paulscode.com/source/Mupen64Plus-AE/20MAY2013/mupen64plus-ae_reimplement-screensize.apk).  For this test, the touch controls are broken, so don't worry about that.  We just need feedback on whether different video resolutions fix the lag problem (in video settings section).
Title: Re: HTC one FPS
Post by: Garrett on May 20, 2013, 02:17:50 PM
Your first GameOverlay Test did not help. Ran around 17 fps, same as before. Touching the screen still helped to increase fps.

The resolution change helped the problem the most.
In 960x720 fps was 20-25 - a little choppy sound/gameplay
In 800x600 fps was 25-30 - pretty smooth gameplay, hiccups occasionally
and 640x480 was 28-30 - pretty much perfect, however a bit too small to play on due to the native resolution being 1920x1080 on the S4.

Though in all of these resolution modes (and native) I noticed still if there is any input such as me touching the screen - (making it produce the little dot where my finger is) or opening/closing the menu, the fps will jump up to a constant 30+fps

So the resolution is a work-around for the problem at the moment, but there is still something else that is making it lag.

--Btw, these fps values same with the version littleguy set me
Title: Re: HTC one FPS
Post by: littleguy on May 20, 2013, 02:22:05 PM
Ah, so I misunderstood one of your PMs.  I thought the non-native resolutions fixed the problem entirely, not just reduced the load....  That chops me back down a notch.  Still, the fact that something makes it run at full speed, repeatably, is the best clue we've had to date...
Title: Re: HTC one FPS
Post by: Garrett on May 20, 2013, 02:30:26 PM
Yeah, I thought it fixed it too, as I pretty much just tried to use 800x600 and lower. It pretty much makes it totally playable. And all my fps tests are on Mario64, some of the other games are a bit slower I've noticed.

My guess is what has been thrown around. It's probably the gpu/cpu being governed because it doesn't think it needs to be working.
Title: Re: HTC one FPS
Post by: scorpio16v on May 20, 2013, 02:45:37 PM
Both tests don't bring realy better results.
Same config, like in my previous posted video. Plugin was rice now. Other settings are default, only framecounter and stretch screen added.
If I run the intro of smash bros. till the point where the start screen appeares, the difference  to my tablet as reference are ~15 seconds.
On the old video with glide plugin the difference was nearly 20 seconds that the Nexus 4 performes the test.
Title: Re: HTC one FPS
Post by: littleguy on May 20, 2013, 03:05:40 PM
@scorpio - Does touching the screen or spamming the menu button/icon a bunch of times give you a performance boost?
Title: Re: HTC one FPS
Post by: mikethebigo on May 20, 2013, 03:30:47 PM
Hi everyone, I have some possibly exciting news!

I was thinking about what Garrett said, about it possibly being a CPU/GPU clocking problem.  I think that actually would be consistent with noticing the increased speed with touch events - the system may dynamically up clock to handle those events.

My GS4 is rooted and I installed antutu CPU master (free from the play store).  It reports it cannot control the GPU but it can control the CPU.  It showed the CPU was dynamically clocking all the way down to 384 MHz often.  I set the CPU to performance mode at consistent max of 1890 MHz.

Afterward there was a HUGE difference with Mupen.  Using the stock app in the play store (not one of the test builds) I consistently got 30 fps in Mario and smash bros, and a consistent 20 fps in ocarina which is the best I've seen so far.

I agree with Garrett that at least part of the problem must be Qualcomm's processor power saving measures, it may just be that there needs to be a way to make the system understand that more power is needed.
Title: Re: HTC one FPS
Post by: littleguy on May 20, 2013, 03:47:04 PM
Awesome!  Can anyone try this on their HTC One, Galaxy S3, or Xperia Z?

I wonder if there are any similar apps that don't require root?  Or something open-source that we could study, perhaps we can build it right into mupen....
Title: Re: HTC one FPS
Post by: mikethebigo on May 20, 2013, 06:34:35 PM
Wow, even better news.  I wanted to be able to manipulate the GPU clock speed as well, found an app that works for any ICS/JB phone (called Faux123, requires root, unfortunately $5 on the play store).  It allowed me to set the CPU to performance max (again 1890 MHz) and also the GPU to performance max (for the S4 it's 450 MHz, I believe for the HTC One it's 400 MHz).

Ran Mupen again (stock one from the play store) and performance was great.  Super Smash Brothers ran completely smoothly at 45-60 FPS during gameplay.  I am almost completely certain at this point it is a CPU/GPU throttling issue.  I'm honestly not sure if there's any way to force higher clock speeds without root.. can try to look into it online but I'm not strong with coding or anything like that.

Let me know if you'd like any test reports or anything while running the app with the higher clocks, thanks!
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 06:57:11 PM
Using N64oid as a reference, there must be a way to at least get the app running at an acceptable speed without root. Probably won't reach the same level as using an app that lets you pick max CPU and GPU, but there has to be a happy medium.

One idea I'd like to try is xperia64's suggestion of a thread that repeatedly invalidates the surface (can test with hooking it up to either the game surface or the touchscreen surface).  If we're lucky, that might have the same effect as repeatedly touching the screen.

Another idea that might be worth exploring is to always use the Xperia Play NativeActivity when the API level is past a certain level (rather than only using it when the device is detected as an Xperia Play).  The only problem with that is there is a bug in at least ICS (probably HC and higher) that would need to be fixed, where presses on the actionbar are not registered.
Title: Re: HTC one FPS
Post by: littleguy on May 20, 2013, 07:24:55 PM
One idea I'd like to try is xperia64's suggestion of a thread that repeatedly invalidates the surface (can test with hooking it up to either the game surface or the touchscreen surface).
...
Another idea that might be worth exploring is to always use the Xperia Play NativeActivity when the API level is past a certain level (rather than only using it when the device is detected as an Xperia Play).

Was thinking the same.... I wasn't aware of the ICS issue with the native activity, I don't recall any issues when I tested it with my Nexus 7.

I agree, there must be some non-root way to let the app know that it's running.  The Android API allows you to disable sleep, so maybe there's something in the API for keeping it in performance mode?  I'm thinking about video player apps, they might run into the same issue... seems bigger than just the gaming community.  Or if faking user input gets the job done, then I guess that works too.

If you wanted to implement those ideas, I'll continue looking into the Adreno SDK and searching the web for more ideas (and finish the screen-size rewrite)...


Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 08:37:29 PM
I wasn't aware of the ICS issue with the native activity, I don't recall any issues when I tested it with my Nexus 7.

I had the problem some time ago when I first got my Galaxy Nexus (back when it had ICS, and before the big 2.0.0 front-end update).  Possibly it only affected a small subset of devices, and also possible the new front-end had the side effect of fixing the problem as well.  Would need to get feedback from testers to come up with a solution (for example if the problem only affected ICS, could just use NativeActivity for JB and higher).
Title: Re: HTC one FPS
Post by: littleguy on May 20, 2013, 09:41:49 PM
For quickly testing the NativeActivity theory, you could just comment out lines 132, 133, 190, and 191 (https://github.com/paulscode/mupen64plus-ae/blob/master/src/paulscode/android/mupen64plusae/MenuActivity.java#L132) in MenuActivity, and tell testers to enable touchpad input...
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 09:45:17 PM
Ok, here are two more tests to try (built from another computer than the last one, so be sure to uninstall it first).  Let me know if either fix the slowness problem:

Test #1: Touchy-feely (http://www.paulscode.com/source/Mupen64Plus-AE/20MAY2013/Mupen64Plus-debug_touchy.apk) (simulates rapid touches on the game surface - screws up the touchscreen controls though)

Test #2: The 'Invalidator' (http://www.paulscode.com/source/Mupen64Plus-AE/20MAY2013/Mupen64Plus-debug_invalidator.apk) (repeatedly does postInvalidate on both the game surface and the touchscreen overlay)

EDIT: And a third one:
Test #3: Touchy-feely B (http://www.paulscode.com/source/Mupen64Plus-AE/20MAY2013/Mupen64Plus-debug_feely.apk) (simulates rapid touches on the touchscreen overlay)
Title: Re: HTC one FPS
Post by: littleguy on May 20, 2013, 10:17:54 PM
Another one I'm curious about would be to comment out lines 290 and 295 (https://github.com/paulscode/mupen64plus-ae/blob/master/src/paulscode/android/mupen64plusae/GameSurface.java#L290) in GameSurface.  I don't see why they're necessary, and commenting them out doesn't seem to hurt anything on my devices.

Edit: Did a scan through the Adreno dev docs, and nothing stood out.  Pretty much everything I read was about optimizing shader designs, using gl extension tricks, texture compression, etc. but didn't see anything anywhere related to power management features of the chipset (let alone software apis).
Title: Re: HTC one FPS
Post by: Garrett on May 20, 2013, 10:24:25 PM
Test #1 - no change at all

Test #2 - this actually improved the fps. Though not perfect, I was getting 25-30 fps

and I can confirm what mikethebigo tried. I picked up the app he mentioned, and set the governor on the cpu & gpu to performance, which makes Super Mario 64 run at full speed.
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 10:33:26 PM
Ok, here's a fourth one:

Test #4: No Wait (http://www.paulscode.com/source/Mupen64Plus-AE/20MAY2013/Mupen64Plus-debug_nowait.apk) (removed calls to eglWaitNative and eglWaitGL)
Title: Re: HTC one FPS
Post by: Garrett on May 20, 2013, 10:43:28 PM
Ok, here's a fourth one:

Test #4: No Wait (http://www.paulscode.com/source/Mupen64Plus-AE/20MAY2013/Mupen64Plus-debug_nowait.apk) (removed calls to eglWaitNative and eglWaitGL)

This is running the game at full speed!
(and yes, I changed my governors back to OnDemand) :)
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 10:48:23 PM
Interesting.  Every example I've seen uses those calls before eglSwapBuffers.. I wonder if removing them has any negative effect on some devices?  I see no difference on my phones either.
Title: Re: HTC one FPS
Post by: Garrett on May 20, 2013, 10:57:35 PM
Might be some interesting info--

Super Smash Bro's runs better on that test#4 than any other version I've tried.

Market version of your app is getting 30-45 fps (and this is with my cpu and gpu set to max)

With the test #4 I'm getting 55-60 with it set to onDemand

And both tests are with gles2n64
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 11:02:04 PM
Sounds like it was waiting for something other than the video plug-in's gl calls (maybe in the Android UI?)  Unless there was some type of race-condition going on, where it ended up waiting for 2 or 3 frames to go by before it could update.
Title: Re: HTC one FPS
Post by: Garrett on May 20, 2013, 11:13:07 PM
Sounds like it was waiting for something other than the video plug-in's gl calls (maybe in the Android UI?)  Unless there was some type of race-condition going on, where it ended up waiting for 2 or 3 frames to go by before it could update.
I had it set to never skip frames. if that's what you're saying about the race-condition.

Btw, I sent the test #4 link to a friend with a nexus tablet to try out, who also had bad lag issues. So I'll let you know what he reports. And I could also probably throw it on an S3 if it's needed.
Title: Re: HTC one FPS
Post by: mikethebigo on May 20, 2013, 11:17:47 PM
Holy cow, when I get home I can try all the tests but I just tried test number 4 and it worked beautifully!  I didn't have to change my CPU or GPU to performance mode, and it handled everything no sweat, even Zelda which seems to give it a lot of problems.
Title: Re: HTC one FPS
Post by: Paul on May 20, 2013, 11:34:22 PM
I had it set to never skip frames. if that's what you're saying about the race-condition.

I meant two threads racing to use the same resource at the same time.  Where I could see this possibly happening is between the call to eglWaitNative and the call to eglWaitGL.  The way I understand these two methods is the first one waits for the native gl calls to finish, and the second one prevents more gl calls until eglSwapBuffers finishes.  In a multi-threaded environment I could see a scenario where eglWaitNative finishes, and the native thread manages to get in another gl call or two before eglWaitGL is called from the first thread.

Anyway, I'm totally making all this up since I have no idea how the code for these methods actually works behind the scenes  ;D
Title: Re: HTC one FPS
Post by: scorpio16v on May 20, 2013, 11:35:03 PM
Can confirm, the no-wait-test fixed the lag on Nexus 4 completely. I've used my same test configuration from my last test run and both devices are running in sync.  :)
Title: Re: HTC one FPS
Post by: Grantious on May 21, 2013, 01:10:44 AM
HTC one (no wait) huge speed increase!
Title: Re: HTC one FPS
Post by: mikethebigo on May 21, 2013, 01:46:24 AM
Of all of the tests, test #4 is definitely the one that basically fixed the problem.  Enjoying good frame rates on pretty much every game now.  Of note, when I use test 4 and also set my CPU/GPU to performance I do get a 5-10 FPS boost in some games but it is really smooth either way.

Now I just need to get my Moga Pro fully compatible with the app and I'll really be on the way to 64 bit greatness!
Title: Re: HTC one FPS
Post by: littleguy on May 21, 2013, 08:37:34 AM
Wow, nothing like waking up to a boatload of great news!!  So glad we finally got this nailed down, and thanks everyone for all the testing effort.  ;D ;D ;D
Title: Re: HTC one FPS
Post by: littleguy on May 21, 2013, 09:21:21 AM
Sounds like it was waiting for something other than the video plug-in's gl calls (maybe in the Android UI?)  Unless there was some type of race-condition going on, where it ended up waiting for 2 or 3 frames to go by before it could update.

EGL provides a cross-platform abstraction for the GL state machine to bind to.  It's mainly for coordinating GL rendering activities with the native windowing/GUI/compositing operations of the platform.  For example, Windows operating systems need to coordinate the drawing of the 2D window frame and widgets with the GL rendering activities inside that frame.  There are mixed mode operations going on, e.g. GDI and OpenGL, and EGL coordinates those operations.

What's a bit confusing in our case is the term 'native' in eglWaitNative.  It doesn't mean the 'native' as in C++ vs. Java, but rather means 'native' as in the Android native drawing and compositing operations vs. GL based draw operations.  The eglWait* functions are probably for apps where a lot of mixed-mode rendering occurs and must be coordinated, e.g. where one thread is drawing the GL stuff and another is updating the decor, overlays, etc. drawn using a different API.  I think they are used in the SDL Android example code to guarantee compositing safety at the possible expense of performance.  I.e. they erred on the side of caution, but I don't think the use is necessarily prescriptive.

In our case, that "other stuff" is indeed the Android OS, refreshing the Action/Menu bar, Navigation bar, context menus, and GameOverlay, all of which occurs on a different thread.  But in our case, there's no need for them to be in perfect frame sync as long as the GL surface never overdraws the "other stuff".  That's a big assumption (see next paragraph) but for the sake of discussion assume that it holds.  My guess is that the new Adreno chipsets have some additional optimizations that make it more lazy in refreshing the "other stuff".  When Garrett enabled the "Show touches" option in the Android settings, that forced the chipset to refresh the "other stuff" at a higher rate and hence allowed the app to run at a higher FPS.

I'm not sure about earlier Android versions, but at least for the JellyBean devices tested here, the Android layout manager (via the 'merge' object) seems to be smart enough to keep the two layers separate and not allow GL to overdraw the "other stuff" even if they're updated at different rates.  I'm not sure if all Android versions and chipsets have these smarts, though.  The main regression I could imagine this introducing would be flickering of the GameOverlay, Action Bar, and in-game context menus.  I think that's the main risk we should keep an eye out for.

Edit: One other piece of info: eglWaitGL (http://www.khronos.org/registry/egl/sdk/docs/man/xhtml/eglWaitGL.html) is functionally the same as calling glFinish (http://www.khronos.org/opengles/sdk/1.1/docs/man/glFinish.xml), which the official Khronos docs say
Quote
glFinish is NOT required before a call to eglSwapBuffers or glReadPixels.   glFinish can take some time and for performance reasons it is best to use this function infrequently and only when necessary.
Title: Re: HTC one FPS
Post by: littleguy on May 21, 2013, 09:31:03 AM
If we do find the flicker regression on some devices, the easy solution would be to add a user preference (disabled by default) and call the eglWait* functions only if it's enabled.  We could add it to the video settings and call it "Eliminate menu/button flicker" with the description text saying "May degrade game speed" or something.
Title: Re: HTC one FPS
Post by: littleguy on May 21, 2013, 11:43:50 AM
Now I just need to get my Moga Pro fully compatible with the app and I'll really be on the way to 64 bit greatness!

Please start a new thread on the issue and we'll be happy to work with you on it.
Title: Re: HTC one FPS
Post by: jnewbern on September 24, 2013, 08:57:24 PM
Hi all,

I have a HTC one and am having issues with lag on Zelda OOT using the version of mupen on the google play store. I found this thread and tried the no wait test #4 version of mupen and it worked great. No lag. But unfortunately the no wait version in this thread does not have native support for my moga pocket controller. With the no wait test version I can use the universal moga driver but that does not support the analog sticks. It treats them as just touch pads. Is there a version that has the htc one fix and supports the moga analog sticks? Thanks for all your help devs I appreciate all your hard work.

big fan.
Title: Re: HTC one FPS
Post by: littleguy on September 24, 2013, 09:23:33 PM
The unofficial MOGA universal driver definitely gives analog control, but only if you're rooted.  Otherwise I think they just act like a d-pad.  See this thread for more info:
http://www.paulscode.com/forum/index.php?topic=877.0

The version available in the Play store does contain all the fixes described in this thread.  These fixes have been there since version 2.3.0 (see the changelog in the About menu).

Just to be clear, "lag" is not the same thing as low FPS.  You should be getting high framerates (30 FPS or more) with the HTC One.  If your audio lags behind the video and input, that's a different problem altogether.
Title: Re: HTC one FPS
Post by: Paul on September 24, 2013, 09:26:26 PM
The bugfix should already be built into the app on the play store.  Are you using Mupen64Plus AE (and not one of the ripoffs like Super N64)?  Take a look at the version number (press "About" from the main menu), and let me know what it says.  I suppose this could be a regression.  Can anyone else with one of the problem devices confirm that the extreme lag is back in the latest version?

--EDIT-- Littleguy beat me to the answer :)
Title: Re: HTC one FPS
Post by: jnewbern on September 24, 2013, 09:41:27 PM
So I did a little more investigating. The version of mupen64 i am using from the play store is 2.3.4. And I see from the changelog that it incorporated the htc one fix a few versions ago. But I still do notice a different between the no wait version from this thread (2.2.1). I am using the gles2n64 plugin with default settings. In 2.3.4 When i run around kokiri village in the beginning of the game I get 19-21 fps and occasionally it drops down to 15 fps with noticable visual lag and audio breaks. When i use the no wait version 2.2.1 my fps is 19-21 and never dips down when i run around. Honestly 19-21 seems a bit low in general but the game seems to run just fine to me except for when it dips down to 15. So obviously i dont know what is causing the issue. Any help would be appreciated.

Also I noticed that links boots seem to be sunk into the ground a bit when running over the main paths through the village.

FYI my htc one is not rooted and running stock android. Thanks
Title: Re: HTC one FPS
Post by: Paul on September 24, 2013, 09:44:52 PM
There have been quite a few changes since 2.2.1, so it is possible one of them resulted in a speed regression on the HTC One.  If you have the time, it would be helpful if you could go back through older versions (posted in the Beta Testing Has Begun thread in the Announcements/ General Discussion board), and find which version the speed difference first appeared.
Title: Re: HTC one FPS
Post by: littleguy on September 24, 2013, 09:48:12 PM
Ok, thanks for the quick update.  The difference in FPS you describe is relatively subtle compared to the original posts of this thread... those users were having dramatic reductions in FPS (like 5 FPS when they should have 30 FPS).  It is possible that the latest version has a new bug (regression) that's causing some hiccups for you.

IIRC I get about 15 FPS on my Tegra3 in the Kokiri village.  That's actually a very graphically demanding section of the game.

Edit: Now Paul beat me to the punch :)
Title: Re: HTC one FPS
Post by: jnewbern on September 24, 2013, 10:07:13 PM
Thanks for the speedy responses you two :). So yeah going through all the previous versions might be a bit time consuming for me :( But i will be sure to let you know if i start to tackle it. I did try out super smash bros and super mario 64 in 2.3.4 and got 30-60 fps and 28-30 fps respectively. They both run great and that makes me super happy :).

So for zelda oot concerning the issue with link looking like he is sunken ankle deep into the road in kokiri village? is this a known issue? He looks fine running over the green part but looks suken in on the road/paths. Sorry i wish i could take a screen shot for you but I dont know how.

Thanks again for all your hard work.
Title: Re: HTC one FPS
Post by: Paul on September 24, 2013, 10:15:19 PM
That foot-sinking behavior could be related to polygon offset.  You might try tinkering with the "Flicker reduction" setting (In video settings).  If you find one that works better, let me know.
Title: Re: HTC one FPS
Post by: littleguy on September 24, 2013, 10:17:46 PM
If you ever want to take a screenshot, hold down the power and volume-down buttons at the same time.
Title: Re: HTC one FPS
Post by: xperia64 on September 24, 2013, 10:19:10 PM
Also, if none of the profiles work well, try this build: http://www.paulscode.com/forum/index.php?topic=1179.0
Set profile to custom and mess around with the value until you get something that looks decent
Title: Re: HTC one FPS
Post by: jnewbern on September 25, 2013, 05:13:38 PM
Well Paul I went through and tested all the versions from 2.2.1 to 2.3.4. I found that when I got back to version 2.3.4 I was not able to recreate the slow downs i was initially seeing. I can only assume the whole issue was user error on my part. Before I did all the testing I was sure to reboot the phone and make sure nothing extraneous was running. I have been trying other emulators and been forced to switch between moga pivot and the universal moga drivers and have noticed that sometimes the force close of pivot doesnt always work and ends up causing funky things to happen. My best guess is i was having some resource draining conflicts between the two when I first was seeing the slow downs.

On another note I tried the different flicker reduction profiles but none of the fixed the issue with the paths in kokiri village. The different profiles did raise or lower the path but none of them hit the mark just right. So I will try the build xperia recommended and try some custom values.

I have also noticed the eyes and mouths of certain characters in super smash brothers are missing. Is this because of the polygon offset also? Perhaps the mouths and eyes are being drawn underneath the skin?