Re: Best practices and things you'd like changed about Love2D
Posted: Sat Jun 05, 2021 9:20 am
Okay, I see. Thnx for the info.
Y'know, these your "Edit: never mind"s really annoy me
Okay, I see. Thnx for the info.
Y'know, these your "Edit: never mind"s really annoy me
Code: Select all
local oldlevels = {}
local newlevels = {}
function love.keypressed(k, s)
newlevels[s] = true
end
function love.keyreleased(k, s)
newlevels[s] = false
end
local function justPressed(key)
return newlevels[key] and not oldlevels[key]
end
local function justReleased(key)
return oldlevels[key] and not newlevels[key]
end
function love.draw()
if justPressed("space") then
love.graphics.clear(255, 255, 255)
end
love.graphics.print("Press space to flash")
for k, v in pairs(newlevels) do
oldlevels[k] = v
end
end
Code: Select all
local edges = {}
local function justPressed(k)
local old = edges[k]
edges[k] = love.keyboard.isScancodeDown(k)
return edges[k] and not old
end
Okay, sorry, it's just that it pokes my curiosity and feels incomplete, plus you did it last time but didn't see when I asked you what you said. . I don't know, maybe you could put the edit at the bottom of the original post so people(read: me) knows what you're talking about. But your way is still okay, I guess.pgimeno wrote: ↑Sat Jun 05, 2021 11:06 am I posted an opinion but changed my mind. The forum doesn't allow deleting posts, so that's all I can do. It was about Xii's complaint about lack of edge detection for keys; I said it was no big deal, as I don't think it's a frequent use case, but then this whole thread is about opinions, so it felt out of place.
framestart and/or frameend events would be nice to have. Doing this stuff in love.update between input and output is often wrong, doing it at the end of love.draw feels dirty, and a custom love.run is not really an option for libraries.
+1. The best currently available workaround is to monkey-patch love.event.grump wrote: ↑Sat Jun 05, 2021 12:29 pm framestart and/or frameend events would be nice to have. Doing this stuff in love.update between input and output is often wrong, doing it at the end of love.draw feels dirty, and a custom love.run is not really an option for libraries.
A number of game state libraries people have posted here don't even care and switch between menu and game in love.update. One or two lines of code in the default love.run would make these things so much easier.
Code: Select all
local raisingEdges = {}
local fallingEdges = {}
function love.keypressed(k, s)
raisingEdges[s] = true
end
function love.keyreleased(k, s)
fallingEdges[s] = true
end
function justPressed(k)
return raisingEdges[k] or false
end
function love.draw()
...
for k in pairs(raisingEdges) do raisingEdges[k] = false end
for k in pairs(fallingEdges) do fallingEdges[k] = false end
end
Jumping in a platformer. Shooting in a shooter. Activating a special ability. Pressing undo. It's a very frequent use case to detect single key presses. And every dev has to write this boilerplate. It's not a big deal, it's simple and easy, but it's something we all have to write. Isn't the point of a library that we don't all need to implement the things we all universally need?
Those are all actions which are best handled via events (ie love.keypressed or keyreleased, in love's current API). Having code to check whether a key was pressed since the last time it was checked (i.e. the "wasPressed" approach) is subtly wrong because you will not detect things such as the user pressing and releasing a key twice in a frame. That may seem completely inconsequential at first but frame times are not predictable, and neither are user inputs. You're free to make that choice in your own game if you really want of course since love gives you the tools to do so, but I'd consider it bad design for a library or framework to promote that.Xii wrote: ↑Sat Jun 05, 2021 7:33 pm Jumping in a platformer. Shooting in a shooter. Activating a special ability. Pressing undo. It's a very frequent use case to detect single key presses. And every dev has to write this boilerplate. It's not a big deal, it's simple and easy, but it's something we all have to write. Isn't the point of a library that we don't all need to implement the things we all universally need?
I personally like Löves "do it yourself" approach, because something which may seem universally needed to you, might not be for others. I have never needed to write that boilerplate code which you talk about for example. I hope Löve focuses on staying a framework rather than trying to be an engine.Xii wrote: ↑Sat Jun 05, 2021 7:33 pmJumping in a platformer. Shooting in a shooter. Activating a special ability. Pressing undo. It's a very frequent use case to detect single key presses. And every dev has to write this boilerplate. It's not a big deal, it's simple and easy, but it's something we all have to write. Isn't the point of a library that we don't all need to implement the things we all universally need?