LÖVE

I just had a suggestion for love2d to make input easier to manage
adding these functions would make life a lot easier and I think could speed up development time for people.

- Love.keyboard.isDownPrevious()
- Love.mouse.isDownPrevious()
- Love.joystick.isDownPrevious()
- Love.joystick.GetAxisPrevious()

- Love.keyboard.GetKeysDown()
- Love.keyboard.GetKeysDownPrevious()
- Love.mouse.GetButtonsDown()
- Love.mouse.GetButtonsDownPrevious()
- Love.joystick.GetButtonsDown()
- Love.joystick.GetButtonsDownPrevious()
- Love.joystick.GetAxesDown()
- Love.joystick.GetAxesDownPrevious()

not only this but you could make a input manager without a update function because you have access to all the inputs that is needed to check if something was just pressed, something is pressed, or something is released for example..
it also supports people making their own input managers because you don't have access to pressed and release functions directly but just the current and previous inputs.

also we can now easily check for if anything was pressed by just passing in the one of the new constant getting functions.

what do you guys think?

I don't understand how this would be usefull, just use a variable to stock the previous key and voila ?

My input library does exactly this, by a popular request. I'm convinced though that the framework itself doesn't need this functionality.

People usually should detect whether something was pressed or released at the current frame (if using the callbacks) or detect whether something is still held down (if using methods in update); Anything else can be implemented using your own code, by storing such state, and querying that state, giving the "classic" 4-state input model of "de-pressed", "pressed", "held", "released".

Or as raidho said, use a library that implements such a thing.

To me, all those function duplications scream bad news; what do the Previous functions return? The same as the regular ones?
So now i have to manually truth-table-combine both results into all 4 possibilities; Why not just return that state itself? And by then, again, you'd use a library.

you would still be able to implement a library you would just be able to do it easier.

the previous functions return the previous frames value.

if duplication is a problem then there could be a constant that you could pass that would edit the return value to the current frame or previous frame with the current frame being the default.

I think making input manager easier to make would be a good thing since they are already very complicated.

That's what libraries are for. The engine itself doens't need to be any more complicated than to do the bare minimum it's supposed to do.

What löve provides itself is already capable of making implementing such a -stateful- input system possible; hence, it's a perfect candidate for a library.

The values in the previous frame are not so useful, because several events (e.g. a key down and up) can occur within one frame.

Best to leave that up to a library, which knows what to do with them. If the programmer doesn't want to miss any single press, they would use the events rather than the isDown() functions.