See frame rates that were a consistent 60fps, running at 10-12fps
Nothing has changed in these apps aside from being recompiled. I’ve installed the apk directly to the device to ensure it was the debug mode that was effecting this (though it didn’t have any noticeable impact prior to updating), though, this changed nothing.
I tried an empty “New Project” with the same results.
I ran a version of one of the apps that was compiled and installed prior to updating, it runs at a consistent 60fps.
erf...so much....
What's the device? your transformer tablet?
I'm gonna test on mine, but i didn't notice a drop in performance since RC2 (the other way around even...)
@nehon said:
erf...so much....
What's the device? your transformer tablet?
I'm gonna test on mine, but i didn't notice a drop in performance since RC2 (the other way around even...)
Sure about the new project part? Sounds crazy…
Yep yep… it’s anything I build for Android (and yep on the tablet as well). It’s likely my PoS machine if you don’t see any issues trying this. Though, I can’t seem to find a reason for it. And it seems odd that the version I have from prior to updating runs just fine.
@iwgeric said:
I haven't upgraded to the 3.0 final sdk yet, but I am running android projects with the latest engine from svn without seeing this issue.
Not much help, but just wanted to let you know. I do plan to upgrade the sdk soon. I’ll let you know if I see what you are seeing.
Thanks… I’m hoping it is just an issue on my side (My machine is flaky at best). I appreciate you all looking at this.
Sorry for drudging up an older post, but still having the same issue.
@iwgeric
I’m not seeing any output from potential logging, however… this doesn’t mean much. Any suggestions for ensuring there is nothing in the way of excessive logging happening?
EDIT: Actually… I just turned logging off completely to see if it would help… and notta. The best FPS I can get running ANY JME app on android is now 10fps. Is it possible that something got corrupted when installing JME 3.0 stable? Or?
@t0neg0d said:
The best FPS I can get running ANY JME app on android is now 10fps. Is it possible that something got corrupted when installing JME 3.0 stable? Or?
There was an update to stable a couple of days ago. Nothing to do with your issue, but it should force the jars to be updated.
I’m quite surprised that creating a new “Basic Game” runs at 10fps. It’s unshaded and has no real logging. When I run that, I always get 60fps.
I’ll keep thinking about it, but I don’t have any other ideas right now.
I tried uninstalling JME and re-installing, notta.
I tried re-installing the Android SDK, notta.
Not sure what has changed, but these are the possibles:
a) Something changed between the last pre-release 3.0 candidate nightly and the actual release. Or
b) My machine is corrupting something when building the .apk - This seems unlikely, as the .apk, would likely just not run.
c) Something is f’d up on my tablet. This is unlikely, as I have a pre-release compile of the same test apps I have been running that STILL run at 60fps. It’s the recompile(s) that now run at 10fps.
I’m going to try this from another machine and see if it specific to this shitty computer (which would be good, because I can compile from another machine if that is the case)
If this doesn’t help, I’m at a loss for how to fix this and sorta leaves me option-less for continuing to use JME as a dev platform =( This would be ultimately sad for me… but kinda hard to proceed with developing in JME if apps just won’t run correctly.
Anyways… any and all thoughts would be GREATLY appreciated.
Once you have exhausted all other possibilities, one approach would be to check out the JME SVN tree at some point where it is expected to work… then move forward or backward in revisions until you find the point it breaks or doesn’t.
It’s painful. I’ve done this a few times over several months of revisions but sometimes it’s the only way.
@pspeed said:
Once you have exhausted all other possibilities, one approach would be to check out the JME SVN tree at some point where it is expected to work... then move forward or backward in revisions until you find the point it breaks or doesn't.
It’s painful. I’ve done this a few times over several months of revisions but sometimes it’s the only way.
This is definitely next on the list. I really want to figure this out as I enjoy developing in JME more than I could possibly explain.
1 - did you check the proc utilisation ? The gpu use ? Maybe that’s the new update includes some update from lwjgl which could have some problem with their drivers. I am maybe saying something stupid, as i don’t know if there is something like a graphic card on a tablet.
2 - maybe (once again, it’s a stupid suggestion ^^) it’s something in the start screen, like the vsync or something like that, which could have a different “default configuration” in the old version. So, you could have launch the application with different settings for that.
Also, a less stupid suggestion : i think that there is some “debug” tools out there which can show in which method you app lose time. You could run your application in its old and new version and see if a specific method is involved in this comportement.
Also … maybe just reinstall jme could do the stuff. After all, the “turn on/off” trick is still working in a lot of case.
While i was writing this, i thought of something else : a rights problem. Maybe your new app is running in a sandbox or something like that, cause your antivirus decided that there is something wrong in the new version and decided to isolate this dangerous application.
This is definitively not something wrong with your program, as you said that you also has 10 fps on an “empty” game.
P.S. : for the “debug and see where application lose time” stuff, if you can have an “empty” game done with the old version, it will be easier to find from where come the problem.
(sorry for my bad english : i am not a native english speaker and i am very tired tonight).
@bubuche
Thanks for the suggestions. I’ve tried a fresh install… that didn’t work. I’ll give the other suggestions a go.
@pspeed@iwgeric
Well… After resolving any and all caching issues with my tablet, I’ve narrowed it down to how transparent pixels are drawn. If you render an object with a small completely transparent texture, your frame rate TANKS. Using semi transparent textures (i.e. some transparent pixels, other opaque pixels) has varied amount of terrible-ness associated with them depending on the amount of transparent pixels.
This is using the Unshaded material from JME. Setting the additional render state : blendmode has no effect one way or the other.
Since this is a new probelm, is anyone aware of any changes in how the android renderer deals with textures? Specifically concerning alpha?
it’s @nehon, talking about a “huge performance improvement”. So, even if it more than likely not connected to our problem, there is a little chance that we are facing a regression.
One other thing you can do to test (a bit) your theory is to disable all the “frame/vertex/face/whatever” stuff in the empty game - because these informations are drew (draw ? drawn ? bad english, sorry) on a semi-transparent surface.
I don’t think it comes from android, as you said that the old game is still running fast.
@t0neg0d said:
Well... After resolving any and all caching issues with my tablet, I've narrowed it down to how transparent pixels are drawn. If you render an object with a small completely transparent texture, your frame rate TANKS. Using semi transparent textures (i.e. some transparent pixels, other opaque pixels) has varied amount of terrible-ness associated with them depending on the amount of transparent pixels.
This is using the Unshaded material from JME. Setting the additional render state : blendmode has no effect one way or the other.
Since this is a new probelm, is anyone aware of any changes in how the android renderer deals with textures? Specifically concerning alpha?
Is this the same issue you originally posted about? I thought you said you ran a new “basic game” and the framerate was still at 10fps? The Basic Game template doesn’t use any textures, only a color on a cube.
@bubuche said:
iwgeric : you forget the "display info" part. Which is transparent (translucent actually).
that's true, but that has nothing to do with Nifty.
Also If the display is the problem, removing the detailed display and just keeping the fps test could be worth to test
Yes… it is the BitmapText that was adding the transparency issue. However, it is worth looking into why a texture sample with transparency would cause such a significant frame rate loss. May just be specific to this tablet? /shrug
But, it you would like to duplicate the issue just apply a transparent texture to any unshaded object and there it is!