Display Lists and 2D Animation

[cloke]

I'm looking into display lists and drawing 2D sprites. I'm still reading up on the topic, but I was hoping to sort a few things out. For a 2D based game is using display lists even a good idea? Would I have a list for each frame? I was thinking of having a vector of display lists and just going through the vector on each frame.

Anyway, does anybody have any good suggested reading or just some general suggestions?

[reubert]

for smallish sprites having a large texture that contains all of your animation frames and modifying the texture coordinates each render is a good way to do it. So for a 4 frame animation you might have the 4 frames in a row on a single texture, then give it coords of 0, 0.25 then 0.25, 0.5 then 0.5, 0.75 and so on.

[SOUR-Monkey]

Display lists are less efficient than straight glVertex() calls below a certain number of vertices. I don't know how you plan on handling your sprites, but if you are just pasting a texture over a quad then display lists aren't going to help you at all. I would just keep track of each sprites size and texture ID, and each frame bind the texture then draw an appropriately sized quad.

The way reubert mentioned for doing animation sounds like a good one.

[cloke]

Thanks for the info. I didn't even think of clipping the texture. For some reason going to GL I just threw out my old knowledge of animation :).

[ThemsAllTook]

for smallish sprites having a large texture that contains all of your animation frames and modifying the texture coordinates each render is a good way to do it. So for a 4 frame animation you might have the 4 frames in a row on a single texture, then give it coords of 0, 0.25 then 0.25, 0.5 then 0.5, 0.75 and so on.

If you do this, you'd probably want to leave at least a 1-pixel padding space between animation frames. Otherwise, you're likely to sometimes see rows or columns of pixels from other animation frames at the edges.

Alex Diener

[aaronsullivan]

Remember, however, that using sections of a texture and display lists mean you won't have to recalculate texture coordinates every frame. I'm pretty sure display lists helped my performance doing exactly this when I was working on a 2D openGL engine for my canceled uDevGame 2003 entry.

I'll be checking into it pretty soon for this year's entry.

[NCarter]

In Yoink I simply divided all of my tile images into independent textures as I loaded them, then drew each tile/sprite as a separate GL_QUAD in immediate mode. Even though this is the most brute-force method imaginable, it still runs more than fast enough for my needs, even on comparatively slow hardware!

The moral of this story is: you don't necessarily have to write optimal OpenGL code to get good performance.