Fill rate problem
Author
Im haveing some fill rate related problems when drawing the background texture for a project. What can i do to fix it.
Example :
Without BG game runs at about 1700 fps
Wit BG its about 250 fps
The background is 4 large polys with a 256x256 mipmapped texture attached to each. Im useing 2D Ortho Perspective. blending makes no difference
hmmm, that may be normal. i have done the same thing except i used one quad and scaled it 320,240,0 which makes it 640,480. and my mipmaped texture it 640,480 yet i get 600+ fps but drops to 450+ with object moving around.
just try one poly and one texture and see how things go then.
just try one poly and one texture and see how things go then.
Mind me, you don''t need mimapping for background textures since they always have the same dimensions on the screen.
How are organized the polygons ? Something like a skybox ?
How are organized the polygons ? Something like a skybox ?
quote:
Without BG game runs at about 1700 fps
Wit BG its about 250 fps
I''d say that''s pretty normal, with a screen filling poly, especially at higher resolutions. What 3D card do you have ?
- AH
Eber Kain: Try turning BG on/off on real scene (something like +25000 triangles) and some math/AI running. And then you''ll see the real difference in fps. There is virtualy none.
DarkWing: you''re definately right, but IMHO this topic does discuss of how fast we can implement a BG.
Whatever the application is, if the BG draw faster without losing quality, then it''s better
oh and I forgot to say something that seemed obvious to me : without mipmapping, the result will be faster. that''s why I suggest to remove them. And if the texture is choosen correctly, there will be NO difference ! Please remember that the texture needs to be resized to fit "correctly" without mipmapping.
Whatever the application is, if the BG draw faster without losing quality, then it''s better
oh and I forgot to say something that seemed obvious to me : without mipmapping, the result will be faster. that''s why I suggest to remove them. And if the texture is choosen correctly, there will be NO difference ! Please remember that the texture needs to be resized to fit "correctly" without mipmapping.
how should the texture be set up? for me i can only use mipmaped images for my BG''s every time i try to set the texture to something else i get a blank quad??
I guess you use the gluBuild2DMipmaps function.
In this case, you will not have any problem because the glu checks the image dimensions for you and resizes it if necessary.
I think you have a blank quad because your image is not good :
- Either the image size exceeds the graphics card texture capability (kind of "out of memory"),
- Or the image size is not 2^n.
Defining a texture without mipmap
Instead of using :
gluBuild2DMipmaps(GL_TEXTURE_2D, internal_format, width, height, format, GL_UNSIGNED_BYTE, pixels);
Use :
glTexImage2D(GL_TEXTURE_2D, 0, internal_format, width, height, 0, format, GL_UNSIGNED_BYTE, pixels);
(where "internal_format" and "format" are probably GL_RGB or GL_RGBA, and where "pixels" is an array of GLubyte pointing to the pixel data).
In this case, you will not have any problem because the glu checks the image dimensions for you and resizes it if necessary.
I think you have a blank quad because your image is not good :
- Either the image size exceeds the graphics card texture capability (kind of "out of memory"),
- Or the image size is not 2^n.
Defining a texture without mipmap
Instead of using :
gluBuild2DMipmaps(GL_TEXTURE_2D, internal_format, width, height, format, GL_UNSIGNED_BYTE, pixels);
Use :
glTexImage2D(GL_TEXTURE_2D, 0, internal_format, width, height, 0, format, GL_UNSIGNED_BYTE, pixels);
(where "internal_format" and "format" are probably GL_RGB or GL_RGBA, and where "pixels" is an array of GLubyte pointing to the pixel data).
According to the OGL specs, OGL assumes a texture doesn''t exist if the filtering mode is set to GL_x_MIPMAP_x and it doesn''t have mipmaps, so set it to GL_LINEAR. If your texture actually takes up the same amount of pixels on-screen as are in the bitmap, you could even use GL_NEAREST without any loss in quality whatsoever. You can do that anyway, of course. It might result in a slight speedup as well.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
