i think my framerate is locked at the vsync rate of my monitor/vid card.
it’s pretty obviously capped at 60 fps, and doest drop below that until i
start doing A LOT of stuff on the screen.
i think maybe it could be a problem w/ my fps counter… if someone has some
good code for one, i’d like to see if thats the problem
or, it could actually be locked to 60fps… how do i fix that?
<M@ the MadProgrammer>_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
i think my framerate is locked at the vsync rate of my monitor/vid
card. it’s pretty obviously capped at 60 fps, and doest drop below
that until i start doing A LOT of stuff on the screen.
If you use SDL_DOUBLEBUF|SDL_HWSURFACE on windows you’ll be locked to
the refresh rate of the monitor.
or, it could actually be locked to 60fps… how do i fix that?
Don’t use SDL_HWSURFACE|SDL_DOUBLEBUF. Create your own hardware
backbuffer, or use SDL_SWSURFACE.On Monday, November 25, 2002, at 11:33 AM, Matt Monson wrote:
i think my framerate is locked at the vsync rate of my monitor/vid card.
it’s pretty obviously capped at 60 fps, and doest drop below that until i
start doing A LOT of stuff on the screen.
i think maybe it could be a problem w/ my fps counter… if someone has some
good code for one, i’d like to see if thats the problem
or, it could actually be locked to 60fps… how do i fix that?
Hm. If your monitor IS running at 60Hz, what’s the point in refreshing faster
than it? You won’t see it. Or worse, you might, aka lots of tearing and
artifacts.
run dxdiag (on windows) and there is troubelshooter tab with override
button - in direcx refresh rate is limited in dx config - you can override
it to your max refresh rate
marex> ----- Original Message -----
From: tsm@accesscomm.ca (Tyler Montbriand)
To:
Sent: Monday, November 25, 2002 7:50 PM
Subject: Re: [SDL] Framerate locked (at vsync rate, i think)
Matt Monson wrote:
i think my framerate is locked at the vsync rate of my monitor/vid card.
it’s pretty obviously capped at 60 fps, and doest drop below that until
i
start doing A LOT of stuff on the screen.
i think maybe it could be a problem w/ my fps counter… if someone has
some
good code for one, i’d like to see if thats the problem
or, it could actually be locked to 60fps… how do i fix that?
Hm. If your monitor IS running at 60Hz, what’s the point in refreshing
faster
than it? You won’t see it. Or worse, you might, aka lots of tearing and
artifacts.
i think my framerate is locked at the vsync rate of my monitor/vid card.
it’s pretty obviously capped at 60 fps, and doest drop below that until i
start doing A LOT of stuff on the screen.
i think maybe it could be a problem w/ my fps counter… if someone has some
good code for one, i’d like to see if thats the problem
or, it could actually be locked to 60fps… how do i fix that?
I think it has already been said, but it’s worth saying again. Don’t.
It’s not broke. There is ‘zero’ point in refreshing faster than the
monitor can show.
See it as a blessing. You can increase the frequency of event
processing, network processing, or game state calculations. That’ll
help make your more responsive, which is a heck-of-a-lot better than
drawing frames that never appear on the screen.On Mon, 2002-11-25 at 11:33, Matt Monson wrote:
It should be mentioned that there are cases where you don’t want
vsync:
If you’re locked to vsync at 70Hz, and your hardware is capable of only
60 FPS, you’ll end up getting 35 FPS, since each frame waits for two
refreshes instead of one. For many games, 60 FPS with a little tearing
is better than 35 FPS.
Triple-buffering avoids this problem. (Of course, MS has made sure it’s
impossible to get triple-buffering in OpenGL in Windows without driver
hacks …)On Thu, Nov 28, 2002 at 01:22:27PM -0500, Jimmy wrote:
I think it has already been said, but it’s worth saying again. Don’t.
It’s not broke. There is ‘zero’ point in refreshing faster than the
monitor can show.
I think it has already been said, but it’s worth saying again. Don’t.
It’s not broke. There is ‘zero’ point in refreshing faster than the
monitor can show.
It should be mentioned that there are cases where you don’t want
vsync:
If you’re locked to vsync at 70Hz, and your hardware is capable of only
60 FPS, you’ll end up getting 35 FPS, since each frame waits for two
refreshes instead of one. For many games, 60 FPS with a little tearing
is better than 35 FPS.
This is not entirely true… when you call SDL_Flip() or
SDL_UpdateRects(), SDL is not supposed to block until the next time you
try to access the video surface. Usually after a Flip/UpdateRects
you’ll do a game-state update before even starting to compose your next
frame. This will take SOME time… Additionally, if you’re composing
the screen in an off-screen surface (which you should probably do if
you’re doing any alpha blending), then you won’t actually be accessing
the destination video surface until the final image has been composed.
This takes MORE time… So the only time when blocking waiting for
V-sync is an issue is when you’re actually transferring the off-screen
surface data to the video surface. While there will be some zone (ie.
35 FPS - 45 FPS) where triple-buffering will improve this, I don’t think
it provides significant gains in 2D…
Triple-buffering avoids this problem. (Of course, MS has made sure it’s
impossible to get triple-buffering in OpenGL in Windows without driver
hacks …)
When you’re dealing with 3D, this is a different story… Can you give
some details on triple buffering in OpenGL in Win32 vs. (for instance)
Linux?
-LorenOn Thu, 2002-11-28 at 15:49, Glenn Maynard wrote:
On Thu, Nov 28, 2002 at 01:22:27PM -0500, Jimmy wrote:
This is not entirely true… when you call SDL_Flip() or
SDL_UpdateRects(), SDL is not supposed to block until the next time you
try to access the video surface. Usually after a Flip/UpdateRects
you’ll do a game-state update before even starting to compose your next
Either way, direct 2D rendering is generally slow; and a bit silly, anyway,
considering how readily available OpenGL accel is these days. (Throw it
in ortho and get alpha blending for free, for starters.)
When you’re dealing with 3D, this is a different story… Can you give
some details on triple buffering in OpenGL in Win32 vs. (for instance)
Linux?
Double- and triple-buffering is outside the scope of OpenGL (in the same
way that eg. setting up windows and such is), so it has to be done at
the OS level. AFAIK, Windows doesn’t give any way to set up a triple-buffered
OpenGL window. Don’t know about other archs.On Fri, Nov 29, 2002 at 01:04:08AM -0800, Loren Osborn wrote: