3 doesn't equal 3?

[MrGreen]

Code: Select all

love.keypressed = function(k,s)
  if s == 'up' then
    direction[1] = love.keyboard.isScancodeDown('down') and direction[1] or 1.0

Could you explain me these three lines again? What is k for and how is s changed? And direction[1] cannot be 3 or 2 values at once. What does that do then?

Apart from that, I find your explanation very great and I love it that it is so detailed. Thanks for spending this time explaining me all this.

And I made minor changes:

main.lua

(1.41 KiB) Downloaded 84 times

(You changed position[1] two times and with "up" you went down and vice versa)

[raidho36]

Could you explain me these three lines again?

It's a makeshift ternary operator:

Code: Select all

variable = condition and valueA or valueB

If condition resolves to true then valueA is set to the variable, otherwise - valueB. There are limitations to that, off the top of my head - valueA cannot resolve to false because it'll return valueB then. Generally I'd advise against using it, it constitutes but a trivial amount of syntax sugar and has inconsistent behavior (see above), use regular if-else construct instead.

[MrGreen]

Okay, thanks a lot.

[zorg]

As raidho says, usually a simple if-else is also fine, although in this case, it's perfectly viable since direction[1] or direction[2], in normal usage, can never not be a number, so it will always work consistently, and how i intended it.

As for k and s, the relevant wiki entry for love.keypressed explains, those are parameters that get filled when löve calls the function, similarly to how dt is passed in love.update by löve itself. k is for the representation of a key (called keyconstant on the wiki), while s represents the physical location of a key, based on the "standard" QWERTY keyboard (called scancode on the wiki, and elsewhere);

The difference is significant only if you realize that keyboards can differ from the "US-standard" QWERTY layout, e.g. i have a QWERTZ, french people may have AZERTY, and so on; If you press the 'Q' key on a QWERTY keyboard, both the keyconstant and scancode will be for the "q" letter, whereas if you press the 'Q' key on an AZERTY keyboard, the keyconstant will be "a", but the scancode will be "q".

If you're interested in how these callback functions get called, you can look at love.run on the wiki.

[raidho36]

I'd rather say, you should always use scancodes if you want to capture specific physical keys on the keyboard, as opposed to the letters printed on the keycaps (which is basically never, there's no reason it should exist much less be the default).

If you want input - always use scancodes.

If you want text - always use the "textinput" callback.

[pgimeno]

I'd rather say, you should always use scancodes if you want to capture specific physical keys on the keyboard, as opposed to the letters printed on the keycaps (which is basically never, there's no reason it should exist much less be the default).

I use it in Thrust II Reloaded for bindable keys, where the keys used are displayed. Without that, it would be too weird if e.g. a French user pressed Z and the key displayed was W.

[raidho36]

I use it in Thrust II Reloaded for bindable keys, where the keys used are displayed. Without that, it would be too weird if e.g. a French user pressed Z and the key displayed was W.

Oh man I hate it when games do this. I have QWERTY layout printed on my keyboard as the main one - as does virtually every other dual language keyboard in existence - and it's the layout I think of whenever anyone refers to a specific key. It just causes confusion when the game tells me keys from my local layout; most games would display controls in QWERTY and for good reason, the few that don't are plainly misguided. Thankfully the last time I played one that did this was very very long time ago.

[zorg]

Now imagine if a keyboard manufacturer or just a random person made a keyboard where not only the layout was non-conformant to what we'd expect (think space cadet keyboard), but the key caps and mapping would also be different from QWERTY. Thankfully such things aren't anything to worry about in general.

[raidho36]

If someone were to make a keyboard where physical layout wasn't matching QWERTY, displaying keys in their "locale" wouldn't work either as this functionality works on top of assumed QWERTY physical layout.

Either way, again, most games don't do this for multiple reasons not the least of which being the global convention about it - that's how most people do it and that's what most people expect. Even if you feel like doing this, you should still include a QWERTY key; make your output a dual-language keycap sprite, with QWERTY key at top left and local key at bottom right.

[MrGreen]

As for k and s, the relevant wiki entry for love.keypressed explains, those are parameters that get filled when löve calls the function, similarly to how dt is passed in love.update by löve itself. k is for the representation of a key (called keyconstant on the wiki), while s represents the physical location of a key, based on the "standard" QWERTY keyboard (called scancode on the wiki, and elsewhere);

The difference is significant only if you realize that keyboards can differ from the "US-standard" QWERTY layout, e.g. i have a QWERTZ, french people may have AZERTY, and so on; If you press the 'Q' key on a QWERTY keyboard, both the keyconstant and scancode will be for the "q" letter, whereas if you press the 'Q' key on an AZERTY keyboard, the keyconstant will be "a", but the scancode will be "q".

Thank you all for your great explanation.