I’ve heard that glBindTexture is really slow and must be avoided as much as possible, but for a 2D tiled OpenGL game coded in C++ (about 400 tiles on screen per frame max.), is a texture atlas really needed? Also is the overhead of re-calculating texture coordinates for each tile really less than the overhead of changing textures only when needed (I draw the tiles row by row and only call glBindTexture when the next tile is different from the current one)?
EDIT:The tiles are 32×32 pixels so all will fit into one atlas
Binding another texture may be cheaper than one thinks depending on your usage pattern if you are only a little lucky. Modern GPUs have more than one texture set that the driver can switch between relatively easily (see this somewhat lengthier explanation). Especially if you change between a moderately variable set of tiles, chances are good that it will not be a total stall.
However the thing is, you don’t know. It might just be different, too. As long as you don’t know, you should assume the worst case rather than the best.
Plus, the dreaded pipeline stall is not the only thing that is possibly expensive in a texture bind. The GL has to dereference at least two pointers (with a high likelihood of cache miss) and do some non-trivial consistency checks on the object and the overall renderstate after binding the object.
Those cache effects and consistency checks are a problem, they are the reason why nVidia is still working on “bindless graphics”. They refer to it as “the new bottleneck”.
All that probably does not matter for 500 state changes on a desktop machine, but as Goz already pointed out, it will matter on a handheld. If nothing else (i.e. even if it does not impact the frame rate), it will cause the battery to drain faster.
That’s a pity because it is totally unnecessary, a texture atlas is easy to implement and has none of that overhead, and all involved calculations are trivial (since you don’t use mipmaps).