/* -- 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( );
}
myimage = SDL_LoadBMP("test.bmp");
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]
SDL performance problems
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...
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]
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]
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.
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.
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.
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.
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]
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]
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.
http://olofson.net/mixed.html
On a small program I wrote, using that boosts the fps from about 40 to 460.
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?
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?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement