So far I''ve used a nice wrapper library in my OpenGL coding ( http://zengine.sourceforge.net ) But I''ve been reading the OpenGL Redbook ( http://www.dcc.unicamp.br/~lmarcos/courses/mc603/redbook/ ) to try and get a full understanding of the API, and specifically, how I can leverage some of its more advanced features in my sidescroller ( http://www.cs.rit.edu/~ktw6675 ). This is entailing some homebrewed additions to ZEngine that I''m thinking about. In addition to working on soft 2D shadows ( http://www.gamedev.net/reference/articles/article2032.asp ) I''m also looking at how to improve performance with display lists, which seem to be very applicable to an engine like mine where you are drawing many static images. My question, specifically, is this: I know that many of the non-trivial performance penalties in OpenGL involve state changes, and other "switch" operations. Say I want to create a display list to draw a tile layer to the screen. Would it be better to draw, in the display list: a) all the tiles of the same texture first, in sequence, so that OpenGL doesn''t have to "bind" a new texture many times over, or b) just draw the tiles in order, from top-left, to bottom-right, like I''m doing now To clarify, in (a) I would draw all tiles with a value "0" first, regardless of where they are on screen. Then I''d move on to draw all tiles with value "1." This might require a tricky data structure if I want to draw only those tiles being looked at by the camera, but if OpenGL is such that the performance gain is substantial, it''d be worth it. But even if I stick with (b) I think that going with display lists should still give me an improvement in performance. I thought I''d at least hear some opinions on the subject before I go and prototype and compare performance between the two.

Well,

25 tiles across X 20 tiles down X ~6 layers on screen at once

= ~3000 tiles.

Worst case scenario would be a checkerboard pattern. Does 3000 "state changes" in this context matter that much?