www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: icarusfactor on January 09, 2012, 09:24:47 pm
-
I could not get my Android 2.2 JPCT code to work on Android 4.0. I updated the build and that let me compile, but get errors on texture size now when I try to run the app.
-----------------adb logcat errors-------------------
I/jPCT-AE ( 4921): Loading Texture...
I/jPCT-AE ( 4921): [ 1326139632424 ] - ERROR: Unsupported Texture width: 768
I/jPCT-AE ( 4921): [ 1326139632427 ] - ERROR: java.lang.RuntimeException: [ 1326139632424 ] - ERROR: Unsupported Texture width: 768
-----------------------------------------------------------
I had compiled it under target 7 and 1 - 1 being 2.3 based stuff and 7 being 4.0 apis with same results.
-
texture size must be power of 2, ideal is square... 8, 16, 32, 64, 128, 256, 512, 1024, 2048
-
That is wild, this compiles under 2.2 Froyo just fine and it is a power of 128, 768 should be ok and is square just 768. It worked because I based my app base size on this and had been working fine until I upgraded.
-
768 isn't a power of two. Depending on where you store your textures (for example in drawable, which i don't recommend), the OS might have scaled them on 2.2.
-
I am using a new android SDK so that may be the case how it compiled in the images from resources. Will try that later and see , thanks.
-
Try placing your image files in res\drawable-nodpi to avoid resizing and downsize the 768x768 image to 512x512 to keep the GPU happy.
-
Finally getting chance to look at the images and my background image has the size is 1024 x 1024 not 768x768 , all other images are 512 x 512 or smaller , so I don't even have any 768 width files. Now I am even more confused nor do I set 768 for any temp buffers in my app source.
-
What res folder are the images placed in?
If they are in drawable-hdpi, drawable-mdpi, or drawable-ldpi, there is a good chance that they are being resized automatically to match the DPI of the screen.
Create a folder called drawable-nodpi, move the images in there, then clean and refresh the project.
-
All my images are placed in /res/drawable only the icon is in each of the other directories. Will try renaming the directory to /res/drawable-nodpi
-
Forgot about the drawable folder, the images will also be resized if in that folder.
-
Thanks , I renamed the folder to a -nodpi and it got past that error but I am now plagued with another error . I don't get this error under the 2.2 just wondering how I get around this or get ICS to release more mem for my app.
E/AndroidRuntime( 2582): java.lang.OutOfMemoryError
-
Something must be using too much memory. If you are allocating large arrays, null them after usage so the garbage collector frees them.
Use the below function at various areas during initialization to see how the RAM accumulates. For example, call logMem() before loading all the textures, and then after they are loaded.
public void logMem()
{
DecimalFormat df = new DecimalFormat();
df.setMaximumFractionDigits(0);
df.setMinimumFractionDigits(0);
String sRAMString = "RAM allocated: " + df.format(new Double(Runtime.getRuntime().totalMemory()/1048576)) + "MB of " + df.format(new Double(Runtime.getRuntime().maxMemory()/1048576))+ "MB (" + df.format(new Double(Runtime.getRuntime().freeMemory()/1048576)) +"MB free)";
Log.v(TAG, sRAMString);
}
1024x1024 textures use a big chunk of memory when loading them so think about decreasing the size to 512x512
-
Thanks all , I think I need to do a redesign of it to clear up the out of memory problem, this was my first try making an app and it worked but just kind of went along as I learned stuff. Will make a plan so it will scale for X amount of objects.
-
As usual, i'll link to the wiki: http://www.jpct.net/wiki/index.php/Reducing_memory_usage (http://www.jpct.net/wiki/index.php/Reducing_memory_usage)... ;)
-
I was thinking of using a database for re-factoring the memory footprint down. I did not know how Android did DB's when I started so I kept "ALL" static and dynamic data in memory. Will plan to move all the static to DB and to try to move as much dynamic data I don't need instantly as well.
Now knowing how Android uses SQLite is still a pain , but now that I have "rooted" my Tablet will be much easier to debug and manage DB errors.
-
Another option would be to use the DDMS tool to view the memory heap usage while the app is running. http://developer.android.com/resources/articles/track-mem.html
16MB is quite a lot for a basic scene with a skybox. My app has about 100 objects (some models have 4000+ vertices) with 15 decent sized textures amongst other things and the RAM usage is only 26MB.
Post up your code if you wish, we may be able to spot the problem.
-
My problem with scale was rendering DNA structures with 10,000- 20,000 atoms and not counting bonds between each. Placing this data structure in a DB and reading only ones that are in visual range and trimming down further making touch active only ones that are close to viewer. Got to be a way to do it. But had put this on the back burner until I could find a way to do it. DDMS is a good tool.
-
Ah that's what is using so much memory, I thought you had just a basic 3D scene.
I had the same issue when I jumped from Gingerbread to Honeycomb, the RAM usage was almost double and could not figure out why. I'm assuming it's the result of Android taking advantage of the larger RAM sizes in newer devices to minimize GC pauses.
There is a simple solution but you will need to have separate APK's for 2.x and ICS.
Honeycomb introduced the large heap parameter in the AndroidManifest.xml file which increases the application RAM from the usual 16GB/24GB/32GB size to 256MB.
Add android:largeHeap="true" to this tag:
<application android:icon="@drawable/icon" android:largeHeap="true" android:label="@string/app_name" android:debuggable="false">
Also ensure the minimum SDK is set to 11 if you want Honeycomb support, or 14 for just ICS support.
-
...but it's not guaranteed that this parameter actually does anything on a specific platform. I wouldn't rely on it...
-
That's true, 256MB is what I get on a Tegra2 3.2 Tablet with 1GB RAM. If it's a 'no-name' Tablet with say only 512MB total RAM then I wouldn't expect much of an increase.
-
That is a really good tip. Yes I thought it was no larger than 32m.
256m is a big plus. But to make it scalable the Android Database
gives me 2 gig of space, well within the limits I need for a structure.
But also understand if to do that, it would be best for making two
versions.