Page 1 of 1
Any reason not to do your logic in love.draw?
Posted: Sat Dec 06, 2014 5:44 pm
by natev
I've just been handling logic inside love.draw (well, in objects' methods that get called by love.draw), then spent some time browsing the wiki and discovered love.update. Both get called every frame-- is there a reason to separate these?
Am I doing something wrong? Is there some reason that love.update is a better place for certain kinds of logic?
Re: Any reason not to do your logic in love.draw?
Posted: Sat Dec 06, 2014 6:11 pm
by s-ol
natev wrote:I've just been handling logic inside love.draw (well, in objects' methods that get called by love.draw), then spent some time browsing the wiki and discovered love.update. Both get called every frame-- is there a reason to separate these?
Am I doing something wrong? Is there some reason that love.update is a better place for certain kinds of logic?
love.update( DT ) gets the delta time as a parameter. That means that you can make it framerate-independent. In theory love.update could get skipped for a frame or the other was around (though not with the default love.run) or even in parallel.
Re: Any reason not to do your logic in love.draw?
Posted: Sat Dec 06, 2014 7:30 pm
by Azhukar
Having modularized code where each module is responsible for its own thing helps with code maintenance. Having a section dedicated to game world updates and another dedicated to drawing keeps your code from becoming spaghetti of intertwined dependencies.
Re: Any reason not to do your logic in love.draw?
Posted: Mon Dec 08, 2014 12:00 am
by natev
Ah, thanks for the explanations.
Re: Any reason not to do your logic in love.draw?
Posted: Mon Dec 08, 2014 10:20 am
by T-Bone
It's not very difficult to get the deltatime in love.draw, if you want to (love.timer.getDelta()). So you can totally put all your game logic there and it will work. The reason most people separate it is because it's usually easier to code it that way (since drawing and updating game logic are quite different things).
Re: Any reason not to do your logic in love.draw?
Posted: Tue Dec 09, 2014 1:36 pm
by DaedalusYoung
Also, sometimes you want to update things in a different order than how you draw them. For example, a parallaxing background changes depending on player position, so you need to update the player first, then you can update the background. But you will want to draw the background first, and then the player.
Re: Any reason not to do your logic in love.draw?
Posted: Thu Dec 11, 2014 12:24 am
by natev
Well, I'm doing things with a queue of drawables, each with its own :draw function-- so my main looks like
Code: Select all
client:getInput()
client:output(game)
game:think(love.timer.getMicroTime())
for i =1, #client.drawQueue do
client.drawQueue[i]:draw()
end
Which seems like a fine way to do things organizationally, logic is still separate from drawing even if they're all run from love.draw.
It seems like I could even run logic and graphics at different framerates with
Code: Select all
repeat
client:getInput()
client:output(game)
now = love.timer.getMicroTime()
game:think(now)
until now >= desiredNextFrame
client:draw()
desiredNextFrame = now + (1/desiredFrameRate)
I was just wondering, because it seemed a little strange to have both functions, but I guess different people like to handle things in different fashions. Unless there's still something I'm missing?