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());
}
SDL Framerates and SDL_Flip()
Author
Well, I've been working on my SDL engine today. And I have noticed that even when I draw a single sprite like this:
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.
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
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
Quote:Original post by TFS_Waldo
Why 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!
Author
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! =)
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.
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.
** 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).
** 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).
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
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
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?
Quote:Original post by msp1
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
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.
Quote:Original post by DeadXorAlive
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?
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
