My field-of-view is 45 degrees. Now when I resize my window, I want everything to scale appropriately, but it doesn’t.
Here is my perspective code (the usual):
glMatrixMode ( GL_PROJECTION );
gluPerspective ( 45.0f, ( GLfloat ) m_Width / ( GLfloat ) m_Height, m_Front, m_Back );
This is standard. I want everything to scale properly so when I (say) reduce the x width of the window, the x width of the entire model is scaled also. How to do this?
use glViewport instead. gluPerspective like glFrustum is independ from window sizes and screen resolutions. the scaling is done when presenting data in a viewport.
in other words, dont use gluPerspective when windows are resized. do this only, when changing the fov for different lense effects or something similar.
use glViewport instead.
to prevent some areas of your window from rendering you can enable the scissor test. this doesnt scale any geometry, but skips pixels outside the scissor.
and never be ashamed to ask something. you cant get enough knowledge
[This message has been edited by jabe (edited 11-01-2001).]
thanks jabe. I was wondering about that.
Something else I’ve noticed when I resize my window is that my framerate doesn’t increase\decrease. It stays fairly steady.
I guess that might be due to the fact I’m running my render code on a thread. Still, I’d expect it to speed up to something silly like 800fps when I reduce the window size down to 32x32 pixels. I suppose I’m rendering to a larger window and swapbuffers is scaling to the window?
I am no expert OpenGL, otherwise why would I be here? But having used other systems, can I suggest that you might have done something wrong in your pipeline.
The final stage of the pipeline (rendering) is the slowest, but not automatically the slowest. Try looking at you early reject code, are you using view-frustrum-culling, if not try it, or at least use back face culling, and see what effect it has. Are you using texture management (most hardware suffers badly if you do not limit textures, or sort by state). e.g. reducing the view size, will only help if it is the rasterising stage which is slowing you down (unlikely on modern hardware)