# SDL Framerates and SDL_Flip()

## Recommended Posts

Well, I've been working on my SDL engine today. And I have noticed that even when I draw a single sprite like this:
void Render()
{
// Needed for drawing sprites; or else it will leave a trail when I move
//    the sprite
SDL_FillRect(g_pEngine->GetScreen(), NULL, 0x00000000);

sprite1.Draw(g_pEngine->GetScreen());    // Draw the sprite

SDL_Flip(g_pEngine->GetScreen());
}


My frame rate is only 30-33 FPS. I am on Windows 2000 Pro SP4, PIII 733MHz, GeForce FX 5200 128MB, 256MB RAM. At first, I didn't understand why the FPS was so low. But when I comment out the "sprite1.Draw(...)" call, the FPS stays nearly the same. But when I comment out the "SDL_Flip" call, I get a frame rate of 50,000+. Is that possible? LoL. Could someone enlighten me on what is causing this? And "g_pEngine->GetScreen()" only does "return m_pScreen;", which is defined as (in 'CEngine') "SDL_Surface *m_pScreen;". Why does "SDL_Flip" cause such a low frame rate? Or am I doing something wrong here? Thanks in advance, Matt U.

#### Share this post

##### Share on other sites
are you using double buffering? if not maybe that's the problem add SDL_DOUBLEBUF flag to the screen creation code or change SDL_Flip() line with SDL_UpdateRect(g_pEngine->GetScreen(), 0, 0, 0, 0);

EDIT: For more info take a look: http://manuals.thexdershome.com/SDL-1.2.5/html/sdlflip.html

And here it says: The SDL_DOUBLEBUF flag must have been passed to SDL_SetVideoMode, when setting the video mode for this function to perform hardware flipping.

hope that helps

#### Share this post

##### Share on other sites
Quote:
 Original post by TFS_WaldoWhy does "SDL_Flip" cause such a low frame rate? Or am I doing something wrong here?

No, you are not doing anything wrong. What you are asking is pretty much what I was experimenting with on this thread. As you will see, by using similar methods to what I was doing, you can actually get great performance out of SDL, but the solution is not really "acceptable":
Quote:
 This experiment, while it works great for simple things, is not a generic all purpose solution that could replace simply calling SDL_Flip after clearing the screen. The problem is that while this method is actually more efficient, it only draws/clears the needed sections, as soon as you get more advanced games, such as if you have a moving background, then you end up doing the same thing as you would have done with simply flipping. So all in all, most games have a background that will change, thus breaking the algorithm, so this idea has pretty much been abandoned over simply using OpenGL in 2D.

So as you can see, you can take out SDL_Flip and use SDL_UpdateRects instead in an optimized manner, but you are just creating too much work for yourself that you could otherwise solve by using a hardware accelerated graphics API such as Direct3D or OpenGL. The main problem is that SDL uses DirectDraw 5, so it's just slow and limited. I was looking into adding a D3D video device for SDL, but first gotta learn D3D [wink]. Anyways, I hope that clears up this topic a bit. Good luck with your game!

#### Share this post

##### Share on other sites
Well, thank you both. As soon as I have time to get back to it, I'll try both suggestions. And I'll be back to let you know if it worked. Thank you very much! =)

#### Share this post

##### Share on other sites
Hi, I don't know really how much a better computer system affects this, mine is not great but it's new. I've written a tetris clone using SDL, I don't remember exactly but i thought FPS was at least over 200.

SDL will be especially slow when you blit from different kinds of surfaces, hardware and software. To make it faster it is important to:
- initialize with a hardware display surface (and make sure you got it!)
- don't use alpha blending, only colorkey (or use software display surface)
- call SDL_Displayformat on your surfaces
- no direct pixel access in hardware mode.

Furthermore you can limit the resolution and work in 16-bit color mode.

For not too complex games SDL can perform reasonably if you use it the right way and can live with the limitations.

#### Share this post

##### Share on other sites
** vertical retrace **
** vertical retrace **
** vertical retrace **

It's a shame that what was common knowledge on these boards 4 or 5 years ago, is now not very well known.

Flipping waits for the vertical retrace. This means it's synchronised to your monitor's refresh rate, or some even division of it. You can't break that barrier without getting rid of flipping and using blitting instead, which is usually achieved by either moving to windowed mode or explicitly asking for blitting (done in SDL with SDL_UpdateRects).

#### Share this post

##### Share on other sites
hi,

i made tests with hw and sw surfaces and the result is unbeliveable. my software is better (fps) if i have sw surfaces only. try this.

msp1

#### Share this post

##### Share on other sites
Quote:
 Original post by Kylotan** vertical retrace ** ** vertical retrace ** ** vertical retrace ** It's a shame that what was common knowledge on these boards 4 or 5 years ago, is now not very well known.Flipping waits for the vertical retrace. This means it's synchronised to your monitor's refresh rate, or some even division of it. You can't break that barrier without getting rid of flipping and using blitting instead, which is usually achieved by either moving to windowed mode or explicitly asking for blitting (done in SDL with SDL_UpdateRects).

Yes, but isn't this refresh rate supposed to be at least 60Herz or something like that? As the OP reported FPS of 30... Or does that make me sound silly?

#### Share this post

##### Share on other sites
Quote:
 Original post by msp1hi,i made tests with hw and sw surfaces and the result is unbeliveable. my software is better (fps) if i have sw surfaces only. try this.msp1

Its well known by people who use SDL that depending on what you are doing software is faster. For SDL, any pixel manipulations or alpha blending( which can be thought of as pixel manipulations ) are best done in software.

Sometimes having a stray surface in system memory or in graphics memory where all other surfaces are in the other type of memory can slow your program down, as the blitting between these is really slow.

These 3 articles are quite illuminating as to different parts of SDL, and IIRC some of these points are dicussed.

#### Share this post

##### Share on other sites
Quote:
 Original post by DeadXorAliveYes, but isn't this refresh rate supposed to be at least 60Herz or something like that? As the OP reported FPS of 30... Or does that make me sound silly?

60 is a multiple of 30. If you're not quick enough to draw the whole frame at 60Hz, you'll end up waiting for every 2nd retrace, ie. 30Hz.

#### Share this post

##### Share on other sites
Quote:
Original post by Kylotan
Quote:
 Original post by DeadXorAliveYes, but isn't this refresh rate supposed to be at least 60Herz or something like that? As the OP reported FPS of 30... Or does that make me sound silly?

60 is a multiple of 30. If you're not quick enough to draw the whole frame at 60Hz, you'll end up waiting for every 2nd retrace, ie. 30Hz.

Very silly. Thanks.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

## Sign in

Already have an account? Sign in here.

Sign In Now

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627657
• Total Posts
2978472

• 10
• 12
• 22
• 13
• 33