SDL_Flip causes a HUGE loss of fps!

SDL Development
1

hI everybody!

When I update the screen in fullscreen mode, I have a quite normal loop
like this:

	surface = SDL_GetVideoSurface ();

	if (!surface) return;

	if ( DK_SURFACE_IS_OPENGL (surface) )
	{
		draw stuff...
		SDL_GL_SwapBuffers ();
	}
	else
	{
		draw stuff...
		SDL_Flip (surface);
	}

Let’s talk about the non-opengl surface…

without the SDL_Flip (surface); I have ~33500 fps doing nothing else
but waiting a key (640x480 32bpp, Athlon 650 under linux)

with that call, the frame rate goes down to ~118 fps !!

is this normal?

FYI, I create the surface with this code

sdl_flags |= SDL_HWSURFACE | SDL_DOUBLEBUF | SDL_FULLSCREEN;

if ( SDL_VideoModeOK (surface_old->w, surface_old->h, 32, sdl_flags) )
{
	fullscreen = SDL_SetVideoMode ( surface_old->w, surface_old->h, 32,

sdl_flags);
if (!fullscreen)
{
DK_ERROR (“Unable to set the fullscreen: %s”, SDL_GetError() );
return (FALSE);
}
}
else
{
DK_ERROR (“requested fullscreen video mode is not supported”);
return (FALSE);
}

but at this point, neither SDL_HWSURFACE and SDL_DOUBLEBUF are active
on the fullscreen surface :?

I get the videomodes like this:

modes = SDL_ListModes (NULL, SDL_FULLSCREEN | SDL_HWSURFACE |
SDL_OPENGLBLIT );

any suggestion?

thanks ins advance!–
signed
derethor of centolos

2

Derethor wrote:

without the SDL_Flip (surface); I have ~33500 fps doing nothing else
but waiting a key (640x480 32bpp, Athlon 650 under linux)
with that call, the frame rate goes down to ~118 fps !!

118fps is an extremely good framerate on any platform. It takes time to
update video memory.

-John–
Underfull \account (badness 10000) has occurred while \spend is active
John R. Hall - Student, Georgia Tech - Contractor, Loki Software

3

without the SDL_Flip (surface); I have ~33500 fps doing nothing else
but waiting a key (640x480 32bpp, Athlon 650 under linux)

with that call, the frame rate goes down to ~118 fps !!

You DEFINITELY need to throttle the code with a call to SDL_Delay().
A tight loop that causes “~33500 fps” is just eating your CPU, which
is not nice.

As you said, all it’s doing is waiting for a keypress…

Hell, what’s even the point of updating the screen (SDL_Flip() or
otherwise) if nothing’s being drawn on it!?!

-bill!

4

Let’s talk about the non-opengl surface…

without the SDL_Flip (surface); I have ~33500 fps doing nothing else
but waiting a key (640x480 32bpp, Athlon 650 under linux)

with that call, the frame rate goes down to ~118 fps !!

is this normal?

That is normal.

Using SDL_Flip means that the flipping has to
wait for the vertical retrace which means that
you shouldn’t get a frame rate above your display
mode refresh rate.

I.E. at 118fps it means you’re probably running
your monitor at 118Hz vertical refresh rate.

However, my problem is the opposite, running
testsprite.c with the flags you mentioned and
confirming that SDL_Flip being used (via printfs),
I couldn’t get my frame rate <= the refresh rate.
SDL_Flip was not waiting for the vertical retrace
in my case, the opposite of what is happening with
you! Further proof that SDL_Flip() is not waiting
for the vertical retrace is painfully obvious
tearing (shearing) I get when I replaced the default
icon.bmp with a somewhat larger more visible bitmap.

I’m running libSDL under Win2K/DirectX. Are you
using X Window?

but at this point, neither SDL_HWSURFACE and SDL_DOUBLEBUF are active
on the fullscreen surface :?

SDL_DOUBLEBUF should be active and that’s why
you’re getting vertical retrace syncing (hence
the lower frame rate). I don’t see any reason
SDL_HWSURFACE is not active either.> From: “Derethor”

5

“Andy Sy” schrieb im Newsbeitrag news:988tgj$5u0$1 at ftp.lokigames.com…

Let’s talk about the non-opengl surface…

without the SDL_Flip (surface); I have ~33500 fps doing nothing else
but waiting a key (640x480 32bpp, Athlon 650 under linux)

with that call, the frame rate goes down to ~118 fps !!

is this normal?

That is normal.

Using SDL_Flip means that the flipping has to
wait for the vertical retrace which means that
you shouldn’t get a frame rate above your display
mode refresh rate.

I.E. at 118fps it means you’re probably running
your monitor at 118Hz vertical refresh rate.

However, my problem is the opposite, running
testsprite.c with the flags you mentioned and
confirming that SDL_Flip being used (via printfs),
I couldn’t get my frame rate <= the refresh rate.
SDL_Flip was not waiting for the vertical retrace
in my case, the opposite of what is happening with
you! Further proof that SDL_Flip() is not waiting
for the vertical retrace is painfully obvious
tearing (shearing) I get when I replaced the default
icon.bmp with a somewhat larger more visible bitmap.

I’m running libSDL under Win2K/DirectX. Are you
using X Window?

What DirectX Vers. is installed on your Comp. ???> > From: “Derethor”

but at this point, neither SDL_HWSURFACE and SDL_DOUBLEBUF are active
on the fullscreen surface :?

SDL_DOUBLEBUF should be active and that’s why
you’re getting vertical retrace syncing (hence
the lower frame rate). I don’t see any reason
SDL_HWSURFACE is not active either.

6

DirectX 8 SDK. Although I’d be very surprised
and interested if that was the problem!> What DirectX Vers. is installed on your Comp. ???