LÖVE

Zorbatron wrote:

bartbes wrote:This is a matter of personal style, and one could argue that saving every pressed character presents other overhead, which might outweigh the overhead created by using love.keyboard.isDown. Furthermore, on most modern computers resources are not that limited that it really matters.

Once again, despite my tone, I mean no offense.

I'm going by what I learn from websites, personal tests, and concrete evidence, not my opinion.

Source: http://lua-users.org/lists/lua-l/2004-04/msg00164.html (scroll to the section "Binding Lua to C++")

Source wrote: Avoid using Lua in "every frame" actions as performance drops
dramatically. For example, don't use Lua to do animation updates; set
up parameters for the animation in Lua and do the updates in C/C++
code.

Just want you to realise alot of this stuff isn't my opinion as much as it is the opinions of people who've done alot of research.

Your link is in the context of lua when bound to C++, not the context of a C++ engine wrapped with lua (the way LOVE functions).

How do you propose I check if a key continues to be held down after it is pressed? Save a list of each key with a pressedDown boolean that I flip on keypressed and keyreleased? I didn't make LOVE but I'm pretty sure if you ask one of the guys who did, they'd say that that's more overhead than isDown since isDown is likely just referencing a constantly updated list to see if a key is down.

Zorbatron wrote:I'm going by what I learn from websites, personal tests, and concrete evidence, not my opinion.

Just want you to realise alot of this stuff isn't my opinion as much as it is the opinions of people who've done alot of research.

1) I was taught to not believe everything you read, this is magnified 100x with the interwebs
2) I would be interested in seeing your test's
3) I would be interested in seeing concrete evidence that actually have to do with the subject at hand, not in its opposite form

I don't think checking for keypresses in update() has any big performance impact, at least not in any game I've seen. And my computer is pretty old, so I'm usually among the first to notice performance problems.

The general consensus on the method to use to monitor input seems to be: it depends on the situation. Both the poll and the thread show this, and I agree. (Not that my opinion is that important )

bartbes wrote:The piece you quoted doesn't have anything to do with this particular situation.

It has everything to do with this situation. You're comparing a method where you are doing a lua loop every update (roughly every frame, not quite but close), with a method that is called from C/C++. The callback is only called when a key is pressed/released, which is all you need.

TacticalPenguin wrote: Your link is in the context of lua when bound to C++, not the context of a C++ engine wrapped with lua (the way LOVE functions).

What? This is a general rule of thumb with any system where C/C++ and lua interface with each other. It applies in all instances where lua is used with C/C++.

TacticalPenguin wrote: How do you propose I check if a key continues to be held down after it is pressed? Save a list of each key with a pressedDown boolean that I flip on keypressed and keyreleased? I didn't make LOVE but I'm pretty sure if you ask one of the guys who did, they'd say that that's more overhead than isDown since isDown is likely just referencing a constantly updated list to see if a key is down.

No it would actually be less overhead, keystate[keycode] = true/false. You'd be calling a function every frame in a loop with the isDown, where with the released/pressed callbacks you'd only be accessing a table when the key was called. It's more efficient, I've tested this a long time ago.

Robin wrote:I don't think checking for keypresses in update() has any big performance impact, at least not in any game I've seen. And my computer is pretty old, so I'm usually among the first to notice performance problems.

It's not a noticable performance drop, you won't notice 1-2 ms drop, but why do it the wrong way just because you can't notice it? If you keep coding poorly, you're bench marks will be much lower than if your code was built properly.

osgeld wrote: 1) I was taught to not believe everything you read, this is magnified 100x with the interwebs
2) I would be interested in seeing your test's
3) I would be interested in seeing concrete evidence that actually have to do with the subject at hand, not in its opposite form

1) I quoted it from the lua.org website, it was the results of a real meeting, with real professionals, its a trustable source, if it wasn't it would probably have been removed.
2) I could do tests if you want, but I really don't think I should be wasting my time proving something that seems sort of obvious.
3) I don't get what you mean, I provided a quote and a source that prove what I just said. There's really no room for misinterpretation here...

I 'm with Zorbatron. There's no need to have checks in update loop. Every time there's a keypressed , keyreleased event, I store it into a table, so I can tell exactly which keys are down and which keys are up. This makes checking inside the update loop redundant. Using only keypressed, keyreleased is more elegant than using both, IMO. Although I had to use the update loop to implement key repeats, that won't be necessary next version.

I'd like to see the performance discussion quelled, as I don't think it's a meaningful debate in this case. If you're using isDown, you're doing a lookup to determine the state of a particular key within the keyboard as a whole. If you store the state in a Lua table and referencing that index in place of isDown, you're still doing a lookup. Neither one performs deterministically and noticeably better, so the debate won't get us closer to making an informed decision.

That being said, I think both are useful. Also, both are clear. If I'm using keypressed, I want to intercept the actual event that indicates the FIRE key was pressed, for example. I change the state of the game to denote the fact that the user wants to fire now, and move on. However, if I'm in my update code and want to calculate the player's movement, I can use isDown in my movement calculations to clearly indicate the key states that cause player movement. Since the table I would create in Lua is already available on the backend, I see no reason to replicate it. And it won't make my code any more legible, it will just change the nomenclature. Which can, truth be told, make code more legible. But I don't think to an appreciable degree.

I only mean this to inform, not ridicule. I apologize if my overly-academic tone comes across improperly.

Hmm... you make some sense. I thought table lookups were cheaper than a lua function call, and it's more pretty if everything was done in the same way.