http://docs.unity3d.com/Documentation/Manual/PluginsForAndroid.html is a pretty good overview of how to use AndroidJNI. Could come in handy to add more native Android functionality.
You should probably hold on to the class and method references instead of getting them all the time (assuming you actually do this). You will run into trouble if you dettach from the thread. You'll have to attach again and fetch the references anew.…
Actually, it could be solved differently via some native heap memory and a tiny static scratch buffer. i'll put that on my todo list, thanks for pointing it out!
byte array allocation when loading an image. that's done on the java heap, passed to C for decoding, then uploaded to the GPU. Only performant way to be able to handle InputStreams. Could use a shared scratch buffer but that would take away memory a…
JNI won't produce garbage if you work with direct buffers or arrays, using critical locking for the later. As i said, you won't be able to avoid JNI. Packing things into a JSON string is pretty much the worst thing you can do in terms of GC.
i work …
Accessing that pinned memory from within the Java Activity has to go through JNI, either by wrapping it in a direct ByteBuffer or by providing a JNI method that accesses the pinned memory in straight C/C++. Why go through all the hassle if you can u…
Sounds don't load immediately, first playback will fail if you call play immediately after load. You can register a listener iirc, or just wait. if you load multiple sounds and they all return 0 then you have a problem, loading a single sound and ge…
That's just for the Dalvik == managed Java heap. Textures go on the native heap (in case it's a shared memory architecture like on most mobiles) or on dedicated GPU Ram. That option won't help. Texture compression is the only option i can offer.
It is highly unlikely that you need all those images at once. Your only option is to only load what you need a specific time, e.g. within a menu, only load the menu assets, within a stage, only load the stage assets.
115MB compressed PNGs is way to much to load all at once. Create a simple ApplicationListener that just loads all your assets and see if the problem persists. If it does, reduce the amount of loaded assets until the app isn't crashing anymore. If th…
Got some time to look into it. First of all, 4096x4096 won't work on most Android devices, including the Tegra 3. That doesn't mean you need to sacrifice anything, just pack your sprites/tiles into more sprite sheets.
Next, i went through your code.…
GL_MAX_TEXTURE_SIZE is really only a best estimate, and you shouldn't rely on it. In any case, your texture size is likely the problem, i'll give your project a spin this weekend. In the meantime repack your textures and report back whether that wor…
We were kinda recognized by getting a dev kit, thanks to the kind soul called Nick and a lot of nagging on Twitter. A separate libgdx forum is not necessary imo.
Zip your project and send it to me. Otherwise you'll need to give us more info. Texture size, drawing method, some code. Whatever you can throw at us. My guess would be texture size, or a custom shader that's wonky.
Our entire test suites running fi…
Just remember that you can test all the things via the desktop project, including controllers. The emulator is neither a good indicator of real performance, nor does it faithfully reproduce GLES 1.x/2.0. I'll add x86 Android shared libs to the build.
A deadzone would fix it, problem is, the stick and trigger values are at their minimum/maximum. One of my controllers is already so bad that it reports -1 pretty much any time i press any of the O/U/Y/A buttons.
I hope the retail controllers will wo…
Last time i checked, eglSwapInterval has no effect on Android. iIRC that's due to the way compositing is done. Some manufacturers actually enable it to work, maybe the Ouya guys can chim in.
Tegra 3 is heavily fill-rate limited. A parallax background has quite some overdraw, interestingly enough, usually more than a full 3D scene. Cut outs, say via PolygonBatch are the way to go in that case.
Our ODK integration is live btw, gdx-control…
Thanks for the info to both of you. I was looking into the various protocols HDMI implements and it indeed doesn't report physical dimensions. Welp, guess i have to special case for the OUYA then :)
It's actually much easier:
1) connect the Ouya via USB2) adb tcpip 5555 (if you have more devices connected, you need to specify the Ouya's id)3) unconnect the Ouya from USB4) adb connect ip-of-ouya (do not include the port number)
That's it, no she…
