When does love.keypressed actually run?

[parallax7d]

Lets say the player presses a key in the middle of the part of the game loop where love.update is running

Does the function defined in love.keypressed trigger right there and then, essentially 'interrupting' love.update?

Or is it queued up and run during the next tick during the love.event part of love.run? Or something else? I'm confused.

[slime]

Or is it queued up and run during the next tick during the love.event part of love.run? Or something else? I'm confused.

Yep. All input / system events are processed at the beginning of every frame, before love.update is executed.
The love.event.pump() call in [wiki]love.run[/wiki] adds the events to LÖVE's event queue, and then the love.event.poll() call processes each pending event, and sends it to the love handlers (which call love.keypressed, love.mousepressed, etc. based on the event.)

[parallax7d]

What would happen while a user enters text into a text box? Would love.keypressed trigger for each letter typed?

[Robin]

Yes, and for any other keys you press. Have you tried it out. (Also, for a text box, you'd probably want to use [wiki]love.textinput[/wiki] for the actual text input.)

[parallax7d]

Lets say the game loop is in the middle of love.update and the user presses 'a'. Does keypressed actually capture 'a' at that point - or does it simply add an event for the next tick to capture any keyboard input if a key happens to still be pressed during the actual execution of keypressed?

If it does capture 'a' immediately, is it possible for it to capture other info? Like the id of the entity that's currently selected? Or can that sort of info only be captured when keypressed is actually run the next tick?

I'm just thinking about user input being missed, or a key's action being applied to the wrong entity, if there is some sort of delay between user input and execution.

[Robin]

Lets say the game loop is in the middle of love.update and the user presses 'a'. Does keypressed actually capture 'a' at that point - or does it simply add an event for the next tick to capture any keyboard input if a key happens to still be pressed during the actual execution of keypressed?

The latter.

I'm just thinking about user input being missed, or a key's action being applied to the wrong entity, if there is some sort of delay between user input and execution.

The first is not a problem, as user input is queued up. The second problem is unlikely, since with a moderate framerate, each tick only lasts a fraction of a second, so it won't have a noticable delay.

Note that this is how pretty much all GUI systems work, as far as I'm aware: the whole event queue comes pretty much directly from the operating system, so if other programs are fast enough for this kind of stuff, your game will be too.

[bartbes]

I'm just thinking about user input being missed, or a key's action being applied to the wrong entity, if there is some sort of delay between user input and execution.

How would the other entity be selected? Would that not also use an input event?

[parallax7d]

Mouse clicks and key presses can be very quick, especially while typing or double clicking;

loop n
during love.update, user presses 'x'
event knows something happened
during love.draw, user lets go of 'x'
loop n+1
event triggers, captures whatever key is currently pressed (none) -- the user's input is essentially lost

Edit: ignore this second part - I get what bartbes was saying
As far as a command going to the wrong entity;

loop n
user clicks on entity1
loop n+1
during love.update, user presses 'x'
event knows something happened
user selects entity2 with mouse
loop n+2
keypressed is triggered, grabs whatever key is currently pressed (still 'x'), applies that action to the current entity (entity2)

Perhaps it would make more sense to apply the current triggered input action onto the last entity selected, if the currently selected entity changed last frame? The edge case bugs that would cause is making me

Either I'm not getting how this works, or I'm being overly paranoid. It's just that it realllly annoys me when playing a game and the keypress is lost. I remember in AOE2 rapidly trying to delete walls, and half your delete key presses would get lost! I want to do everything I can to avoid that sort of thing, even if it only applies to 1 in 1,000 inputs.

[s-ol]

Either I'm not getting how this works, or I'm being overly paranoid.

both.

Whenever the user does something, an event is sent into the queue. At the start of every loop, the whole queue is applied to the callbacks in order; That means as far as love.keypressed and love.mouseclicked are concerned, you can pretend the events are completely real-time, you cannot select entity A, hit delete and select entity B before A gets deleted and mess up the input.

The only thing that could happen is your deletion happening in love.update. love.update and love.keyboard.isDown always query the current state, that means what happened in this frame's input. This means that if the use somehow manages to press E and R in the same frame, there is no way of telling which came first from within love.update alone.

I just ran a quick test and when I type as fast as I absolutely can there are still a minimum of 5 frames between letters (for hello). I can't manage to type the same key twice in under 7 frames.

[parallax7d]

Whenever the user does something, an event is sent into the queue. At the start of every loop, the whole queue is applied to the callbacks in order; That means as far as love.keypressed and love.mouseclicked are concerned, you can pretend the events are completely real-time, you cannot select entity A, hit delete and select entity B before A gets deleted and mess up the input.

cool, I got that now, thanks for elaborating

I just ran a quick test and when I type as fast as I absolutely can there are still a minimum of 5 frames between letters (for hello). I can't manage to type the same key twice in under 7 frames.

Well, that depends on the time between frames

But yeah, I guess maybe I am being too paranoid about lost input.

I figure the fastest APM in the world is 818 = 13.6 actions per second. I guess as long as the fps of the game stay above double that, the chances for a lost command are tiny. It's just so annoying when it does happen!