I don''t want to use textures, due to the power of 2 limitation, so I try glDrawPixels and it''s too slow. I have a geforce FX card, so my machine ain''t outta date or anything.
I basically want fast 2D performance without using textures, could someone please point me in the right direction?
Fast 2D with OGL, without textures, how?
Author
I keep starting to learn DirectX because I find it''s 2D fast, but stop because I prefer OpenGL, then can''t get fast enough 2D performance, rinse and repeat!
I don''t want to use textures, due to the power of 2 limitation, so I try glDrawPixels and it''s too slow. I have a geforce FX card, so my machine ain''t outta date or anything.
I basically want fast 2D performance without using textures, could someone please point me in the right direction?
I don''t want to use textures, due to the power of 2 limitation, so I try glDrawPixels and it''s too slow. I have a geforce FX card, so my machine ain''t outta date or anything.
I basically want fast 2D performance without using textures, could someone please point me in the right direction?
Use textures.
Seriously, the power-of-two is not a limitation, you just have to be slightly clever about how you deal with your drawing.
What you do is fill up the texture with as much as you want, then adjust your texture coordinates to map only those parts of the texture you want to draw (or you could use the nvidia rectangular texture extension, but I''d recommend doing the extra work for handling pow-2 textures). You get a hell of a lot of benefits from using textures and the 3D hardware (blending, depthtesting, filtering etc.) so the little extra effort is certainly worth it.
There are some slight issues which you might come across, but the pros far outweigh the cons. If you *really, really* don''t want to use textures then there are some nvidia extensions (and I''m sure Ati mirrored them) for doing faster pixel transfer, but you won''t ever achieve speeds the hardware is capable of if you don''t use it how it''s meant to be used.
Seriously, the power-of-two is not a limitation, you just have to be slightly clever about how you deal with your drawing.
What you do is fill up the texture with as much as you want, then adjust your texture coordinates to map only those parts of the texture you want to draw (or you could use the nvidia rectangular texture extension, but I''d recommend doing the extra work for handling pow-2 textures). You get a hell of a lot of benefits from using textures and the 3D hardware (blending, depthtesting, filtering etc.) so the little extra effort is certainly worth it.
There are some slight issues which you might come across, but the pros far outweigh the cons. If you *really, really* don''t want to use textures then there are some nvidia extensions (and I''m sure Ati mirrored them) for doing faster pixel transfer, but you won''t ever achieve speeds the hardware is capable of if you don''t use it how it''s meant to be used.
use gluScaleImage. It will scale the texture to what size you want.
Question: Don''t understand why gluScaleImage didn''t wrok well until i set GL_UNPACK_ALIGNMENT and GL_PACK_ALIGNMENT to 1. Can someoen help me?
Question: Don''t understand why gluScaleImage didn''t wrok well until i set GL_UNPACK_ALIGNMENT and GL_PACK_ALIGNMENT to 1. Can someoen help me?
TerraX : if you don''t need to repeat your texture, then you can use non-power-of-two textures with OpenGL. You simply have to allocate texture memory for the closest highest power-of-two size and fill in the non-power-of-two sub-texture thanks to the glTexSubImage2D function. You then have to be careful about texture coordinate but it''s a minor problem, especially since the texture matrix can help you.
PM: if you upload RGB textures, then you probably need to set GL_PACK/UNPACK_ALIGNMENT to 1 otherwise the GL assumes that lines are aligned by packs of 4 bytes (4 is the default alignment) but your RGB texture in certainly aligned to 3 bytes. In fact, it''s not a problem with GLU, rather it''s a problem with the GL.
PM: if you upload RGB textures, then you probably need to set GL_PACK/UNPACK_ALIGNMENT to 1 otherwise the GL assumes that lines are aligned by packs of 4 bytes (4 is the default alignment) but your RGB texture in certainly aligned to 3 bytes. In fact, it''s not a problem with GLU, rather it''s a problem with the GL.
I don''t want to sound dumb, or off topic, but try using SDL (Simple Direct media Layer). It''s a lot like OpenGL and even renders OpenGL; it opens up a window, and then you can use OpenGL in that window. It''s kinda like GLUT in that respect. You should check it out, because it is like DirectDraw, but fast, open source, and easy, like OpenGL. It is cross-platform, is able to handle Graphics, Sound, Input, CD-ROM, and some other stuff, too. And did I mention it was easy? (oh, yeah, i did.) If you want to do 2D without textures, look into SDL, you won''t be disappointed. Note- EASY! No Windows API calls! Like GLUT for 2D!
"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
Author
Thanks for the replies everyone. Looks like using textures is gonna be much faster. It''s a little bit of a hassle, but I managed to get a 512x512 texture with some animation frames in it, got the texCoords calculated sweet, I''ll use textures from now on, plus the super fast alpha blending/rotation etc rocks, thanks
Perhaps I should type this question in another fresh post, but I don''t want to mess up the forum so I''ll post here as it''s kinda related..
Pixel perfect collision? What''s the best way? So far I''ve thought of storing a mask array for each "sprite", offsetting and testing each of these against each other, but I think this''ll be slow. So perhaps somehow use the stencil buffer or depth buffer or something? I dunno, that''s why I''m asking
Perhaps I should type this question in another fresh post, but I don''t want to mess up the forum so I''ll post here as it''s kinda related..
Pixel perfect collision? What''s the best way? So far I''ve thought of storing a mask array for each "sprite", offsetting and testing each of these against each other, but I think this''ll be slow. So perhaps somehow use the stencil buffer or depth buffer or something? I dunno, that''s why I''m asking
You could do so using occlusion queries. The graphics card needs to support NV_occlusion_query or ARB_occlusion_query (beware, HP_occlusion_test is not enough for this case). There is an example in the NeHe's lens-flare tutorial.
[edit] well in fact I think that HP_occlusion_test is enough, if you invert the depth test temporarily.
[edited by - vincoof on October 8, 2003 4:29:04 AM]
[edit] well in fact I think that HP_occlusion_test is enough, if you invert the depth test temporarily.
[edited by - vincoof on October 8, 2003 4:29:04 AM]
quote:Original post by TerraX
So far I''ve thought of storing a mask array for each "sprite", offsetting and testing each of these against each other, but I think this''ll be slow. So perhaps somehow use the stencil buffer or depth buffer or something? I dunno, that''s why I''m asking
Don''t try using a *graphics& API for collision detection, thats just a stupid idea. Even if you could get it to work, reading results back over the AGP is not going to be fast.
Simple idea is to have a 1-bit mask as you say, then you can simply AND the two intersecting sprites together (with appropriate offsets). If you get any ones in your result they''ve overlapped. And remember you can check the bounding boxes first (very fast) so you''ll only be doing the pixel checking infrequently.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement