Sprite transparency in OpenGL?
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?
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)].
[Normally, I have a new mesh/quad for every frame, i.e., vertex pointer, but I keep my textures bound once (usually)].
respect,
pk
iFrog is coming.
(Dec 20, 2011 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.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
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.
respect,
pk
iFrog is coming.
You could certainly do that, but why bother?
TexSubImage2D is CPU->GPU.
CopyTexSubImage2D is GPU->GPU.
CopyTexSubImage2D is GPU->GPU.
I don't think it would save any app size or allow any different look...
(Feb 16, 2012 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.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Possibly Related Threads...
Thread: | Author | Replies: | Views: | Last Post | |
Sprite game with OpenGL/GLKit | InvisibleMoustache | 6 | 13,686 |
Oct 10, 2012 09:20 AM Last Post: OneSadCookie |
|
OpenGL ES 2.0, 2D Alpha Transparency Artifacts | Macmenace | 3 | 10,995 |
Mar 28, 2010 11:18 PM Last Post: AnotherJake |
|
libpng transparency problem | wyrmmage | 3 | 7,532 |
Mar 1, 2007 05:53 PM Last Post: OneSadCookie |
|
OpenGL Sprite Structure | Stalin55 | 2 | 5,952 |
Aug 18, 2006 03:40 PM Last Post: AnotherJake |
|
SDL + OpenGL Sprite Loading Problem | Greywhind | 3 | 6,885 |
Jun 29, 2006 04:44 PM Last Post: OneSadCookie |