As the subject says is there a way to flush the input of the pointer clicks etc, back in the BB days we had FlushMouse and FlushKeys this would clear the buffers between functions so that the new function could operate as if there were no clicks or inputs. These functions are good for mouse inputs between functions where the new screen is shown or when transitioning between mouse screens the new screen takes a click or clicks from the old screen.

GetPointerReleased to trigger something vs GetPointerPressed() (and their Raw counterparts) can help.

and, i miss MouseMoveX/Y (i think it was, in DBPro) while we do have GetRawMouseWheelDelta() in AGK.

otherwise, since AppGameKit is meant for multi-platform development (and mobile targets), there isn't a lot of Windows (or PC)-specific functionality built in (i assume that's why).

finally, if you're deving for Win only, i'm sure a dll containing all related functionality can be put together (by someone with more skill than me ).

hope that helps.

I think calling Sync() will do what you want. Input is read and stored during the Sync process.

This is for functions like get GetPointerPressed, GetRawMouseLeftPressed, etc which read the value since the last frame.

I think Virtual Nomad's answer is a good one

I would have preferred a function to flush the inputs on all platforms, I will have to make a makeshift one for now. Calling sync isn't a good solution for inputs as it does a screen flip, I was aiming for just clearing the buffers no user interaction at all.

Sync
Description
Updates the scene with the latest information, draws all sprites, updates global objects, and swaps the backbuffer into view.

i know we can manually Update, Render, Swap, et al, but "latest information" sounds like more of Sync() could/should be exposed like a ClearInputBuffer() command? that might make a popular Request on the Repo if you're up for it.

small tangent:

working with another user recently and i suggested that they only call GetPointerX/Y()/etc early and once per loop (where values can change throughout the loop), record the inputs and use the variables throughout the remainder of the loop; this goes back to advice posted when i was coding with DBPro.

when he did (in his rather large project), it (using the stored variable vs multiple direct calls) caused a sizable (& unexpected) performance hit

What I did was simply have a repeat look with just a sync call, I did try the loop without the sync but it never updates.



Maybe a input update without the backbuffer flip would be a nice addition so we can refresh inputs without updating what the user sees.