#### Archived

This topic is now archived and is closed to further replies.

# SDL performance problems

This topic is 5226 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I did a short test; I filled the screen with tiled bitmaps and then moved a second bitmap over that background. I initialized with SDL_HWSURFACE | SDL_DOUBLEBUF and used SDL_Flip to update after each redraw. On a 2.5Ghz PC with a built-in gfx card I got 120fps and a smoothly moving bitmap. On my gaming PC at 2.0Ghz and a GeForce 3-card I only got 35fps and the movement of the moving bitmap was far from smooth. Can anyone help me understand why? My only guess is that somehow the graphics acceleration doesn't kick in (but shouldn't I get errors on the HWSURFACE-initialization then?). A second question: the decrease in performance is quite big between different bit-depths (like 35fps in 32bpp and 70fps in 16bpp), should it really? At 640x480 on a 2Ghz machine?! A third, related question, the documentation at libsdl.org is pretty old, is there anywhere else one might find a more recent documentation? I hear they have a wiki, but I can't find a link to it. The ugly, procedural, test code (just cut-paste-and-compile if you have SDL installed (don't forget to change code generation to multi-threaded dll)) in case anyone wants to try it out. The test.bmp is 120x120...
/* -- Include the precompiled libraries -- */
#ifdef WIN32
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
#endif

#include <stdio.h>
#include "SDL.h"

// Global variables
SDL_Surface *screen;

// main()
int main(int argc, char **argv)
{
SDL_Surface	*myimage;
SDL_Rect	*mydest;

if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
{
fprintf( stderr, "Video initialization failed: %s\n",
SDL_GetError( ) );
SDL_Quit( );
}

screen = SDL_SetVideoMode(640, 480, 16, SDL_HWSURFACE | SDL_DOUBLEBUF);
if ( screen == NULL ) {
fprintf(stderr, "Couldn't set 640x480x16 video mode: %s\n",
SDL_GetError());
SDL_Quit( );
}

int x,y,count;
mydest->h = 120;
mydest->w = 120;

for(count=0;count<100;count++)
{
for(y=0;y<4;y++)
{
mydest->y = 120*y;

for(x=0;x<6;x++)
{
mydest->x = 120*x;
SDL_BlitSurface(myimage, NULL, screen, mydest);
}
}

mydest->x = count*5;
mydest->y = count*5;
SDL_BlitSurface(myimage, NULL, screen, mydest);

SDL_Flip(screen);
}

printf("Active for %.2f seconds at %.2f fps.\n", ((float) SDL_GetTicks()/1000), (100/((float) SDL_GetTicks()/1000)));

SDL_Quit( );

return 0;
}
// end main()       
[edited by - Xipe on June 3, 2004 3:20:34 PM]

##### Share on other sites
Forgot to mention: I am currently compiling and running it under Windows. Haven't everything set up on Linux yet, but since I'm aiming for a cross-platform game I'm a bit concerned over the performance.

I read somewhere that SDL looks for the DirectX-libs at compile time, so I added them and got a 15fps boost (from 35 to 50). But that's still pretty slow IMHO when working in 640x480 -- on a 2Ghz machine with GeForce3 I would expect at least 150-200 fps even with the ugly and unoptimized code above... And the same kind of test code ran at 80fps under DirectX on my old Celeron 300Mhz with a GeForce TNT card a few years ago.

[edited by - Xipe on June 3, 2004 9:34:47 AM]

##### Share on other sites
What i noticed when working with SDL:

Always, always, always convert the SDL_Surfaces to the screen depth (there''s a function for that one, SDL_DisplayFormat). AFAIK if the depths do not match your performance goes down due to SW blitting.

##### Share on other sites
Most problems with slow SDL speed can be "solved" by initializing your ScreenSurface with the SDL_ANYFORMAT flag set.
I *think* this allows SDL to pick a colordepth different from the one you specified if this allows the use HW acceleration.
The usual problem here is that you try to create a SDL surface with a colordepth different from your desktops colordepth.

If you still don''t get more than 70 or 80 fps check if your number of frames matches your monitors refresh rate. Now to bypass this you have to turn off vsync somehow. This should show you higher framerates, but it will/might also introduce image tearing artifacts. Actually your method for measuring the framerate looks "interesting" too, but as I have no clue what SDL_GetTicks() actually does, if this could be a problem.

Now, all this is more an uninformed guess than anything else, cause I have never worked with SDL.

##### Share on other sites
Thank you for the suggestions and help!

SDL_DisplayFormat() upped the performance on the same bitdepth as the desktop, and SDL_ANYFORMAT made that performance increase available at all other bitdepths.

I'm still not all that impressed, but I guess it's good enough to start working with.

640x480 - 130 fps
800x600 - 85 fps
1024x768 - 53 fps
1280x1024 - 40 fps

As for the fps; yes, I guess how I arrive at the fps is interesting . SDL_GetTicks() returns the number of milliseconds since SDL got initialized at application start, so there's probably an overhead there on (at the most) a few hundred milliseconds; but not so much that I should be concerned with overly faulty values.

It's not 100% smooth movement at 800x600 and higher resolutions though, so I'm gonna try to figure that one out next.

[edited by - Xipe on June 3, 2004 3:20:09 PM]

##### Share on other sites
SDL''s 2D blitting performance is currently known to be a bit on the slow side, but an OpenGL backend is currently under development for it. In the meantime, check out this OpenGL wrapper:
http://olofson.net/mixed.html
On a small program I wrote, using that boosts the fps from about 40 to 460.

##### Share on other sites
Or ... just use OpenGL?

I use SDL for all my windowing/keypress/whatever stuff EXCEPT drawing... it''s not like making opengl do 2D stuff is hard, now is it?

1. 1
2. 2
3. 3
Rutin
16
4. 4
5. 5

• 10
• 11
• 14
• 10
• 25
• ### Forum Statistics

• Total Topics
632649
• Total Posts
3007644
• ### Who's Online (See full list)

There are no registered users currently online

×