I am trying to write a libgdx livewallpaper (OpenGL ES 2.0) which will display a unique background image (non splittable into sprites).
I want to target tablets, so I need to somehow be able to display at least 1280x800 background image on top of which a lot more action will also happen, so I need it to render as fast as possible.
Now I have only basic knowledge both about libgdx and about opengl es, so I do not know what is the best way to approach this.
By googling I found some options:
split texture into smaller textures. It seems like GL_MAX_TEXTURE_SIZE on most devices is at least 1024x1024, but I do not want to hit max, so maybe I can use 512x512, but wouldn't that mean drawing a lot of tiles, rebinding many textures on every frame => low performance?
libgdx has GraphicsTileMaps which seems to be the tool to automate drawing tiles. But it also has support for many features (mapping info to tiles) that I do not need, maybe it would be better to use splitting by hand?
Again, the main point here is performance for me - because drawing background is expected to be the most basic thing, more animation will be on top of it!
And with tablet screen growing in size I expect soon I'll need to be able to comfortably render even bigger image sizes :)
Any advice is greatly appreciated! :)
Many tablets (and some celphones) support 2048 textures. Drawing it in one piece will be the fastest option. If you still need to be 100% sure, you can divide your background into 2 pieces whenever GL_MAX_TEXTURE happens to be smaller (640x400).
'Future' tables will surely support bigger textures, so don't worry so much about it.
For the actual drawing just create a libgdx mesh which uses VBOs whenever possible! ;)
Two things you dindn't mention will be very important to the performance. The texture filter (GL_NEAREST is the ugliest if you don't do a pixel perfect mapping, but the fastest), and the texture format (RGBA_8888 would be the best and slowest, you can downgrade it until it suits your needs - At least you can remove alpha, can't you?).
You can also research on compressed formats which will reduce the fillrate considerably!
I suggest you start coding something, and then tune the performance up. This particular problem you have is not that hard to optimize later.
Related
A lot of different questions were asked around the question "How to deal with Textures for different devices in Libgdx". I would like to summarize information here and ask what is not clear for me still.
Tips for the good quality of Textures:
Forget about the approach to build huge Textures with transparency. RAM will be destroyed on low devices. explanation
Use Viewport. Aspect Ratio for Textures will look the same for each device. explanation
Avoid raw textures. Apply the TextureFilter. explanation
Use AssetManager. It allows you to load, dispose, make screen loading progress in the easiest way. example
Use different resolutions for different devices. Use ResolutionFileResolver. It allows Libgdx automatically to choose the most appropriate Texture for each device. example
Note: feel free to add ideas to this list
The question is about the last point. Android platform has a huge amount of different phones and tablets. I understand that it doesn't make sense to create each Texture for each Resolution.
How many resolutions to cover separately? I suppose to take 3 categories: for lower, middle and high devices.
If so - how to choose the most appropriate one for each category?
Are there any cases to use the same Texture somewhere? (small icons, HUD, etc)
How can I do antialiasing on triangles on the entire render? Should I put it on the fragmentShader? Is there any other good solution to improve this sort of thing?
Here is my "view", with very crispy edges (not very nice).
After doing some Deep research, I found that It's in fact pretty simple, and the most comonly done is to render like there was a screen 4 times bigger (or even more than 4 times). After rendering to this much more bigger screen, the GPU will take the avarege of that area and set the pixel color based on that.
It's pretty easy to enable this with this library:
https://code.google.com/p/gdc2011-android-opengl/source/browse/trunk/src/com/example/gdc11/MultisampleConfigChooser.java
However,you should keep in mind, that it will spent 4 or more times time to render everything, meaning more time to process, and perhaps, less FPS...
Also, if you are emulating an android device with OpenGL, find out if your GPU supports this kind of Multisampling. Mine for example, doesen't (Tegra).
Here is the final result, with and without multisampling:
I am looking at making a simple game. Without giving out the entire story, I need to draw two pieces of fruit (with arms and legs), who do different movements. They can do a few different actions (less than 5) and they also react to each others actions.
I'd like it to look simple. Very 2D, kids sort of graphics. Maybe shaded, but nice bright happy colours.
Let's say an action is to 'throw ball'. I'd like to see a semi smooth arm action. Smooth if possible.
So, I found a tutorial, which used sprites, and a PNG with 3 different states of a person walking. So, very basic. And I was able to make it walk across the screen, leading each part of the PNG for each state, and iterating through that over and over again, while moving the image.
I got pretty happy with my progress, and would like to base my game on that sort of model - but ... is using sprites, and loading areas of the PNG to make the image move correct? My PNG would be large if I want maybe 20 images just to throw the ball.
But if that's the right way to go, then great! It seems you can go with OpenGL and all that, but that's for 3D graphics right? Using sprites, and a few PNG with images would be OK for perforamnce and all that?
OpenGL is a valid choice for 2D or 3D, you shouldn't have any performance issues.
It will work fine for your game, and would likely be much smoother than trying to use android animations, which are not hardware accelerated on Android 2.x.
I am learning to develop games with Android using libgdx, a framework for programming in Android using OpenGL ES and on desktop with Java using LWJGL. The device I am testing on (HTC Hero) quotes a maximum texture size of 1024 and a maximum stack depth of 2. However, when I create textures at this maximum size, they will not load, instead displaying a white square where the texture should be. The textures are this size because they are packed sprite sheets, and it is preferable to keep them at this size. With regards to the stack depth, the device will also show a white square if more than 1 texture is used simultaneously, so it seems as though the maximum values given by OpenGL ES are one step above that of the device's actual performance. Can anybody help me out? Thanks
Actually there are scales for texture in libgdx, like texture must be exponent of 2. so as you said you are running with sprites please go through once how to work with sprites in http://libgdx.googlecode.com/svn/trunk/tests/gdx-tests/src/com/badlogic/gdx/tests/. I hope it works
I find this question to be of value despite of its age.
In current devices going 1024x1024 is pretty much safe. But if it doesn't work on one of yours, go lower. 1 or 4 draw calls won't affect much performant wise.
My game already consists of an atlas the size of 1024x1024 as I am aware that is the max size for a texture. The problem is I need about 1-2 more of these 1024x1024 textures. That should give me 3 glBindTexture() calls which I know is huge performance drag. I have not tested it yet because I am having other problems currently but would this slow my application by a considerable amount? Is there another solution?
If you are worried about any performance loss, I'd recommend you to profile your application so you really can see where your application's bottleneck is, and then come back if it turns out to be horrible.
Three big atlas textures are still better than many small textures that you bind over and over again.
Currently my game has around 6 512x512 texture atlases and I still dont require any loading screens on any phone so far. Although if you are going to do a lot of binding you may want to look into making a Batcher class that will submit all of your vertices to the GPU at one, it will speed up your application considerably