Glen RItchie wrote:
Rainer Deyke <rainerd eldwood.com> writes:
Glen RItchie wrote:
Well then, I am at a complete loss as to why the exact
code works perfectly under win32 when i pass the client
area to glViewport but fails under SDL and GLUT when i
pass the window size/width…
When you say win32, do you mean the win32 api, or running under the
windows environment? (Aka, have you tested SDL/GLUT on windows, or just
on a *nix box?) Last time I had problems with stuff not rendering it was
due to misinstalled OpenGL, which was silently failing instead of, say,
segfaulting as one might expect.
I also remember when I was first learning how to use SDL for OpenGL, and
had an issue which I found out was caused by not calling glViewport. On
my resize, I put it so it called:
SDL_SetVideoMode( new_width , new_height , 32 , SDL_OPENGL );
glViewport( 0 , 0 , new_width , new_height );
which worked perfectly.
By this do you mean that you are combining GLUT and SDL in a single program?
That seems like an odd combination, since there is a lot of overlap of
functionality between GLUT and SDL. Combining both libraries in one program
may result in unexpected side effects.
Err. no. this isn’t what i’m doing. I just wanted to say that you can’t get the
client area in GLUT either.
From this bit of documentation on glutReshapeWindow (it’s a callback
registration):
http://www.opengl.org/resources/libraries/glut/spec3/node48.html#SECTION00083000000000000000
The default behavior on a resize is to call glViewport(0,0,width,height)
- so you should be able to get the needed numbers from this.
GLUT aside, there’s not much I can do. The parameters passed to
SDL_SetVideoMode are supposed to be the dimensions of the client area. It
works for me. If it doesn’t work for you, either there is a bug in your
code, or you have discovered a bug in SDL.
I’m pretty sure it’s not a bug in my program.
I’ll explain what i’m trying to do and why i need the client area.
I’ve implemented a GUI interface into my prog and the main thing is dragging
windows around. Eg. click on the title bar and drag them. Now in fullscreen this
works perfectly when the mouse moves 1 pixel the window moves one unit in opengl
co-ords ( i set it to use ortho2d ). But i’ve noticed a certain lagging in
windowed mode, eg the mouse moves one pixel but the window moves less. This is
because i create a window at say 500, 500 and pass this to glortho. But the
actual client area is less than this and so opengl helpfully changes the ratio
because you can’t fit the 500,500 into the smaller client area. This is why i’ve
noticed the lagging on the window behind the mouse in windowed modes but not
fullscreen. in fullscreen there is no title bar.
Since this sounds like speculation based on the program behavior rather
than actual checking, try creating a window the size of your screen. If
you are setting the window width/height instead of the client
width/height, then when the window when perfectly centered on the screen
(see glutPositionWindow) you should be able to see every edge of the
window (none hidden). You may have to put your start bar (on windows) to
autohide mode to confirm the height, which would be most obvious (due to
the titlebar’s size).> I originally found this bug when using Direct3D on Windows and fixed it by using
the client area as the ortho params. When i ported the same code to opengl i had
the original problem. Thus… i wish to find the client area.
I guess i’ll just have to use X11 commands to get the current active window and
get the client area that way.
Glen Ritchie