## Any reason not to do your logic in love.draw?

General discussion about LÖVE, Lua, game development, puns, and unicorns.
natev
Prole
Posts: 14
Joined: Thu Nov 20, 2014 3:55 pm

### Any reason not to do your logic in love.draw?

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?

s-ol
Party member
Posts: 1077
Joined: Mon Sep 15, 2014 7:41 pm
Location: Cologne, Germany
Contact:

### Re: Any reason not to do your logic in love.draw?

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.

s-ol.nu /blog  -  p.s-ol.be /st8.lua  -  g.s-ol.be /gtglg /curcur

Code: Select all

print( type(love) )
if false then
baby:hurt(me)
end

Azhukar
Party member
Posts: 478
Joined: Fri Oct 26, 2012 11:54 am

### Re: Any reason not to do your logic in love.draw?

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.

natev
Prole
Posts: 14
Joined: Thu Nov 20, 2014 3:55 pm

### Re: Any reason not to do your logic in love.draw?

Ah, thanks for the explanations.

T-Bone
Inner party member
Posts: 1492
Joined: Thu Jun 09, 2011 9:03 am

### Re: Any reason not to do your logic in love.draw?

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).

DaedalusYoung
Party member
Posts: 402
Joined: Sun Jul 14, 2013 8:04 pm

### Re: Any reason not to do your logic in love.draw?

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.

natev
Prole
Posts: 14
Joined: Thu Nov 20, 2014 3:55 pm

### Re: Any reason not to do your logic in love.draw?

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?

### Who is online

Users browsing this forum: No registered users and 9 guests