Framerates in SDL

Discussion in 'Game Development (Technical)' started by esrix, Jan 15, 2006.

  1. esrix

    Original Member

    Joined:
    Aug 11, 2005
    Messages:
    143
    Likes Received:
    0
    I've known for a while that, while SDL is considerably good at what it does, it has some speed issues with drawing to the screen at certain framerates even with fullscreen hardware acceleration enabled. And I know the trick that sometimes works to remedy this is the use of dirty rects.

    However, I'm also questioning the framerates that some people are aiming for. So far, I have one sprite moving around on the screen at about 30 FPS. I planned on optimizing as we were going to add more sprites so that we wouldn't have a performance issue. However, I discovered that many people are complaining about SDL running at only 40 FPS when they are coding for 60 FPS.

    So, my question is, if I'm running at 30, do I really need to implement a system that will make use of dirty rects?
     
  2. Ryan Clark

    Indie Author

    Joined:
    Oct 29, 2004
    Messages:
    656
    Likes Received:
    0
    Depends how much stuff you plan to have drawn to the screen each frame.

    Professor Fizzwizzle is 30fps (locked), 800x600, and runs at full speed even on a 200mhz machine. However, this is with dirty rects, and software surfaces. Without dirty rects your minimum system requirements will obviously increase.

    So, the question is, why not use dirty rects? I see no downside.
     
  3. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    Because dirty rects are loads more complicated :)

    Cas :)
     
  4. esrix

    Original Member

    Joined:
    Aug 11, 2005
    Messages:
    143
    Likes Received:
    0
    Is it that hard to implement dirty rects? I've only heard people mention them, not really talk about setting up the system.
     
  5. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    It's not really hard, but it's a pain, and at the end of the day it could be the case that it's a waste of time if you need to animate nearly all of the screen anyway.

    Cas :)
     
  6. mahlzeit

    Original Member

    Joined:
    Sep 26, 2004
    Messages:
    852
    Likes Received:
    0
    I don't know if this was the question, but if you're only getting 30fps blitting one sprite, you're probably doing something wrong.

    I was also under the impression that SDL's UpdateRects() function -- the one that takes an array of rectangles -- would collapse overlapping rectangles (so nothing would be copied twice), but the docs now say it doesn't. (Oh, and so does the source code.) Maybe that functionality was removed? (Or I remember wrong.)
     
  7. esrix

    Original Member

    Joined:
    Aug 11, 2005
    Messages:
    143
    Likes Received:
    0
    No, I'm not "getting" 30 FPS, I've purposely set the framerate to run at 30 FPS. I can actually set it to run faster if I wanted. 30 is what I'm aiming for (for the time being)
     
  8. Olofson

    Original Member

    Joined:
    Dec 11, 2005
    Messages:
    270
    Likes Received:
    0
    It was never there, AFAIK. The reason is that it'd just be a waste of cycles for applications that don't need it (not everything generates overlapping dirty rects), and when it's needed, it's hard to do it in a way that's efficient for any type of use. (Big difference between merging remove/redraw rects of slowly moving sprites, and partially overlapping sprites, for example.) Also, building it right into SDL_UpdateRects() would mean it's of no use with double buffered displays, unless you somehow build the "double dirty rect set" logic in as well.

    Anyway, I figured "pig" over here (Fixed Rate Pig; the second from the top) might be of some help...
     
  9. Ande

    Original Member

    Joined:
    Oct 10, 2005
    Messages:
    6
    Likes Received:
    0
    One big problem with SDL is that it can't do alpha blending with hardware in Windows. So, if you are alpha-blending surfaces to a hardware surface (as the screen often is in full screen mode), things will get really slow. This is something I really wish they would fix in SDL but the standard answer is always that you should have used OpenGL.
     
  10. karlb

    Original Member

    Joined:
    Jan 6, 2005
    Messages:
    7
    Likes Received:
    0
    You can force SDL to use software surfaces, which isn't very fast, but fast enough for many types of games. I'm using alpha-blending in all of my SDL games (http://www.linux-games.com), and I didn't get complaints about performance so far.
     
  11. mahlzeit

    Original Member

    Joined:
    Sep 26, 2004
    Messages:
    852
    Likes Received:
    0
    Yes it can. Works fine on one of my computers, not on the other. So it depends on the hardware/drivers. I doubt this is any different with DirectDraw.
     
  12. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    If SDL is using DirectDraw under the hood, that's why. DirectDraw can only do masking - no blending. If they switched that up to Direct3D with an orthographic projection they could easily add all kinds of cool effects but I guess it's not a priority.

    I'm using SDL with the Tao OpenGL wrapper and it seems to be working really well.
     
  13. Olofson

    Original Member

    Joined:
    Dec 11, 2005
    Messages:
    270
    Likes Received:
    0
    Exactly. Problem is implementing the SDL API over a 3D API is rather different from what the other SDL backends are doing. The SDL design is based on dedicated 2D APIs, and is biased towards supporting "old school" software rendering, and that doesn't mix too well with the way 3D accelerators and APIs operate.

    The good news is, most of that stuff has already been figured out and implemented: the glSDL backend. It started out as a compile-in wrapper that I did because I wasn't happy with software rendering only on Linux.

    Bad news is, glSDL is (as the name implies) using OpenGL for the rendering. (Simply because OpenGL is the only portable solution, and I use Linux 99% of the time.) Anyone else feel like porting glSDL to Direct3D? ;)


    Anyway, the problem with using the SDL 2D API over a 3D API is that, apart from the SDL API being far from a perfect fit, the whole deal buys you nothing more than raw blit performance. No scaling, no rotations, no advanced blending, no sub-pixel accurate rendering. If you want that, you'll need 3D acceleration to run anyway - so you "should" be using OpenGL. Only problem is, there are Windoze boxen out there with crap drivers, and even some with video cards for which no OpenGL drivers exist.

    An OpenGL-over-Direct3D wrapper built into SDL/Win32, perhaps? Not a small project, and I have a feeling that there is little interest. Seems like most Win32-only people use Direct3D directly, most non-Windows and multiplatform people use OpenGL directly, and the few who care enough and have the resources implement engine backends for both. (I'm leaning towards the latter myself, because I'm pretty sure getting that right is a lot less work than implementing a full, correct and fast OpenGL-over-Direct3D wrapper.)
     
  14. Olofson

    Original Member

    Joined:
    Dec 11, 2005
    Messages:
    270
    Likes Received:
    0
    (The force... uh, Google is not with me tonight. :mad: )

    Any way the Tao OpenGL wrapper could be used with C (or C++) on Win32? (I'll just use OpenGL directly on other platforms - and on Windows, if the user so desires. However, on Win32, I want Direct3D by default, to avoid issues with broken or non-existing OpenGL drivers.)
     
  15. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    I believe so. I'm using it via C# (and SDL.Net) but I'm sure other wrappers exist.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer