Hi! I’m trying to view all events in the event queue so I can remove events based on a few conditions. I’m trying to do this with SDL_PeepEvents. The problem is it expects the number of events I want to peep as it’s second parameter but I don’t know how many events are currently in the queue (I want all of them).
Since the size of events is only 1, that’s how big action should be. If you were to declare events as this instead: SDL_Event events;, you could have up to 20 events stored in it, so action should be 20, or (sizeof(events)/sizeof(SDL_Event)). Keep in mind that SDL_PEEKEVENT does NOT remove events from the queue, so your event handler will still have to go through them. And if you don’t use an event handler, you’ll only get the first events each time, so you’ll be going in circles if you don’t remove events somehow.
Thank you @Blerg and @Smiles. I think I figured it out. The whole point of me even doing the PeepEvents thing was to try and prioritize the movement events. Basically if you spam movement events (WASD spam) the character will spaz out even after you stop pressing buttons.
My idea was to check the event queue every “frame” and remove all movement events from the event queue except for the most recent one.
What I finally realized is that the real problem was that I’m handling only one event per frame which is not what I want. Since my game is running at 60 fps if you button mash quicker than 60fps then events will start becoming queued and thus being delayed.
I have changed it now so that it goes through ALL queued events (using SDL_PollEvent in a while loop) THEN it updates the velocity (as a result of all the events) and THEN finally render. Ta-da!!! Now it handles multiple events per render (or frame i guess you can say). SO now I don’t need to remove old move events, it will go through and calculate the velocity as a result of all the move events and then render the frame.
Thanks again for all the help I just had to wrap my mind around how all of this works lol.
I believe that all generated events fill up the queue, (all inputs, window changes, audio device changes, and the rest). So if you’re not deleting events from the queue, it will fill up and events will stop being created. Your program would just sit there and look unresponsive. It only takes ~20 seconds to do 10k mouse motion events, (constantly swirling the mouse around the screen), so 6.5 times that, (the event queue limit is 65535) would mean that you have roughly over 2 minutes of super intense gameplay before everything suddenly stops for the player; but the program continues as if nothing is wrong. I can’t verify that statement there. I have an event watcher which works even after the limit is reached. The code I posted earlier prevents user added events, but I don’t know about regular events currently. Might verify it later though.
Not sure if this is the same as what you’re doing or not, but I have my event handler simply update an array of keyboard states, then my program simply updates any movement values based on the state of the array. That way I can use: SDL_AddEventWatch to do all of the leg work. Just use switch/case statements for each event type you want to handle. Ohhh, and do keep everything as lean as possible in there, event watchers run EVERY time there’s an event, so it will slow down whichever thread is doing your video. Since my program only updates the array state, it always has the latest input when a game frame is processed.
Ohhh, and by the way, you still have to run SDL_PumpEvents or SDL_PollEvents to get events when using a watcher. Also of note the watchers do NOT remove events from the queue, so you’ll need a temporary SDL_Event, (create it outside of your loop to avoid constantly memory allocations that aren’t caught by the compiler), and use SDL_PollEvents(&tempevents); to simply remove them from the queue. Technically that part isn’t required per se; however as someone who like to run lean and mean, I prefer to do that so memory usage is kept as low as possible.
My framework is a wrapper around other libraries, so yes I could use it; I chose not to in case I wanted to remove SDL later on. It’s not optimized like I want it, but it works for now, and if I change libraries again, I won’t have to change any of my future programs, just my wrapper. I had a bunch of false/poor project starts that never went anywhere because there was always another library or engine I wanted to try, or I couldn’t get a library to compile, or lots of other reasons. I decided to go with a wrapper around all other libraries so that I don’t have to constantly change my programs if/when I want to change which libraries I’m using. I know that’s the reason why SDL exists in the first place, but it lacks a lot of features, (3D, networking, file decoding). It’s not supposed to have those either since SDL is supposed to just be simple. It’s also written in pure C, and that’s one of the bigger reasons I don’t use other libraries. People tend to over complicate things when using C++ in my opinion.
From what I could tell, there was only one call to SDL_PollEvent, so it was queuing the events up like it was supposed to, pulling a single event per frame, and making one update to the game state.
Yep, this is exactly what one should do: Handle all available events every frame so they don’t queue up, (most probably) in the order they arrive.
It’s very likely that you get more than one event in some frame just from keyboard and mouse (movement+clicks); if a joystick or gamecontroller is active you’ll likely get a lot more. Handling only one event per frame just doesn’t work reliably, even if it sometimes appear to work during development on your system.
You can always ignore (=> just not handle) events you don’t care about, and put events you want to handle a bit later (for whatever reason) into your own queue - though I think the latter should rarely be needed.