Best practices and things you'd like changed about Love2D

[GVovkiv]

What if, there was some sort of priority system?
For example:
I need draw rectangle with specific color, but i already have modified colors

Code: Select all

love.graphics.setColor(1, 0.5, 1)
love.graphics.rectangle("fill", 200, 200, 100, 100)
--and now, i need to draw another, but with specific color, but keep graphics state from 1st line
--so, i should do something like
local r, g, b = love.graphics.getColor()
love.graphics.setColor(0.4, 1, 0.5)
love.graphics.rectangle("fill", 0, 0, 100, 100)
love.graphics.setColor(r, g, b)

But what if, in love there was something like:

Code: Select all

--some draw staff here
love.graphics.setColor(1, 0.5, 1)
love.graphics.rectangle("fill", 200, 200, 100, 100)
--and now, i need to draw something with specific parameters
-- color now - 1, 0.5, 1
love.graphics.rectangle("fill", 0, 0, 100, 100, {r, g, b, a, etc}) -- so, if draw function have it own parameter, then it will be temporarily overwrited by this exact draw call
--color still - 1, 0.5, 1
love.graphics.rectangle("fill", 200, 200, 100, 100)

What about that?

[pgimeno]

It becomes annoying though that whenever you draw something you have to reset all the global drawing state in case some previous function modified it. So every call to love.graphics.x() has to be preceded by love.graphics.setX(). It's even more verbose than additional parameters.

That's not how I write them. Instead, every time I change something from default, I take care of resetting it back to the expected default immediately after use. If changing several things, there's push/pop.

[milon]

I personally like the current way font & color are handled - it makes me structure my code better and be more intentional about graphical attributes. To expand on pgimeno's point a little, you can set your own defaults when you initialize your game (or state), but the theory is still the same: set attributes, draw the graphics, restore default attributes. It kinda goes back to the comments on the 1st page about love being more of a framework rather than an engine. You tell love what to do, and it'll do it. But it won't assume for you what should happen. (Unless the function has defaults specified.)

[ddabrahim]

love.load has no real purpose.

Hi all!
Just would like to add my 2 cents regarding the load callback method.
As my project grow in size and get more complex, I begin to notice that when launching the game takes a long time, falling objects for example supposed to collide with the ground and stop on collision, but instead just fall through the ground by the tame the screen is rendered. Restarting the game usually fixes the problem.

I am a complete beginner so it is possible I am missing something but I think it is an indication of that, falling objects begin to update before the ground objects being fully loaded and initialised.
In most frameworks, the load callback method supposed to help to avoid this problem by making sure everything is loaded and initialised before calling the update method.

So the load callback method is indeed a bit misleading in that sense it is not actually taking care of loading but instead of removing it I think maybe it should actually take care of loading for us before calling update?

Thanks.

[slime]

So the load callback method is indeed a bit misleading in that sense it is not actually taking care of loading but instead of removing it I think maybe it should actually take care of loading for us before calling update?

It probably is a bug in your code - in the default game loop (love.run), love.load is called before the first update, and it doesn't contribute to the first frame's timestep value.

[ddabrahim]

It probably is a bug in your code

I get this only when the game takes a long time to launch like 2 times out of 10, not sure why that is but I don't think it is my code because literally the only thing should happen is load -> move 1 pixel -> draw -> repeat until collide with ground then stop but it is skip at least 30 frames at times and objects are already positioned below the ground in the very first frame. If love.load should take care of this and prevent it from happening then maybe my antivirus interferes with the execution of Love, maybe the debugger in ZeroBrane.

[slime]

I linked the default game loop above so you can see how it works (or modify it to your liking) if you want to debug your issue more. Maybe you have some code that takes unexpectedly long inside one of the first frames after loading? There are a few ways to investigate that sort of issue.

[grump]

it is skip at least 30 frames at times and objects are already positioned below the ground in the very first frame

More investigation would be necessary to tell where that lag comes from, and when exactly it happens.

My advice is to clamp dt to a maximum value, so that hiccups in the frame rate can't mess things up:

Code: Select all

function love.update(dt)
    dt = math.min(1 / 30, dt) -- dt will never exceed 1/30 seconds
    ...

What is a good value depends on the project, your system requirements, and how sensitive the game is to large dt. Be aware that this makes the game run slow if the machine is not fast enough to run the game at at least 30 fps.

This also saves you from the gigantic dt that occurs on Windows when the player drags the game window around.

[ddabrahim]

Thank you both for the advice and the link. I'm going to look in to that and see if it helps

[togFox]

Is the above example a good reason to keep love.load()?