HTC one FPS

[littleguy]

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

[mikethebigo]

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!

[Paul]

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.

[littleguy]

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

[Paul]

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

[littleguy]

For quickly testing the NativeActivity theory, you could just comment out lines 132, 133, 190, and 191 in MenuActivity, and tell testers to enable touchpad input...

[Paul]

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 (simulates rapid touches on the game surface - screws up the touchscreen controls though)

Test #2: The 'Invalidator' (repeatedly does postInvalidate on both the game surface and the touchscreen overlay)

EDIT: And a third one:
Test #3: Touchy-feely B (simulates rapid touches on the touchscreen overlay)

[littleguy]

Another one I'm curious about would be to comment out lines 290 and 295 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).

[Garrett]

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.

[Paul]

Ok, here's a fourth one:

Test #4: No Wait (removed calls to eglWaitNative and eglWaitGL)

[Garrett]

Ok, here's a fourth one:

Test #4: No Wait (removed calls to eglWaitNative and eglWaitGL)

This is running the game at full speed!
(and yes, I changed my governors back to OnDemand)

[Paul]

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.

[Garrett]

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

[Paul]

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.

[Garrett]

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.