Page 1 of 3
OpenGL and Vsync
Posted: Sun Oct 10, 2010 3:09 pm
by N64vSNES
So I'm working on a project that uses openGL ( and SDL ) and I've had trouble with smooth scrolling maps and texture tearing and this only happens when its windowed and not when fullscreen as long as I enable waiting for Vsync, and this is aparantly because you can't wait for Vsync when you haven't got controle over the resolution.
Of course this is what I've read if any of this is incorrect then please feel free to correct me.
So I'm curiouse to how other people's has worked around this?
Re: OpenGL and Vsync
Posted: Thu Oct 14, 2010 12:15 pm
by N64vSNES
Nobody?
Re: OpenGL and Vsync
Posted: Thu Oct 14, 2010 12:21 pm
by dandymcgee
Screenshot might help.
Re: OpenGL and Vsync
Posted: Thu Oct 14, 2010 12:24 pm
by EccentricDuck
Is there a call you can make for changing the standard resolution (without going fullscreen) or can Vsync be synchronized to a particular resolution? Maybe put up some code showing where you call/set it and where you switch to fullscreen/change resolution.
Re: OpenGL and Vsync
Posted: Thu Oct 14, 2010 1:00 pm
by N64vSNES
Ok I set resolution once and don't switch at all.
Code: Select all
SDL_Init( SDL_INIT_VIDEO | SDL_INIT_AUDIO );
SDL_WM_SetCaption("The Eternal Quest Engine",NULL);
Mix_OpenAudio(22050,MIX_DEFAULT_FORMAT,2,1024);
SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER,1 );
/*SDL_GL_SwapControle used to fix this issue in fullscreen, used to...*/
SDL_GL_SetAttribute( SDL_GL_SWAP_CONTROL,1 );
if ( FLSCR == false )
buffer = SDL_SetVideoMode( 640,480,32, SDL_OPENGL );
else {
buffer = SDL_SetVideoMode( 640,480,32, SDL_OPENGL | SDL_FULLSCREEN );
}
/******************************/
glClearColor(0,0,0.5f,0);
glMatrixMode( GL_PROJECTION );
glLoadIdentity();
glOrtho(0,640,480,0,-1,1); // Orthographic projection
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();
glEnable ( GL_TEXTURE_2D );
glEnable ( GL_COLOR_MATERIAL );
glEnable ( GL_BLEND );
glBlendFunc( GL_ONE,GL_ONE_MINUS_SRC_ALPHA );
glEnable ( GL_POLYGON_SMOOTH );
glEnable ( GL_POINT_SMOOTH );
MainLuaState::GetInstance()->Initialize();
Ticks = SDL_GetTicks();
FrameTime = SDL_GetTicks();
CurrentFPS = 0;
There is my intialization code
Code: Select all
DebugSystem::GetSystem()->UpdateDbg();
TextBoxSystem::GetSystem()->UpdateSys();
if( SDL_GetTicks() - (Uint32)Ticks < 1000 / (Uint32)MaxFPS )
{
SDL_Delay( ( 1000 / MaxFPS ) - ( SDL_GetTicks() - Ticks ) );
}
if ( SDL_GetTicks() - FrameTime >= 1000 ) {
CurrentFPS = CurrentFrame;
CurrentFrame = 0;
FrameTime = SDL_GetTicks();
}
SDL_GL_SwapBuffers(); // update the buffer
CurrentFrame++;
DebugSystem::GetSystem()->ResetPolyCount();
There is my flip code
The is also a loop() bolean but it just calls SDL_PollEvent() and glClear()
Is a screenshot really needed? because its just texture tearing a quick google search should bring one up.
But this is really started to get a problem because SDL_GL_SWAP_CONTROLE normaly fix's this problem in fullscreen.
UGH!
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 8:02 am
by N64vSNES
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 8:56 am
by qpHalcy0n
Well, unfortunately as I've outlined in the thread below yours which was also suffering SDL problems, when dealing with SDL and OpenGL concurrently all bets are off. It's simply too difficult to tell what in the hell this API is really doing. A short search and a bit of past experience has revealed that not only has VSync been deprecated about 4 separate times, the flags to control VSync number over 5. This primarily depends on what version of SDL you're using. You will note that the particular method you're using has been deprecated since 1.3, so it may not work. You'll need to search through the documentation more extensively to determine what (if anything) has replaced it.
Other issues to note are that this is primarily an OS-specific and window specific setting. OpenGL has no concept of "VSync". You're just instructing it to wait on cue from the window system. So the behavior even in regular OpenGL can be hit or miss. Some obvious things: check that your driver settings have not "Forced VSync off". Any "forced" setting will override any app setting. If you're running vista or windows 7, disable aero when testing OpenGL apps. Windows Aero in Win7 is powered by a DirectX accelerated layer and OpenGL exists as a service to it. This can sometimes cause some wonky problems when dealing with windows specific API calls, such as VSync.
Lastly, your code exhibits especially poor error checking. Most API's functions that alter video state will return value on success or failure. At this point you can't even be sure the mode was set with success. Add some error checking code in there to be sure.
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 9:39 am
by N64vSNES
Ok I'm getting a good lesson on Vsync but what I don't understand is the amount of projects out there that uses SDL and openGL and nobody has had this issue? Surely its not just me
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 9:50 am
by qpHalcy0n
It's not just you
My advice is, and alway has been, just steer a mile clear of SDL and SFML.
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 12:05 pm
by dandymcgee
qpHalcy0n wrote:It's not just you
My advice is, and alway has been, just steer a mile clear of SDL and SFML.
Out of curiosity what do you suggest instead?
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 1:41 pm
by N64vSNES
I've fixed this within fullscreen now, I think.
But surely the is a way around this? I've read that the reason SDL itself dosen't have this issue because SDL_Flip(); will wait for Vsync anyway.
:/ I'm going to do some more googling but I'm beginning to think the isn't a way around this
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 2:16 pm
by qpHalcy0n
My suggestion has always been to communicate with the OS directly.
Definitely go searching, there may or may not be a way around this. I can't be sure. There does not exist any limitation within the OpenGL driver or within windows that would NOT allow this to happen, so it looks like yet another shortsighted silly SDL limitation. Have a look though, perhaps they've fixed this.
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 3:00 pm
by EccentricDuck
N64vSNES wrote:I've fixed this within fullscreen now, I think.
But surely the is a way around this? I've read that the reason SDL itself dosen't have this issue because SDL_Flip(); will wait for Vsync anyway.
:/ I'm going to do some more googling but I'm beginning to think the isn't a way around this
Wait, you said initially that the problem only happened in windowed mode and not fullscreen:
N64vSNES wrote:...I've had trouble with smooth scrolling maps and texture tearing and this only happens when its windowed and not when fullscreen as long as I enable waiting for Vsync, and this is aparantly because you can't wait for Vsync when you haven't got controle over the resolution.
Re: OpenGL and Vsync
Posted: Fri Oct 15, 2010 5:07 pm
by N64vSNES
EccentricDuck wrote:N64vSNES wrote:I've fixed this within fullscreen now, I think.
But surely the is a way around this? I've read that the reason SDL itself dosen't have this issue because SDL_Flip(); will wait for Vsync anyway.
:/ I'm going to do some more googling but I'm beginning to think the isn't a way around this
Wait, you said initially that the problem only happened in windowed mode and not fullscreen:
N64vSNES wrote:...I've had trouble with smooth scrolling maps and texture tearing and this only happens when its windowed and not when fullscreen as long as I enable waiting for Vsync, and this is aparantly because you can't wait for Vsync when you haven't got controle over the resolution.
At first yes but
There is my flip code
The is also a loop() bolean but it just calls SDL_PollEvent() and glClear()
Is a screenshot really needed? because its just texture tearing a quick google search should bring one up.
But this is really started to get a problem because SDL_GL_SWAP_CONTROLE normaly fix's this problem in fullscreen.
UGH!
I figured that it was to do with the fact some 256 bit programs in windows do this when a monitors settings are reconfigured.
Re: OpenGL and Vsync
Posted: Thu Dec 02, 2010 8:48 am
by N64vSNES
Thought I'd put that this remains unsolved