I have a pretty amped up gaming machine that doubles as my development box. It's a P4 3.0 gHz, with 1 gig of ram, and an ATI 9800XT 128 meg card. It runs things like UT2004 at 1280x1024 at ~65 fps. Doom3 - 800x600 with every video setting on high at ~40 fps or so. Quake III runs at 1600x1200 at over 100fps. So why do my tiny SDL programs, such as the pong clone I created yesterday, top out at ~50 fps? We're talking NO sprites here. I am using HW surfaces, and windowed mode, at 800x600. My drawing loop blanks the entire screen, draws every element, then flips. So it's not like I'm flipping every time I draw something, or blanking out each individual object. Plus, the compiled program gets ~90 fps on a friend's comparable machine. That still seems low for something so simple, but I'm more curious about why there's such a disparity between my framerate and his. I was just goofing around today with another test program that draws a box in white on screen, the blits an overlay image over it with SDL_SRCALPHA, and that made the framerate drop from around 50 to ~32 or so. I know alpha blits are slow, but cmon. We are talking about a card that can spit a ridiculous number of pixels. Even with an empty render loop, or one that JUST does SDL_FillRect(scr, NULL, SDL_MapRGB(scr->format, 0, 0, 0) ends up idling at ~50 fps. Any ideas?

By no sprites, do you mean you're not using any images/textures at all? If you are loading up and using any images, make sure you convert them to your video format. Otherwise it's known to create a huge bottle neck because it has to automatically do it every time you blit it.

If you're not though, I don't know what to tell you. Maybe try to use a SW surface instead and see if it changes anything?

I know this is obvious, but it can often be overlooked... take a good luck at your code, and make sure that the problem is really SDL and not some faulty algorithm.

Did you enable a back buffer?
Windowed mode is slower than full screen mode.
Are you properly clipping your blits?
Are you using a printf variation for debugging purposes?
Actually having images as surfaces and blitting them to the screen surface is faster than locking your screen and drawing the images pixel by pixel.

Cheers!

Tried a SW surface - no change. Yes, I am loading NO images or sprites.

I know of all the optimizations you both are referring to, but cmon. I am having trouble believing that a machine that can run Quake III at 1600x1200, high detail EVERYTHING at 100~fps can't run PONG at more than 50 fps.

I don't care if my renderer is a small Filipino boy with a notepad who writes 1s and 0s down before jogging over to dictate them into the video card.


That's why I'm thinking it's got to be something weird. The other strange thing is, it seems to be capped around 50 fps. I have a test bed I use to test sprite animations, and I can have 200 sprites bouncing around on there, and it will still give me ~50 fps.

SDL performance does leave much to be desired- it uses a very old version of DirectDraw, which wont take full advantage of your hardware setup. Keep toying with it, and you can get some acceptable performance.

Try using hardware surfaces in fullscreen mode, in my experience in windowed mode it makes no difference.

Alpha blits are unusably slow anyway, don't worry. There isn't much you can do about that, except:
-Using software surfaces can speed things up a little- reading from video memory is required in order to blend the pixels, which is slow. However, using software surfaces will give you a general decrease in speed everywhere else.
-Consider glSDL, a wrapper for the video part of SDL that uses OpenGL for drawing instead of the ancient directDraw SDL uses normally; I got a huge increase in performance with alpha blitting. Unfortunately the drawback of glSDL is blitting surface to surface is then terribly slow (which made it useless for me). It is also no longer maintained.

On the subject of a framerate cap, I think SDL does this when using doublebuffering and using SDL_Flip. I was able to circumvent this by making my own double buffer using a surface which I blitted everything to, drew to the screen, and called SDL_UpdateRect instead of flip.

This is all stuff I've deduced by observation so I'm not sure how accurate it is.

Check your video card's vsync setting. I'm not 100% certain, but it sounds like a vsync issue. SDL has no way to set the vsync directly; the only way to change is through the video card properties.

Also, try running in fullscreen and see what you get. Fullscreen is often much faster.

Fullscreen + hardware surface gave me maybe 10 more FPS.

I have it displaying high and low, and it ranges from 27 to 90, but the 90s are definitely few and far between, cause you can see the counter hovering right around 50-60.

When I have time this evening, I will try doing my own double buffering with SDL_FlipRects as was suggested.

Still seems odd to me, though.

jdhardy may have something there with the refresh rate - you're drivers should let you adjust the vsync - but it just doesn't sound like that's the problem. The part where you say it caps around 60 does, but then you say it goes even lower than that. So, it doesn't really make sense.

Weird problem you have... lol. I'd be pissed too if a machine like that was choking on something so trivial.

Quote:

Original post by Arkainium jdhardy may have something there with the refresh rate - you're drivers should let you adjust the vsync - but it just doesn't sound like that's the problem. The part where you say it caps around 60 does, but then you say it goes even lower than that. So, it doesn't really make sense. Weird problem you have... lol. I'd be pissed too if a machine like that was choking on something so trivial.

It's all over the place, too.

Sent it to my buddy to run on his work laptop, which is slightly lower specs than my laptop. I get ~85fps. He gets 250.

*shrug*

All I can suggest is posting your code so that we can have a peek. It does sound weird.

Post it all if you can; there can be bottlenecks in strange places.

You could also try running it with AMD's CodeAnalyst profiler. If it spends alot of time in hal.dll, then it's probably a vsync issue.