SDL Event Shenanigans

[RandomDever]

So I've used SDL for a while now and I always noticed a skippyness in my frame rate but only now realised what it is. It's not SDL's rendering function being slow it seems to be SDL event processing. When my game is running and all it's doing is looping through events and I go to town with the mouse scroll wheel the frame rate drops to around 20 or stops all together.

Here's the code:

Code: Select all

while(!quit)
{
    while(input.PollEvent())
    {
        if(input.IsType(SDL_QUIT))
        {
            quit = true;
        }
    }

        window.Clear();
        window.Draw();
}

PollEvent simply calls SDL_PollEvent on an SDL_Event.
Clear simply calls glClear(GL_COLOR_BUFFER_BIT).
And draw simply calls SDL_GL_SwapWindow on an SDL_Window.

Am I doing something wrong?
Any advice is greatly appreciated.

[dandymcgee]

I have no idea what "input.PollEvent()" or "input.IsType()" do. Mind showing us that code?

[RandomDever]

Code: Select all

bool InputManager::PollEvent()
{
    return SDL_PollEvent(&event);
}
bool InputManager::IsType(Uint32 type)
{
    return event.type == type;
}

[dandymcgee]

I'm still not sure what the problem is.

When my game is running and all it's doing is looping through events and I go to town with the mouse scroll wheel the frame rate drops to around 20 or stops all together.

What does "go to town with the mouse scroll wheel" mean?

And draw simply calls SDL_GL_SwapWindow on an SDL_Window.

Where are you actually rendering anything?

I need a much better description of what problem you're trying to fix, and what code is involved. It seems like you have a lot of fairly useless wrapper functions, which is fine except that I have no idea what any of them contain.

[RandomDever]

Going to town means rapidly scrolling up and down as fast as I can.
All drawing code was removed to pinpoint the problem so all it does now is clear and swap.
The problem I am trying to fix is the frame rate tanking like lead any time any input triggers an event.
The mouse wheel event is simply the most extreme example as it can cause 0 FPS. However it also happens to a lesser extent no matter what I do, including holding down a key.
As for the pointless wrappers... I have OCD or something so yeah.

[dandymcgee]

The mouse wheel event is simply the most extreme example as it can cause 0 FPS. However it also happens to a lesser extent no matter what I do, including holding down a key.

Well yeah, when you tell your program to infinitely loop doing nothing but processing events and you send it thousands of requests per second by mashing keys or scroll wheel what else do you expect?

To be honest this doesn't really sound like an issue since you're not doing anything else. If you were rendering something complex that required scrolling then you might be able to discard some of the extra scroll events, give rendering higher priority than handling input, etc., but these are all speculative until you have an actual application to test.

Easy solution: Buy a new computer. Realistic solution: Stop worrying about it until you have an real application. First make it work, then make it work right, then make it work fast.

[RandomDever]

The thing is I don't want to wait until my program is more complex to fix the problem.
But before posting here I had a simple movement test running where a little image would move around responding to user key presses.
But when holding down a key to move the image the frame rate kept slowing down and speeding up producing unsmooth movement. Also you mentioned discarding events and giving rendering higher priority.
I don't understand how you would do either of those.

[dandymcgee]

Have you implemented a frame rate limiter? If not, I suggest you try that. Contrary to what it may sound like, the primary purpose of frame rate limiting is to keep the frame rate consistent and smooth, not to make it slower.
http://lazyfoo.net/SDL_tutorials/lesson14/

[RandomDever]

No I had not implemented that but now that I have limited it to 60 frames per second it still exhibits the same behavior. Because a frame limiter can only prevent it from going too high but the problem here is whenever ANY input is received the frame rate goes down.

[qpHalcy0n]

Does it do this with all events? Or just mouse wheel events?

If you don't have access to a code profiler, try using SDL_GetKeyboardState or SDL_GetMouseState. Be sure you look this up because I think you have to pump the event queue before calling this. Does it change?

If it changes (for the better), then the event polling may be a blocking call and the buffer is just getting out of control. I'm not very familiar with SDL at all, but this is where I'd start.

[RandomDever]

It happens with seemingly all events.
One of the first things I tried before posting here was removing the SDL_PollEvent and just use SDL's keystates but the behavior is the same.

[qpHalcy0n]

In this event, be sure you call SDL_PumpEvents. This is a once per frame call as is the keyboard/mouse state query. In this case, SDL_PumpEvents would probably be the culprit. You may wrap the call around a timer (get the time and after the call) so that you can see exactly how long the call is taking.

If you're on windows, you can call GetAsyncKeyState to retrieve the keyboard status. You can use GetCursorPos to retrieve cursor position. There are other mouse functions for retrieving mouse state. If these functions fail to cause a backup then your bus should be clear so the problem likely lies in SDL itself or how you're using it.

X has similar functions.

[superLED]

You could either share your whole code so people could look at it and test out different solutions,
or maybe share the executable so we could see if it has something to do with your computer.

[RandomDever]

I removed the PollEvent and PumpEvent and used as you suggested GetAsyncKeyState to move my square around and it holds at a smooth 60 fps. However I am assuming this is windows specific and I would prefer a cross-platform solution. I believe PollEvent implicitly calls PumpEvents so that specific function is likely the problem. One thing I tried earlier was using SFML to see if it would fix this behavior and it seemed to do the same thing so I don't really know what could be causing this.

[dandymcgee]

I still recommend you post your exact code so others can use it for testing. Otherwise, we're guessing blind here. I did a bit of research and it seems others have experienced this problem in the past and determined it to have been an NVidia driver issue. For this reason, you may want to test it on a few different hardware setups and check the results.