To be clear: you have no need to call glTexSubImage2D for a sprite game. TexSubImage2D *is* slow, because it involves transferring data from the CPU to the GPU.

Create your textures once, bind and draw as necessary each frame.

And, GeForce 2MX?! Why are you using a ten year old graphics card?

yep. doesn't sound very feasible. still, as a thought experiment it sounds intriguing. What about VBOs? Isn't that kind of like a "hardware sprite"?

[Normally, I have a new mesh/quad for every frame, i.e., vertex pointer, but I keep my textures bound once (usually)].

(2011.12.20 11:21 AM)OneSadCookie Wrote:  To be clear: you have no need to call glTexSubImage2D for a sprite game. TexSubImage2D *is* slow, because it involves transferring data from the CPU to the GPU.

Now wait a minute. I think you just confused glTexSubImage2D with glReadPixels? The glTexSubImage2D call is fast and optimized and should not transfer data to the CPU. Rather, it is the backup call if you can't use FBOs (if you find FBOs to hard to use or you use an ancient system that doesn't support them.) But glReadPixels (combined with a glTexImage) is exactly what you describe, drawing to a texture the slow way. over the CPU.

But for the main question I agree, you are not likely to save time by doing more work, in this case render all sprites to a texture and then render that. And transparency for 2D sprites is easy. Get those done and start thinking about the harder parts, like a good collision detection/collision handling system.

No, he said transferring from the CPU to the GPU. Refreshing a texture every frame is most certainly slower than reusing the same one over.

I just started thinking about "mesh sprites" that are 2D meshes with minimal or no transparency. Designing them would be different than making animated quads (where you usually have quite a lot of transparency). The bound bitmap would be more like a palette/texture, like with 3D objects.

You could certainly do that, but why bother?

(2012.01.07 07:26 AM)Skorche Wrote:  No, he said transferring from the CPU to the GPU. Refreshing a texture every frame is most certainly slower than reusing the same one over.

Same thing. If you use glTexSubImage2D, you don't transfer in either direction, it is all on the GPU.

TexSubImage2D is CPU->GPU.
CopyTexSubImage2D is GPU->GPU.

(2012.01.07 11:03 AM)OneSadCookie Wrote:  You could certainly do that, but why bother?

I'm thinking about cutting down the app size by avoiding a lot of texture sprites and somewhat a different look.

I don't think it would save any app size or allow any different look...

(2012.02.16 03:35 PM)OneSadCookie Wrote:  I don't think it would save any app size or allow any different look...

We can settle the score over a game of chess...

(2012.02.16 03:35 PM)OneSadCookie Wrote:  I don't think it would save any app size or allow any different look...

Sure it would. With sprite animation you have to store a lot of discrete frames. With meshes you could do a lot of effects that are traditionally done with 3D models. Think like Another World or Flashback for example.