I am working with AndEngine and OpenGL ES 2.0. I keep reading about GL_MAX_TEXTURE_SIZE and how I should keep my texures under 1024x1024. I started wrong before and while using tilesets in TMX extension (doesn't really matter what it is, if you don't know AndEngine) I get to a tileset that makes a texture wider than 1024px. I am thinking of splitting the tileset into two, making them "safe". But I can't find any device released in last couple of years that has this limit set under 2048x2048. Is there any list or website I can use to filter devices by GL_MAX_TEXTURE_SIZE?
I read the following questions:
Minimum required Texture Size for compliance with OpenGL-ES 2.0 on Android?
Is there any Android device with screen size greater than GL_MAX_TEXTURE_SIZE?
And I used this site to search for devices. But I can't search by/filter by GL_MAX_TEXTURE_SIZE, which makes the search tedious. I am asking mostly because I started wrong, it's a hobby project and the amount of work might be too large compared to the number of possible devices that will be enabled (I expect 0).
1024x1024 is about the safest you can go on any device, especially on older ones. Newer devices shouldn't have any problem, although I've seen recent devices (I recall a Galaxy Nexus, the newest ICS update fixed that though) render white quads with texture sizes of size 2048x1024.
If you're targeting new devices and want to keep older ones compatible, it shouldn't hurt to split your tilesets. After all, you aren't likely to do too many context switches if you use two or three spritesheets for background, etc.
If you still have the individual image files, breaking them into small sized Atlases or custom sized atlases is easy if you use the TexturePacker2 tool from the LibGdx library.
I don't know the exact limitation of devices, but it's always better to take into consideration the lowest end of device you want to support and build upward from there. Using the LibGdx tool, you can easily change your mind later, so it's the most flexible solution.
Look at:
LibGdx TexturePacker
Related
I have created an openGL app in android that has a few textures that I have created in different sizes (1024,1024 and 2048,2048) I picked 2048 because that's what the galaxy s3 supports. I was wondering if there is a way to filter what phones can see my app on max_texture_width I have looked at several resources
e.g.
http://developer.android.com/guide/topics/manifest/supports-screens-element.html
http://developer.android.com/google/play/filters.html
and couldn't find any help, I can see a lot of ways to do this programmatically such as:
Reasonable texture sizes in android
but since the smaller of my textures is 1204x1024 and some graphics cards would crash on this I don't want my app to be able to get that far. Anyone got any advice on how to solve this? If I were to create a smaller texture size of 512x512 I will need an additional algorithm that I (probably) cannot write within the time constraints due to other reasons.
Thanks
You cannot filter apps by declaring max supported texture size in manifest, only on supported texture format(s).
Alternatively, you can filter your apps on Google Play per device, but there are way too much devices for you to check compatibility with.
I've read this question but am still uncertain of the value of different DPI targets.
Doesn't supporting multiple density images add to the .apk file size, whereas just using high-res images offers a solution for all screens (using automatic scaling)? There's still only one binary for users to install unless one limits the app to phones and tablets, so the smaller the file, the better.
Is downscaling of images dependent on hardware implementation and sometimes messy nearest-neighbour resampling is used, or can I be confident it'll be a bilinear resampling no matter the hardware, which is fine for photos? And is there a significant performance gain in providing suitably presized bitmaps?
It seems to me that the extra meg or two of asset files may be more cost than gain.
I was toying with the same thing myself. Eclipse makes it easy to add every resolution as you can simply add an Android Icon Set which automatically creates the right sizes for you, it makes the app a bit bigger. Apparently XHDPI is only supported from Froyo (API 8) so if you're going to support before that you need to include HDPI. Also older devices, the rescaling doesn't look as nice and it's slower but the new devices, there's no real difference. At the Google IO I recall them saying it's okay just to use the XHDPI if you're targeting at and above API 8.
I'm trying to develop an app that uses opengl on android, and ideally make it run on any phone as old as the original droid (or at least any phone that has OpenGL ES 2.0 support). Currently, I'm using a 2048x2048 ETC1 texture compression. It works fine on the Droid X I'm testing it on, but I currently don't have an original droid to test it on, and I can't find much data on this topic either. I know the G1 didn't do well with textures bigger than 512x512, and the droid seems to do fine with images as large as 1024x1024, but what about 2048x2048? (Again, etc1 compression, so it's about 2 MB large). Also, because ETC1 doesn't support alpha, I would like to load up another ETC1 texture to support an alpha channel. Is this a pipe dream?
Basically, I would like to know how much space I have to load texture data in android phones no older than the original droid, at least without the whole thing slowing down drastically.
You can query the MAX_TEXTURE_SIZE to get the maximum texture size, or you can look up your phone on http://glbenchmark.com (you can find the Droid info here). The G1 did not support GLES 2.0, AFAIK.
Loading up several textures should definitly work, especially when they are not more than 2 MB each. But you will of course be restricted by the size of the memory available.
Also, to have optimal performance you should mipmap your textures. Since you are using ETC, this must be done offline.
For a guide to how to use ETC1 with alpha, see here.
My Android app has been out for several months and works fine on any number of WVGA phones like the Droid, Droid 2, Galaxy, etc.
On the Motorola Xoom, however, a small portion of the textures load with white boxes where the images should be.
Researching online the most usual cause for this appears to be not using power of two textures. This seems an unlikely explanation since they work fine on so many other devices. Also, I am using power of two textures. The one caveat there is that I'm loading a bunch of bitmaps into a 1024 by 1024 texture dynamically. The code I'm using is from a now defunct library called Rokon, the relevant texture atlas code is here: http://code.google.com/p/rokon/source/browse/trunk/src/com/stickycoding/rokon/TextureAtlas.java?r=260 -- Like I said, I'm skeptical this could be the cause since it works on so many other devices AND many of the textures I am loading this way do work fine.
But I'm not sure what else could be causing it. A memory issue seems unlikely given that amount of memory available on the Xoom compared to the other devices the app works on.
Right now I don't own a zoom, but I can replicate the issue via DeviceAnywhere (where I see white backgrounds).
Nothing of interest shows up in LogCat either.
I know this isn't much to go on, but I'm at a loss here, what kinds of potential causes should I be looking at here? Thanks in advance for any ideas.
Try using glGetError() to see if OpenGL throws any errors
Is your application 2D or 3D? When you're drawing your sprites on the screen; which method are you using?
If your texture is white during onDrawFrame that probably depends on:
An untextured quad (using VBO:s or standard Vertex Arrays) - probably not, because it works on other devices
Xoom lacks support of the draw_texture extension - if you're using 2D
Xoom lacks support of VBO:s (Vertex Buffer Objects) - probably not, almost every Android device out there supports VBO:s
Do you have any sort of texture compression implemented that Xoom doesn't support?
At runtime, use this code to get the extensions and check if they're available:
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
boolean supportsDrawTexture = extensions.contains("GL_OES_draw_texture");
// Continue here and sooner or later you should see where Xoom lacks support
// where other devices doesn't.
Is it possible that you're falling foul of Android's automatically-resize-bitmaps behaviour? Print out the bitmap sizes as they are loaded to check, or move them to res/drawable-nodpi to avoid the behaviour entirely.
Is it possible that your texture exceeds 2048 pixels width or height? That's the maximum allowed texture size on XOOM.
To put some context, my game has been developped for android 1.5. So it was using the lowest resolution by default on any android phones. Which was great, game was running fast and all.
Now I added support for scoreloop which required my game to support android 1.6. When I runned the game I realized everything got smaller since I used unit dimension without looking at the screen density.
Now that I fixed sizing. I realize that my game seems a bit choppy. I believe that redrawing on the new screen resolution is the problem.
I draw my game in a Canvas in a SurfaceView. How can I make it faster? I use default functions like drawCircle, drawLine... I believe reducing the screen resolution should help since I don't need high screen resolution. I just don't know how or if it's possible.
Or may be doing my drawing in opengl would solve the problem too.
Read this : http://developer.android.com/guide/practices/screens_support.html
You should use the pixel format depending of your needs.