OpenGL Switching PresentInterval after window creation

Recommended Posts

Is there some way to switch the present interval dynamically after the window has already been created? I cannot find a way to do that in DirectX9. I can only find how to set it at startup. I know this can be done in OpenGL on Windows, and even in DirectX9 on the Xbox 360. So is there something similar in DirectX9 on PC?

Searching the forum, I found [url="http://www.gamedev.net/topic/424071-mdx-turning-vsync-onoff-without-recreating-swap-chain/"]this old topic[/url], but that suggests I need to reset things to switch VSync. Doing this takes some time, is that correct? Or can that be done at any time in between two frames without causing a framedrop because of the reset?

I know that quite a few games these days have VSync on by default and then dynamically shortly turn if off if the framerate drops too far. When the framerate is back to normal, vsync is then turned on again. How is this done on PC in DirectX9? Or is this only done on consoles?

Share on other sites
To change VSYNC in DX9 you need to reset the device, which is really slow since you have to release all of your non-managed resources. So you can't change it frame-to-frame to get the "soft VSYNC" effect that you're referring to. In DX10/DX11 the sync interval is a parameter that you pass to Present, so it is possible to change it each frame. However even with that it's still difficult do a soft VSYNC, since you don't have the same amount of low-level timing info and control that you do on consoles. I'm not sure if any PC games have actually shipped with it, but if they did they were surely using DX10 or DX11. (The one notable exception is RAGE, which had Nvidia add a soft VSYNC option into the driver for them). Edited by MJP

Share on other sites
On Vista and Win7 D3D9Ex has a WaitForVBlank method, which I guess does the same as the DXGI version, though I haven't tried it.
You could also create a DirectDraw device that you use only for VSync. Check out WaitForVerticalBlank, [url="http://msdn.microsoft.com/en-us/library/aa911354.aspx"]http://msdn.microsof...y/aa911354.aspx[/url] or GetVerticalBlankStatus. Edited by Erik Rufelt

Share on other sites
Okay, sounds like my best option then is to just not support dynamic vsync switching in my engine and move the vsync option from the in-game settings menu to the pre-game launcher.

Kind of funny how some features are impossible in one API, and no problem in another. Same OS, same hardware, but DirectX 9 can't do it and OpenGL can. Guess DX10/11 do have some useful improvements after all. [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img]

Thanks for the help, folks! Edited by Oogst

Share on other sites
[quote name='MJP' timestamp='1345312105' post='4970875']
However even with that it's still difficult do a soft VSYNC, since you don't have the same amount of low-level timing info and control that you do on consoles.
[/quote]Does DX11 have a GPU timestamp read-back API, and a requirement for GPUs to support it? DX9 is lacking this, and GL has it via an extension (not sure which GPUs do and don't support the extension though).
Being able to stamp your frames to get a value on GPU processing time would be a great base-level API requirement ([i]like on consoles[/i]). Even if read-back is delayed, you can use a rolling average to get yourself out of trouble a few frames after vsync starts being consistently harmful.

Share on other sites
[quote name='Hodgman' timestamp='1345447620' post='4971365']Does DX11 have a GPU timestamp read-back API, and a requirement for GPUs to support it? DX9 is lacking this, and GL has it via an extension (not sure which GPUs do and don't support the extension though).
Being able to stamp your frames to get a value on GPU processing time would be a great base-level API requirement ([i]like on consoles[/i]). Even if read-back is delayed, you can use a rolling average to get yourself out of trouble a few frames after vsync starts being consistently harmful.
[/quote]
Doesn't DirectX have some equivalent of OpenGL's fences? Fences are not exactly what you describe, but they do give some nice information on where the videocard is at the moment. Edited by Oogst

Share on other sites
There are timestamp queries, which are actually available in DX9 as well.

Share on other sites
[quote name='MJP' timestamp='1345449778' post='4971374']
There are timestamp queries, which are actually available in DX9 as well.
[/quote]You've just blown my mind!
I swear that last time I looked at the local version of [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb147308(v=vs.85).aspx"]this page[/url] (inside the DirectX SDK's installed documentation), there was no timestamp query.
I was still under the impression that the only method of timing GPU usage under DX9 was the non-real-time, CPU-blocking, flush & finish method [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb172234(v=vs.85).aspx"]described here[/url].

On consoles, I basically use a ring-buffer of time-stamp queries to detect bad performance; the major check is using the deltas to calculate a rolling average of GPU-frame-time to see if there's consistently bad GPU performance. It seems I can implement this on DX9 as well?

Share on other sites
[quote name='Hodgman' timestamp='1345451449' post='4971381']
[quote name='MJP' timestamp='1345449778' post='4971374']
There are timestamp queries, which are actually available in DX9 as well.
[/quote]You've just blown my mind!
I swear that last time I looked at the local version of [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb147308(v=vs.85).aspx"]this page[/url] (inside the DirectX SDK's installed documentation), there was no timestamp query.
I was still under the impression that the only method of timing GPU usage under DX9 was the non-real-time, CPU-blocking, flush & finish method [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb172234(v=vs.85).aspx"]described here[/url].

On consoles, I basically use a ring-buffer of time-stamp queries to detect bad performance; the major check is using the deltas to calculate a rolling average of GPU-frame-time to see if there's consistently bad GPU performance. It seems I can implement this on DX9 as well?
[/quote]

Yeah I had thought they were new for DX10, but someone else pointed out to me that DX9 has them as well. In my experience the query works pretty much the way you'd expect. Which of course means it has all of the usual latency problems with queries, as well as the "just what exactly am I measuring?" problem you have with reading GPU timestamps. Edited by MJP

Create an account

Register a new account

• Forum Statistics

• Total Topics
627716
• Total Posts
2978783
• Similar Content

• Hello! As an exercise for delving into modern OpenGL, I'm creating a simple .obj renderer. I want to support things like varying degrees of specularity, geometry opacity, things like that, on a per-material basis. Different materials can also have different textures. Basic .obj necessities. I've done this in old school OpenGL, but modern OpenGL has its own thing going on, and I'd like to conform as closely to the standards as possible so as to keep the program running correctly, and I'm hoping to avoid picking up bad habits this early on.
Reading around on the OpenGL Wiki, one tip in particular really stands out to me on this page:
For something like a renderer for .obj files, this sort of thing seems almost ideal, but according to the wiki, it's a bad idea. Interesting to note!
So, here's what the plan is so far as far as loading goes:
Set up a type for materials so that materials can be created and destroyed. They will contain things like diffuse color, diffuse texture, geometry opacity, and so on, for each material in the .mtl file. Since .obj files are conveniently split up by material, I can load different groups of vertices/normals/UVs and triangles into different blocks of data for different models. When it comes to the rendering, I get a bit lost. I can either:
Between drawing triangle groups, call glUseProgram to use a different shader for that particular geometry (so a unique shader just for the material that is shared by this triangle group). or
Between drawing triangle groups, call glUniform a few times to adjust different parameters within the "master shader", such as specularity, diffuse color, and geometry opacity. In both cases, I still have to call glBindTexture between drawing triangle groups in order to bind the diffuse texture used by the material, so there doesn't seem to be a way around having the CPU do *something* during the rendering process instead of letting the GPU do everything all at once.
The second option here seems less cluttered, however. There are less shaders to keep up with while one "master shader" handles it all. I don't have to duplicate any code or compile multiple shaders. Arguably, I could always have the shader program for each material be embedded in the material itself, and be auto-generated upon loading the material from the .mtl file. But this still leads to constantly calling glUseProgram, much more than is probably necessary in order to properly render the .obj. There seem to be a number of differing opinions on if it's okay to use hundreds of shaders or if it's best to just use tens of shaders.
So, ultimately, what is the "right" way to do this? Does using a "master shader" (or a few variants of one) bog down the system compared to using hundreds of shader programs each dedicated to their own corresponding materials? Keeping in mind that the "master shaders" would have to track these additional uniforms and potentially have numerous branches of ifs, it may be possible that the ifs will lead to additional and unnecessary processing. But would that more expensive than constantly calling glUseProgram to switch shaders, or storing the shaders to begin with?
With all these angles to consider, it's difficult to come to a conclusion. Both possible methods work, and both seem rather convenient for their own reasons, but which is the most performant? Please help this beginner/dummy understand. Thank you!

• I want to make professional java 3d game with server program and database,packet handling for multiplayer and client-server communicating,maps rendering,models,and stuffs Which aspect of java can I learn and where can I learn java Lwjgl OpenGL rendering Like minecraft and world of tanks

• A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

-What I'm using:
C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.
-Questions
Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?

• Both functions are available since 3.0, and I'm currently using glMapBuffer(), which works fine.
But, I was wondering if anyone has experienced advantage in using glMapBufferRange(), which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
• By xhcao
Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness.

• 9
• 21
• 14
• 12
• 42