That’s the idea - but actual page flipping (as in, not back-to-front
blits) calls for retrace sync’ed flips, or you’ll find yourself
rendering into the front buffer every now and then.
And screenshots… With some APIs, there doesn’t seem to be a correct,
safe way to implement it outside the application. Expect any random
weirdness… :-)On Thu, Feb 7, 2013 at 11:49 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
The rendering progressively part should be taken care by double
buffering.
–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’
It’s just a rendering loop that changes the screen colour and shape at
every different frame.
I’m not using it for developing a video game, but for display testing
equipment and the display was set at 50Hz.
I’ll try to see how it behaves on Linux, maybe the resolution of the timers
in Windows is really not enough for this kind of application.
Everyone, thanks for all the tips and suggestions!
VittorioOn Thu, Feb 7, 2013 at 5:59 PM, Alex Barry <alex.barry at gmail.com> wrote:
Can we see your loop and how you’re getting the frame rate? Otherwise, in
windows with some processors, the timers are only accurate to 10s of
milliseconds, which could possibly explain a 51 rather than a 60.
Try something like this to test:
#include
// … Setup your renderer with vsync enabled
UINT32 offsets[21];
offsets[0] = SDL_GetTicks();
for(int i=1; i < 21; i++)
{
SDL_RenderPresent( your_renderer );
offsets[i] = SDL_GetTicks();
}
for(int j=1; j < 21; j++)
printf( “Iteration #%d took %dms”, j, (offsets[j-1] - offsets[j]) );
It’s my suspicion that it’s just a timer resolution issue, but that loop
may give you some more insight into it.
Otherwise, I may suggest that it’s almost never a good idea to tie your
code to a specific framerate, since you have been able to demonstrate some
issues with milliseconds between frames. Take a look at a framerate
independent movement http://lazyfoo.net/SDL_tutorials/lesson32/index.phparticle.
On Thu, Feb 7, 2013 at 10:33 AM, Vittorio Giovara <vitto.giova at yahoo.it>wrote:
According to my tests, even when not polling for events and just calling
SDL_RenderPresent on a vsynced renderer I still get 50 to 51 fps.
Tested on win 7 using d3d, ogl and sw.
Probably using timers and an associated callback I could get a higher
resolution in respected timings, but I would get the same problem as soon
as i try to render something on 60Hz (where you have to call refresh every
16,6666 milliseconds).
Is there any other way that vsync and timers to get a frame refresh
synchronized with the screen framerate?
Even not using SDL if there is no such functionality?
Thanks,
Vittorio
On Wed, Feb 6, 2013 at 11:21 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
SDL_RenderPresent tells SDL to swap the front and back buffers. If
vsync is enabled, this will halt the thread until the current refresh
is over (effectively making it wait until the next frame starts).
I deal with events right after the video update (where this function
would be called) is done. There really isn’t much of point on
processing events more than once per frame (and if you don’t want to
be limited to frame steps then you probably don’t care about vsync for
starters).
Using SDL_Delay for timing is a bad idea, use timers instead. You will
probably need this for game logic timing anyway as you can’t predict
what will be the refresh rate of the video mode you’re using (unless
you’re forcing it, but that’s as bad as not letting the user change
the resolution and doesn’t work everywhere).
2013/2/6, Vittorio Giovara <vitto.giova at yahoo.it>:
Are you sure SDL_RenderPresent blocks the thread until the next frame
starts?
If that’s the case, then you shouldn’t be adding SDL_Delay between each
frame no?
How are you going to deal with events in the meantime otherwise?
Vittorio
On Wed, Feb 6, 2013 at 9:39 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:
Enabling vsync should do the trick, that’s the whole point of vsync
after all. If that doesn’t work then it means something else (either a
SDL bug or a driver bug or something like that) is interfering,
assuming you aren’t overriding it with an environment variable.
The program really shouldn’t need to do anything besides enabling
vsync. Then whenever SDL_RenderPresent is called the thread will halt
until the next frame starts.
2013/2/6, Vittorio Giovara <vitto.giova at yahoo.it>:
Well at least now we know more about the interaction between the
hint
and
the renderer.
Returning to the original question (Is it possible to force a
refresh
of
a
SDL renderer exactly when a screen refresh happens?) is there any
other
suggestion?
Best,
Vittorio
On Tue, Feb 5, 2013 at 3:33 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:
Welp, forgot about that. Went to check the code, and found this:
hint = SDL_GetHint(SDL_HINT_RENDER_VSYNC);
if (hint) {
if (*hint == '0') {
flags &= ~SDL_RENDERER_PRESENTVSYNC;
} else {
flags |= SDL_RENDERER_PRESENTVSYNC;
}
}
Looks like the hint overrides the flag if present and does nothing
otherwise. So yeah, go with the flag instead, sorry.
Interesting how I can set the hint to “01” and it effectively force
vsync off, though… 
2013/2/5, Vittorio Giovara <vitto.giova at yahoo.it>:
Isn’t that the same of doing
SDL_CreateRenderer(sdlwindow, -1, SDL_RENDERER_ACCELERATED |
SDL_RENDERER_PRESENTVSYNC);
or does the hint impacts a different section of code?
Vittorio
On Tue, Feb 5, 2013 at 11:37 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
…and this is when I wish I could edit e-mails.
SDL_SetHintWithPriority(SDL_HINT_RENDER_VSYNC, enable_vsync ?
“1” :
“0”, SDL_HINT_OVERRIDE);
Still, you get the idea.
2013/2/5, Sik the hedgehog <sik.the.hedgehog at gmail.com>:
There’s a hint that can be used to enable and disable vsync.
Just
replace its default value (ideally give the option to the
user in
the
program). Not sure if it requires reinitializing the video
mode,
didn’t get around using it yet.
SDL_SetHint(SDL_HINT_RENDER_VSYNC, “1”);
If you’re providing the setting from within the program then
you
probably want to override the hint to ensure the program’s own
setting
is used (if you don’t provide the setting then don’t override
it
please!):
SDL_SetHintWithPriority(SDL_HINT_RENDER_VSYNC, enable_vsync,
SDL_HINT_OVERRIDE);
2013/2/5, Vittorio Giovara <vitto.giova at yahoo.it>:
Hi,
Is it possible to force a refresh of a SDL renderer exactly
when
a
screen
refresh happens?
Right now I have the screen set at 50Hz, I’m drawing
something
(color
fill)
and then wait (with SDL_Delay) for 20ms before drawing again.
However
with
any rendering backend (directx, opengl and software) and with
vsync
on
and
off, sometimes I get exactly 50 frames in one second,
sometimes
-
Moreover this approach won’t work if I set the screen to
60Hz as
you’d
have
to wait for 16,66666ms.
What can it be done about this? I was thinking of using the
high
resolution
timer but not sure I’m going into the right direction.
If it is not possible to do it with SDL, can anyone give any
pointer
how
they would do it?
Cheers,
Vittorio
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Oi!
For something like that then yes, you really need to use vsync for
timing and nothing else. I think timers are more accurate in Linux,
but still don’t rely on them because they are not timed to video
hardware and hardware isn’t perfect (even a very slight variation is
enough to throw it off).
Would have probably helped if you mentioned that at the beginning XD
2013/2/8, Vittorio Giovara <vittorio.giovara at gmail.com>:> It’s just a rendering loop that changes the screen colour and shape at
every different frame.
I’m not using it for developing a video game, but for display testing
equipment and the display was set at 50Hz.
I’ll try to see how it behaves on Linux, maybe the resolution of the timers
in Windows is really not enough for this kind of application.
Everyone, thanks for all the tips and suggestions!
Vittorio
On Thu, Feb 7, 2013 at 5:59 PM, Alex Barry <alex.barry at gmail.com> wrote:
Can we see your loop and how you’re getting the frame rate? Otherwise,
in
windows with some processors, the timers are only accurate to 10s of
milliseconds, which could possibly explain a 51 rather than a 60.
Try something like this to test:
#include
// … Setup your renderer with vsync enabled
UINT32 offsets[21];
offsets[0] = SDL_GetTicks();
for(int i=1; i < 21; i++)
{
SDL_RenderPresent( your_renderer );
offsets[i] = SDL_GetTicks();
}
for(int j=1; j < 21; j++)
printf( “Iteration #%d took %dms”, j, (offsets[j-1] - offsets[j]) );
It’s my suspicion that it’s just a timer resolution issue, but that loop
may give you some more insight into it.
Otherwise, I may suggest that it’s almost never a good idea to tie your
code to a specific framerate, since you have been able to demonstrate
some
issues with milliseconds between frames. Take a look at a framerate
independent movement
http://lazyfoo.net/SDL_tutorials/lesson32/index.phparticle.
On Thu, Feb 7, 2013 at 10:33 AM, Vittorio Giovara <vitto.giova at yahoo.it>wrote:
According to my tests, even when not polling for events and just calling
SDL_RenderPresent on a vsynced renderer I still get 50 to 51 fps.
Tested on win 7 using d3d, ogl and sw.
Probably using timers and an associated callback I could get a higher
resolution in respected timings, but I would get the same problem as
soon
as i try to render something on 60Hz (where you have to call refresh
every
16,6666 milliseconds).
Is there any other way that vsync and timers to get a frame refresh
synchronized with the screen framerate?
Even not using SDL if there is no such functionality?
Thanks,
Vittorio
On Wed, Feb 6, 2013 at 11:21 AM, Sik the hedgehog < @Sik_the_hedgehog> wrote:
SDL_RenderPresent tells SDL to swap the front and back buffers. If
vsync is enabled, this will halt the thread until the current refresh
is over (effectively making it wait until the next frame starts).
I deal with events right after the video update (where this function
would be called) is done. There really isn’t much of point on
processing events more than once per frame (and if you don’t want to
be limited to frame steps then you probably don’t care about vsync for
starters).
Using SDL_Delay for timing is a bad idea, use timers instead. You will
probably need this for game logic timing anyway as you can’t predict
what will be the refresh rate of the video mode you’re using (unless
you’re forcing it, but that’s as bad as not letting the user change
the resolution and doesn’t work everywhere).
2013/2/6, Vittorio Giovara <vitto.giova at yahoo.it>:
Are you sure SDL_RenderPresent blocks the thread until the next frame
starts?
If that’s the case, then you shouldn’t be adding SDL_Delay between
each
frame no?
How are you going to deal with events in the meantime otherwise?
Vittorio
On Wed, Feb 6, 2013 at 9:39 AM, Sik the hedgehog <@Sik_the_hedgehog wrote:
Enabling vsync should do the trick, that’s the whole point of vsync
after all. If that doesn’t work then it means something else (either
a
SDL bug or a driver bug or something like that) is interfering,
assuming you aren’t overriding it with an environment variable.
The program really shouldn’t need to do anything besides enabling
vsync. Then whenever SDL_RenderPresent is called the thread will
halt
until the next frame starts.
2013/2/6, Vittorio Giovara <vitto.giova at yahoo.it>:
Well at least now we know more about the interaction between the
hint
and
the renderer.
Returning to the original question (Is it possible to force a
refresh
of
a
SDL renderer exactly when a screen refresh happens?) is there any
other
suggestion?
Best,
Vittorio
On Tue, Feb 5, 2013 at 3:33 PM, Sik the hedgehog <@Sik_the_hedgehog wrote:
Welp, forgot about that. Went to check the code, and found this:
hint = SDL_GetHint(SDL_HINT_RENDER_VSYNC);
if (hint) {
if (*hint == '0') {
flags &= ~SDL_RENDERER_PRESENTVSYNC;
} else {
flags |= SDL_RENDERER_PRESENTVSYNC;
}
}
Looks like the hint overrides the flag if present and does
nothing
otherwise. So yeah, go with the flag instead, sorry.
Interesting how I can set the hint to “01” and it effectively
force
vsync off, though…
2013/2/5, Vittorio Giovara <vitto.giova at yahoo.it>:
Isn’t that the same of doing
SDL_CreateRenderer(sdlwindow, -1, SDL_RENDERER_ACCELERATED |
SDL_RENDERER_PRESENTVSYNC);
or does the hint impacts a different section of code?
Vittorio
On Tue, Feb 5, 2013 at 11:37 AM, Sik the hedgehog < @Sik_the_hedgehog> wrote:
…and this is when I wish I could edit e-mails.
SDL_SetHintWithPriority(SDL_HINT_RENDER_VSYNC, enable_vsync ?
“1” :
“0”, SDL_HINT_OVERRIDE);
Still, you get the idea.
2013/2/5, Sik the hedgehog <@Sik_the_hedgehog>:
There’s a hint that can be used to enable and disable vsync.
Just
replace its default value (ideally give the option to the
user in
the
program). Not sure if it requires reinitializing the video
mode,
didn’t get around using it yet.
SDL_SetHint(SDL_HINT_RENDER_VSYNC, “1”);
If you’re providing the setting from within the program then
you
probably want to override the hint to ensure the program’s
own
setting
is used (if you don’t provide the setting then don’t
override
it
please!):
SDL_SetHintWithPriority(SDL_HINT_RENDER_VSYNC, enable_vsync,
SDL_HINT_OVERRIDE);
2013/2/5, Vittorio Giovara <vitto.giova at yahoo.it>:
Hi,
Is it possible to force a refresh of a SDL renderer exactly
when
a
screen
refresh happens?
Right now I have the screen set at 50Hz, I’m drawing
something
(color
fill)
and then wait (with SDL_Delay) for 20ms before drawing
again.
However
with
any rendering backend (directx, opengl and software) and
with
vsync
on
and
off, sometimes I get exactly 50 frames in one second,
sometimes
-
Moreover this approach won’t work if I set the screen to
60Hz as
you’d
have
to wait for 16,66666ms.
What can it be done about this? I was thinking of using the
high
resolution
timer but not sure I’m going into the right direction.
If it is not possible to do it with SDL, can anyone give
any
pointer
how
they would do it?
Cheers,
Vittorio
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org