I've found a bunch of tutorials on how to make this work on Open GL 1 & 1.1 but I can't find it for 2.0.

I would work it out by loading the texture and use a matrix on the vertex shader to move through the sprite sheet.

I'm looking for the most efficient way to do it. I've read that when you do the thing I'm proposing you are constantly changing the VBO's and that that is not good.

Edit: Been doing some research myself. Came upon this two Updating Texture and referring to the one before PBO's. I can't use PBO's since i'm using ES version of OpenGL so I suppose the best way is to make FBO's but, what I still don't get, is if I should create a Sprite atlas/batch and make a FBO/loadtexture for each frame of if I should load every frame into the buffer and change just de texture directions.

  • \$\begingroup\$ Just to be clear, how are you doing your sprites now? Are you drawing a textured quad and changing the texture coordinates on each frame? \$\endgroup\$
    – Mokosha
    Commented Nov 1, 2013 at 22:03
  • \$\begingroup\$ That's correct. \$\endgroup\$ Commented Nov 2, 2013 at 10:39

1 Answer 1


One way to do sprite animation with OpenGL ES shaders is achieved by using uniforms and changing texture coordinates in the vertex shader. To elaborate, suppose you have a 1024x128 sprite sheet with 8 frames.

  1. Set up a quad whose vertices (clockwise) are (-1, -1), (-1, 1), (1, 1), (1, -1).
  2. Assign texture coordinates to the vertices with (0, 0), (0, 1), (1, 1), (1, 0), respectively.
  3. In the vertex shader, define a uniform iSpriteFrame which is set to the frame of the sprite animation you wish to draw (between zero and seven for this example).
  4. When you draw the sprite at frame n, for each vertex with texture coordinate tc and position p, calculate the final texture coordinate ftc with

    ftc.x = (iSpriteFrame + tc.x) * 0.125
    ftc.y = tc.y
  • \$\begingroup\$ Thanks for the answer, I understand the point. So, you think using vertex shader to move around the sprite sheet is the most efficient way to do do it? FBO's is suppose to make a "jump" into OpenGL's pipeline and go directly to the Fragment shaders with the pixels info. wouldn't that be more efficient? Any clues on that? \$\endgroup\$ Commented Nov 3, 2013 at 15:14
  • \$\begingroup\$ The question you're referencing is referring to changing texture data from a running application. That's significantly slower than what's required to do sprite animation. When you do sprite animation, you don't need to change the texture data at all, only which data you're displaying. You shouldn't be worrying about performance anyway. Get something that works and then see if it doesn't meet your needs. With that in mind, I can't think of what techniques would be faster than what I'm suggesting. \$\endgroup\$
    – Mokosha
    Commented Nov 3, 2013 at 20:04
  • \$\begingroup\$ Ok! I'm starting to get the hole idea. So messing up with FBO's switches your texture data on run time… I'll stick to vertex work then. Won't I get problems with too much texture data loaded? \$\endgroup\$ Commented Nov 3, 2013 at 21:55
  • \$\begingroup\$ Yes, this is the classic "compute vs memory" tradeoff that people make all the time. You can stay within your limits most likely by using compressed textures and keeping your sprite sheets manageable. \$\endgroup\$
    – Mokosha
    Commented Nov 4, 2013 at 1:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .