The idea is to draw multiple sprites on a lone textured quad, with transparency that preserves the existing texture wherever each sprite has pixels with 0 alpha. Unless I've been using them wrong, GL_BLEND and glBlendFunc kind of don't do that.

Why do you want to do that? Draw each sprite on its own quad (though it's a good idea to put many sprite images into a single texture, aka a "sprite sheet", in order to reduce the number of times you have to call glDrawElements).

100% impossible. Unless we're talking about some weird new definition of time here or I just fell into the Twilight Zone, drawing 30 textured quads can't possibly be quicker than drawing 1 textured quad. It's like saying one iteration through a while() loop is slower than fifty. What the hell?

Why do you assume that the number of quads is the bottleneck? It almost never will be.

Usually, the bottleneck will be on the GPU, in the number and complexity of pixels filled. That means that many smaller quads will be faster so long as they cover fewer pixels (including the transparent ones!) than the one large quad, and especially so if shading them is vastly simpler, which it should be.

Sometimes, the bottleneck will be the CPU overhead in making many draw calls, hence my advice to use a sprite sheet.

Most games nowadays draw scenes with hundreds of thousands of triangles. Even on mobile devices you can draw tens of thousands of textured triangles. As OneSadCookie said, vertexes are cheaper than most games care too much about, draw calls and fill rate are not.

Drawing sprites with transparency on a single textured quad: JSH*@(GDGDSODGSJDSBGJDSbA}fsa;

Is it even possible to do in OpenGL? Because using the CPU to do alpha testing = slower than dirt.

I think there's a way to use the fragment shader to process data if you can get it to handle the alpha values for you, i.e., input textures into the shader program and read back the data – just a hunch. OpenCL anyone?

Updating textures tends to be very expensive. Sending a few thousand triangles is not.

Again, the expensive part of rendering 2D games is rarely related to the number of vertexes. It's generally state changes (by giving each sprite it's own texture and constantly switching between them), draw calls (by making a draw call for each sprite), or fill rate (the number of pixels that have to be drawn).

So the best way to speed up 2D rendering is to make a sprite sheet by packing lots of sprites onto a single texture. Then you can send a bunch of quads that share the same texture all in one draw call.

(Dec 20, 2011 04:16 AM)Guest! Wrote: So in otherwords, an operation like glTexSubImage2D is so expensive(comparatively anyway) that no matter how it's used, putting each sprite on its own quad is faster? Just inherently?

In practice, yeah, pretty much. In all the games I've made (both 2d and 3d) I've always been limited by fill rate or CPU.