Ah, SDL, you've done it again.

[N36fSL3A]

I guess SDL and I have a shifting relationship... Well, this time the problem between us is CPU usage. I added a SDL_Delay(x); to my code during my drawing time in my main game loop, but my frame rate is still low.

You see, I'm making a zombie game, and now it got so big that blitting images to the screen takes up more CPU usage than necessary. Now, I need a more "Heavey Duty" version of frame rate control than before.

Thanks for help in advance. If you need any source code from a particular area in my game, I'll be happy to show you.

[N36fSL3A]

I seriously need help, I want to release a tech demo by tomorrow.

[cire]

I guess SDL and I have a shifting relationship... Well, this time the problem between us is CPU usage. I added a SDL_Delay(x); to my code during my drawing time in my main game loop, but my frame rate is still low.

This doesn't make a whole lot of sense. You told SDL to take give up a little cpu time to the operating system, and are surprised that the program using less cpu time didn't result in faster frame rates? That's a lot like stopping at a rest stop on the highway and wandering why you aren't getting to your destination faster.

[N36fSL3A]

You're not getting it. My program freezes completely. I think this is due to the Operating system not having enough time to update essential programs that are always running. This is why I want to give the operating system some time, hoping that I can actually have a playable game by tomorrow, I have to show my partner my progress.

[cire]

You're not getting it. My program freezes completely. I think this is due to the Operating system not having enough time to update essential programs that are always running.

I don't think it's me that isn't getting it. If you reduce the amount of time devoted to your program, less time will be spent executing your program. That is the only metric you're affecting with SDL_Delay.

[Scorpic]

Most modern day operating systems use a variation of a round robin approach when it comes to servicing processes. Which very simply means even if you're process isn't giving anything back to the CPU (no delays) the operating system will still context switch between all of the processes in execution.

So it doesn't have anything to do with the OS not having time to update essential programs. Maybe your Delay is too much causing major fps issues or if you are multithreading it could be messing up some synchronization.

[Disch]

My program freezes completely. I think this is due to the Operating system not having enough time to update essential programs that are always running.

That's not what's happening. If your program isn't getting CPU time, doing a Delay wouldn't help anyway because your program would not be running so the OS doesn't know it wants to delay. But you are getting CPU time. Check task manager and look at it. If you aren't doing any delays you will be using 100% (or close to it).

If your program is truly freezing (as in deadlock), then you're either caught in an infinite loop (extremely likely) or you are botching a multithreaded task and two or more threads are stuck waiting for each other.

If it's the former, it's very easy to debug. Just reproduce the deadlock, then go in your debugger and force it to break. It'll put you on the currently executing line, then just look for whatever loop that code is running in to see why it's deadlocking.

Well, this time the problem between us is CPU usage.

In my experience, SDL's performance sucks. It's the main reason I stopped using it. I had trouble maintaining 60 FPS on a tiny 320x240 display on my old 1 GHz machine (this was maybe 8-9 years ago I think... 1 GHz wasn't top of the line but it wasn't garbage yet).

I find that SDL tends to do it's rendering in software, which is painful. It might do it that way because the drawing methods it uses are so archaic and outdated (blitting? dirty rects? This isn't 1996 any more). But that's purely speculation on my part.

I need a more "Heavey Duty" version of frame rate control than before.

I have an excellent framerate regulator that does a great job at keeping the framerate steady. I wrote it for my NES emulator a while back.

You can find it here:

http://forums.nesdev.com/viewtopic.php?p=57398#p57398

(please forgive my use of Hungarian Notation. I was young).

I'm happy to answer questions about it, but that post should explain it pretty well.


(EDIT: corrected link. I gave the link to the Sound Sync version, not the clock version)

[N36fSL3A]

SDL only does drawing in software if you set it to. Never do it.

Thanks anyway, but do you know of a page that shows the use of a system like this? Just an example please.

[naraku9333]

AFAIK SDL only does hardware rendering in version 2, though I believe I read something that suggested if you use opengl calls directly it will hardware render.

[Disch]

Fredbill30 wrote:

SDL only does drawing in software if you set it to. Never do it.

Even if you specify hardware, I don't think it'll do it hardware because modern hardware doesn't work that way. Modern hardware is all about rendering textured quads, not about blitting.

but do you know of a page that shows the use of a system like this? Just an example please.

The timing thing? There's an example in that link.

naraku9333 wrote:

AFAIK SDL only does hardware rendering in version 2

I've heard a lot about SDL 2 but have yet to see any sign of it. The official SDL page still doesn't mention anything later than 1.2.

Even looking at the forums, I see a post for "SDL 1.2.15 RELEASED!", but nothing for SDL 2.

Does it even exist?

though I believe I read something that suggested if you use opengl calls directly it will hardware render.

That's the only way you can feasibly use SDL. Using SDL's rendering simply is not an option, IMO. But at that point it becomes little more than window creation code... and offers little benefit over something like glu.

Nevermind that addon libs like SDL_ttf, SDL_image, etc all work with SDL surfaces, which makes it awkward to use them unless you're doing SDL rendering.


Blah blah blah. My list of complaints with SDL goes on. I'll just say it used to be great but it did not keep up with the times, now it's crap.

[S6k9GNh0]

Actually, the main download page does link to SDL2. SDL2 is all that's in development, is in various indie cross-platform games (specifically those helped by Ryan Gordon) and the wiki defaults to the SDL2 API. If you can't find it, you're blind.

[Disch]

Do I have the wrong page?

http://www.libsdl.org/download-1.2.php

That's the download site.

And nowhere on the main page does it say anything about SDL2.

http://www.libsdl.org


And you're right the wiki does mention SDL 2, but I still don't see a download link.

[naraku9333]

It's under SDL HG http://www.libsdl.org/hg.php

[S6k9GNh0]

SDL2 has no official releases yet because the implementation still isn't complete.

Why they set the standards so high and decided to have a 4+ year long release date is beyond me.

[Disch]

Ah. Thank you, naraku.

[N36fSL3A]

How can I implement the FPS thing? I need my program to respond again...

[Disch]

How can I implement the FPS thing?

The code is all outlined in that thread I linked to. It also gives a simple usage example.

I guess I can rephrase it to apply more to what you're doing...

/*
    you need a 'doframe' function with an optional 'draw' parameter.
    This is where you will put all your game code.
*/
void doFrame(bool draw)
{
  ProcessUserInputAndDoLogicUpdatesHere();

  if(draw)
    DrawTheScreenAndDisplayItHere();
}

/*
    then to regulate the framerate, you need some variables.  I'm making these global for
    simplicity of this example, but a better approach would be to put all of this in a class.
*/

// timestamp that next frame is to occur
Uint32 nextFrame;

// the number of frames we have skipped
int framesSkipped;

// configurable (optionally const) value to determine how many frames we allow it to
//   "fall behind" before we give up and resync.
// higher values = game opts to run 'slower'
// lower values = game opts to run 'choppier'
int maxFrameSkip = 5;

// configurable (optionally const) value to determine when to start "skipping" frames.
//   IE, we'll start skipping after we fall this many frames behind
int skipFramesBehind = 5;

// number of milliseconds between frames.  17 gives you approx 60 FPS  (1000 / 60)
int frameLength = 17;


/*
    We also need a function to "resync".  This should be called once to initialize the timing
    mechanism.  And also called again whenever something happens that throws the
    clock way out of whack (such as the user entering a menu or something).  This probably
    does not apply to SDL much so you probably will only need to call this on initialization.
*/

void resyncFrameTime()
{
    nextFrame = SDL_GetTicks();
    framesSkipped = 0;
}


/*
    Now the actual function to regulate the framerate
    I'm going to use
*/

void regulateFrameRate()
{
    // get time between next frame and now
    Sint32 dif = (Sint32)(SDL_GetTicks() - nextFrame);

    // if it's not yet time for the next frame... wait and sleep for a bit
    if(dif < 0)
    {
        SDL_Delay(1);
        return;
    }

    // otherwise, we're going to do at least 1 frame.  increment our time counter
    nextFrame += frameLength;

    // if we have fallen too far behind.. we need to start skipping frames to catch up
    if(dif >= (frameLength * skipFramesBehind))
    {
        // if we have already skipped the maximum number of times.  "Give up" and just resync
        if(framesSkipped >= maxFrameSkip)
            resyncFrameTime();
        else
        {
            // otherwise, skip this frame
            ++framesSkipped;
            doFrame(false);    // by "skip", I mean "run logic, but don't draw".
            return;
        }
    }

    // otherwise, we just do a "normal" frame
    framesSkipped = 0;
    doFrame(true);  // do the frame, and draw it
}



/*
    Now for intended usage:
*/

int main()
{
    while( your_game_is_running )
    {
        regulateFrameRate();
    }
}