Sorry your browser is not supported!

I whas more or less looking for a solution to agk and tegra devices problems.

When i found this thread about box 2d problems on various android os.

Here is something that sounds intresting this guy writes.
-------------------------------------------------------------------
Seems to be a bug with accessing system time in C/C++ with the NDK.
It's supposed to be low latency but it seems with different versions of android, that is hit and miss. I call it a bug because something like this should be consistent on all platforms.

I'm in the process of rewriting the timer class to use C++11's chrono package, which is supposed to be guaranteed to select the highest resolution timer on the system you're deployed to.

Thanks. Your post did help, unfortunately it's led me down a disappointing road. It turns out that trying to get a reliable clock/timer reading on the NDK side of android is impossible. I'll post more details in my answer.

Her is his solution..............................................

As I mentioned in the comments here, this came down to being a timer resolution issue. I was using a timer class which was supposed to access the highest resolution system timer, cross platform. Everything worked great, except when it came to Android, some versions worked and some versions it did not. The galaxy tab 10.1 was one such case.

I ended up re-writing my getSystemTime() method to use a new addition to C++11 called std::chrono::high_resolution_clock. This also worked great (everywhere but Android)... except it has yet to be implemented in any NDK for android. It is supposed to be implemented in version 5 of the crystax NDK R7, which at the time of this post is 80% complete.

I did some research into various methods of accessing the system time or something by which I could base a reliable timer on the NDK side, but what it comes down to is that these various methods are not supported on all platforms. I've went through the painful process of writing my own engine from scratch simply so that I could support every version of android, so betting on methods that are inconsistently implemented is nonsensical.

The only sensible solution for anyone facing this problem, in my opinion, is to simply abandon the idea of implementing such code on the NDK side. I'm going to do this on the Java end instead, since thus far in all my tests this has been sufficiently reliable across all devices that I've tested on. More on that here:

http://www.codeproject.com/Articles/189515/Androng-a-Pong-clone-for-Android#Gettinghigh-resolutiontimingfromAndroid7

Update
I have now implemented my proposed solution, to do timing on the java side and it has worked. I also discovered that handling any relatively large number, regardless of data type (a number such as the nano seconds from calling the monotonic clock) in the NDK side also results in serious lagging on some versions of android. As such I've optimized this as much as possible by passing around a pointer to the system time, to ensure we're not passing-by-copy.

One last thing too, my statement that calling the monotonic clock from the NDK side is unreliable is however, it would seem, false. From the Android docks on System.nanoTime(),


...and System.nanoTime(). This clock is guaranteed to be monotonic, and is the recommended basis for the general purpose interval timing of user interface events, performance measurements, and anything else that does not need to measure elapsed time during device sleep.

So it would seem, if this can be trusted, that calling the clock is reliable, but as mentioned there are other issues that then arise, like handling allocating and dumping the massive number that results which alone nearly cut my framerate in half on the Galaxy Tab 10.1 with Android 3.2. Ultimate conclusion: supporting all android devices equally is either damn near or flat out impossible and using native code seems to make it worse.


http://stackoverflow.com/questions/9274932/strange-stutter-in-box2d-on-different-android-devices#comment11715806_9274932

All the problems this guy had with his android development seams to be the same agk have with various android os.

honeycomb/sandwich is very slow and box 2d is more then less choppy.

Did i find a Diamond for agk or is it a hit and miss?

If iam not wrong so would this affect all these parts in agk.
framerate counter.
getframe time
box 2d
and a whole other bunch of core parts.

His codeprojects page have a java solution that works alot better.

We use

in NDK for a high resolution timer, but he doesn't seem to make any mention of that.

One of the more intresting aspects is that there seams to be flaws in ndk when it gets to system time on various android os.

And you missewd this part

So my find didt help agk to work better on more android os

Seams like many other toolkits used this to solve parts of there choppy android apps.

Wath more could be the issue with agk apps runs slow on some android os?

Many apps i downloaded from goggle play in the begining does also run well on my old sandwich device that didt like them Before nowdays.

So there seams to be some issues that are fixable.

And i want agk to run as good as possible when i love its simplicity.

Part of the problem was the Tegra 2 GPU which had very limited pixel performance but was used on 1280x800 screens. I've been experimenting with reducing the frame buffer resolution and then letting it stretch to fill the 1280x800 screen but I don't know how widely supported this is.

Its pretty much the accelerated grafix that whas introduced on honeycomb and later that slows agk down.
And as you say the high resolutions on some to weak devices.

Do you have a snippet on the internal shader for sprites that i could look on and maybe help somehow?

And if its the stretch frame buffer you want to test so do i have a bunch of android devices to test on.
samsung galaxy tab 8.9
samsung galaxy s3 mini
sony experia arc
samsung galaxy y
zte skate
dmtech 10 inch tablet
single core cpus range from 800-1.2 mhz/GHz
dual core 1 GHz
android os gingerbread,honeycomb,sandwich and jelly bean.

Iam on my way to try to start a Company in sweden and building and hardware library in case.

Iam still attending various Courses on economics and other stuff on my spare time after work so iam not there yet

Edited...............
If you guys would add the possibilitys to do some basic shaders on sprites so would it be alot easier for users to find the pitfalls that may be in there?