Develop Reference

Best practice for animating a few 2d sprites on screen

I want to add a few animated sprites to my application, drawn from spritesheets. There would never be more than three on screen at any time.
As I was researching this topic, I came across several technologies that support drawing and animating the sprites including lib gles, libgdx, cocos 2d etc...
However, because I believe I have a fairly simple use case, I was wondering if it is typically necessary to bring in these libraries to my project just to animate a few sprites? What is typically the recommended way to go about solving my problem that would not have a huge hit on performance?

Best way to achieve fluid animation in Android

I want to apply little tricky fluid ink animation as same as the below image:
I want to achieve using the basic classes only like applying scale, translate etc. I don't want to go with 2D or 3D. As I have checked some of the links they are suggesting frame animation but It doesn't have smooth transition.
Kindly suggest best way to achieve this animation.
Thanks,

"I don't want to go with 2D or 3D."
Well.. I don't know about you but those are the only options until we have 4D screens and mindsets.
But I guess you mean using 2D images or 3D models.
Unless you want to procedurally generate that (which can be quite a pain) I'd suggest using a spritesheet, there may be better ways to do this but I think a spritesheet on 30fps might be the easiest + fluid way to do this, increase FPS to increase fluidness (until the max of androids 60 fps screens)
Basically:
Create a (example) 256x128 sprite, and "manually" animate the sphere to the other side of the image, saving each "frame" and either create 1 big texture with all the frames (most efficient) or save each frame independently (lower on RAM if you manage it well, but it'll be hard to get 60 fps with this due to loading times)

You can check the recently announced Lottie library (by Airbnb).
It is a library for Android that parses Adobe After Effects animations exported as json with Bodymovin (related project) and renders them natively on Android devices.

Drawing large background image with libgdx - best practices?

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.

Making a full-screen animation on Android? Should I use OPENGL?

Say I need to make several full-screen animation that would consist of about 500 frames each.
Animation should be playing at a reasonable speed - supposedly not less, then 20fps - and pictures should be of a reasonable quality, not overly compressed.
What method do you think should I use?
So far I tried:
1. storing each frame as a compressed JPEG
2. before animation starts, loading each frame into a byteArray
3. as the animation plays, decode corresponding byteArray into a bitmap
and draw it on a surface view.
Problem - speed is too low, usually about 5-10 FPS.
I have thought of two other options.
turning all animations into one movie file... but I guess there might be problems with starting, pausing and seeking to the exactly right frame... what do you think?
another option I thought about was using OPENGL ( while I never worked with it before ), to play animation frame by frame. What do you think, would opengl be able to handle it?
Thanks!
edit, i managed to peek into talkingtom, and found that it contains about 20megs of well compressed JPEGs, like this.

You could handle it in a couple of different ways.
It sounds like decoding is your bottleneck. You could try making all the 3 steps including the decoding before playing the animation, so you will just have to draw the already-converted bitmaps.
OpenGL is definitely up to the task in the sense that it will probably never be your bottleneck. But as said above, the drawing does not seem to be the problem.
Animating on the device. In case you are animating geometric objects or pixmaps and the animation has a common background you could reuse, separate the animation into "actors" and move them around - this will require much less data.
EDIT : Complex animations on mobile devices are rarely full-screen movies or series of images - the amount of (redundant) data would be overwhelming (as you have noticed already). They are animated 2D and 3D models. For 3D it is advisable to use OpenGL, for 2D, common canvas drawing may be enough. To make it even more efficient, you could split the model into separate parts and animate them separately (would look similar to SouthPark animations). You can combine this with using spritesheets (like separate small movie strips) to animate separate parts. This would give you much more flexibility while still using less data than a compressed movie.

I really think you need to turn it into a movie file - that will give you some appropriate compression and android can do all the work with the media player. I believe getting to the right frame is fairly easy but you may have to use lower compression on the video stream to make this work.

Maybe using universal tween engine can fix your performance problem.

Direction to take with Android Graphics

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.