Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


OpenGL: How to detach frame rate form refresh rate


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
18 replies to this topic

#1 AHa   Members   -  Reputation: 122

Like
Likes
Like

Posted 19 March 2001 - 07:29 AM

Do anyone know how to detach frame rate form refresh rate??....

Sponsor:

#2 zedzeek   Members   -  Reputation: 528

Like
Likes
Like

Posted 19 March 2001 - 08:36 AM

this is os specific
in windows u can disable it in the display properties tab, also theres an extension win_swap_interval (see my site for a demo)

http://members.xoom.com/myBollux

#3 AHa   Members   -  Reputation: 122

Like
Likes
Like

Posted 20 March 2001 - 05:04 AM

It''s all about windows... Which example do you speak about?

please helpme a bit more

#4 zedzeek   Members   -  Reputation: 528

Like
Likes
Like

Posted 20 March 2001 - 08:58 AM

bottom of page click on "opengl extensions" then click "win swap interval"

http://members.xoom.com/myBollux

#5 PowerBoyAlfa   Members   -  Reputation: 122

Like
Likes
Like

Posted 20 March 2001 - 12:04 PM

If you are referring to the fact that when you use fullscreen exclusive mode that the speed of you rendering matches the speed of your refresh rate. The reason is simple. It is because of the surface option to wait for the verticle refresh before flipping the back buffer to the primary buffer. If you were to ignore this, your program would traverse though your code at full speed without stopping, but you would get a nasty flashing glitches in your graphics (fine for testing). To wait for your verticle refresh is to bring your main graphics rendering loop to a screeching halt until your refesh has flipped the surface. It is okay however, since when the flipping is done, your code blasts through the loop until it gets back to the flip surface routine again. The only way to have code run constantly without stopping for the flip is to run a separate thread.

#6 Xtreme   Members   -  Reputation: 122

Like
Likes
Like

Posted 20 March 2001 - 03:47 PM

Actually I''ve noticed a number of things when running Win2k vs. WinMe.

In Win2k, when i run my demo in full screen mode, the FPS value cannot pass the refresh rate. However, running it in windowed mode, it does.

This problem does not occur under WinMe.
Also, i noticed the FPS is lower in fullscreen compared to windowed when running under Win2K. Again this problem does not occur in WinMe.

-Xtreme.

#7 Poya   Members   -  Reputation: 122

Like
Likes
Like

Posted 20 March 2001 - 09:27 PM

Sorry but I have had this problem for a long time and i think it is related to the same issue. I notice in my games, there are set frame rates i can get. eg normally i get a frame rate of ~72, but there is a certain point beyond which adding 1 more poly causes frame rate to drops to 35, then again 24 and... I heard that this has to do with refresh rate or something. Could anyone explain to me why and what this is? is there a way to force a more gradual drop in framerate? Oh and i have noticed that this kindda doesn''t happen in Quake 3.

Thanks

#8 Anonypous Moster   Members   -  Reputation: 122

Like
Likes
Like

Posted 20 March 2001 - 11:38 PM

With VSync on you will only get factors of the refresh rate. With a 60Hz refresh rate, you will only get 60FPS, 30FPS, 15FPS and so on. You can''t get a more gradual drop unless you turn VSync off which is undesirable.

#9 Maximus   Members   -  Reputation: 124

Like
Likes
Like

Posted 21 March 2001 - 12:04 AM

quote:
Original post by Xtreme
In Win2k, when i run my demo in full screen mode, the FPS value cannot pass the refresh rate. However, running it in windowed mode, it does.



Strange, I can run games in full screen with vsync disabled and get a higher fps than my refresh rate. Running Win2k pro w/ a 32meg geforce sdr, leaked 10.80 drivers.


#10 Null and Void   Moderators   -  Reputation: 1087

Like
Likes
Like

Posted 21 March 2001 - 12:45 AM

As was said in the previous post, I get higher numbers than my refresh rate in fullscreen in Win2K as well. Oh, and while I''m on this topic, I read a review about WinME vs. Win2K''s game performance, and Win2K was faster for almost every game except UT .

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said
Resist Windows XP''s Invasive Production Activation Technology!
http://www.gdarchive.net/druidgames/

#11 Maximus   Members   -  Reputation: 124

Like
Likes
Like

Posted 21 March 2001 - 12:57 AM

Put simply, the Unreal engine has problems. The software renderer effects the hardware renderer which causes some of the slowdowns in D3D and OGL. 3DRealms removed the software renderer from Duke Forever, and sped up the hardware renderer by doing so. Sure hope DNF does get released eventually, I soooo want that game! Even more so than the new Doom at the moment.

#12 AHa   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 March 2001 - 03:36 AM

My reply to all these topics questions and so on:

First i have worked with DirectDraw.. There it''s very simple to detach the framerate from the refresh rate.. You only set in the flip functio some code like this DDFLIP_NOVSYNC

and it works fine.. I get framerates above 1000 fps ) but you have some tearing effects...

So in opengl i think there is an option to do this also. First I somtime plays quake it''s OpenGL and it has a function in it to do this.

So I want to know that code )


#13 AHa   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 March 2001 - 03:37 AM

and this works in all windows versions! also in win2k and win me

#14 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 21 March 2001 - 03:50 AM

I''m not really saying anything new here...

wglSwapInterval is your answer. wglSwapInterval(0) disables retrace synchronization and wglSwapInterval(1) enables it. Whatever you decide to use, wglSwapInterval _should_ override any driver settings, but don''t necessarily expect it to.

OpenGL was intended to be hardware-independent so things like retrace synchroniziation are handled by the OS, so don''t expect to have OpenGL do it. OpenGL is just for drawing stuff, not managing frame buffers or anything like that.

Personally, I''d rather use a hardware-indepentent API like OpenGL and not have to worry about setting up structures and querying stuff to the point that I have 20 pages of code before I can even draw something like with Direct3D. I may be wrong on this, but if anyone says that DirectX 8 eliminates that, I should point out that Microsoft just wrapped the old stuff in the same way that the OpenGL utility library does, and that''s something that''s existed in OpenGL long before Direct3D ever existed.

#15 Xtreme   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 March 2001 - 12:00 PM

I don''t see a mention of wglSwapInterval anywhere on MSDN!
Is this hardware dependent?

#16 zedzeek   Members   -  Reputation: 528

Like
Likes
Like

Posted 21 March 2001 - 02:03 PM

MSDN is not very uptodate with opengl. have a look at www.opengl.org or my site under gl extensions

http://members.xoom.com/myBollux

#17 Shadwdrak   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 March 2001 - 04:16 PM

I don''t want to sound dumb, but hey this place is for help right?

Is retrace synchronization is the same as vertical sync?

-Will

#18 PowerBoyAlfa   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 March 2001 - 03:32 AM

Yes, the politically correct term is "verticle retrace" but there are numerous other terms, e.g. "refresh rate". It seems like we have been repeating ourselves a lot, so here is how it works. The Cathode Ray Tube (Monitor) has to draw one line at a time usually in a top-to-bottom motion. It is going fast enough that the human eye detects it as one steady image. But if you notice, the lower the refresh rate, the more flashy and blurry your image gets (tough on the eyes). It is recommened to run in refresh rates of 75hz or higher.

The reason you get "tearing" is because, if you decide NOT to wait for the refresh to finish drawing and start at the top, the image you place in your primary buffer instantly goes to the screen, even if the monitor isn''t done drawing the first frame, so you get part of one image at the top of the screen and part of another image at the bottom (ugly).

When you tell your code to wait for "verticle syncing", you are waiting for the frame in your primary buffer to be completely drawn to the screen and the CRT to move back up to the top of the screen to start drawing the next frame. It is at this point, the backbuffer is flipped to the primary buffer, the CRT begins drawing. and you code is free to put more data in the back buffer. Your CPU is much faster than your monitor, so it gets done doing everything, long before the monitor has finished drawing the last bit of data you flipped to the primary buffer. So when you code gets back to the flip function. It waits again until it has permission to flip the buffers. Repeated a million times or so.

#19 Anonypous Moster   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 March 2001 - 04:35 AM

Refresh rate is NOT the same as Vertical retrace. The refresh rate is, basically, what it says - the rate at which the vertical retrace occurs. This of course is assuming you are talking about the vertical refresh rate. The vertical retrace is the actual event where the electron gun is repositioning itself back at the top of the frame.
Vertical sync is a term used to denote that you are in synchronisation with the vertical retrace, that is you wait for the vertical retrace before doing the flip.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS