Best practices and things you'd like changed about Love2D

General discussion about LÖVE, Lua, game development, puns, and unicorns.
MrFariator
Party member
Posts: 509
Joined: Wed Oct 05, 2016 11:53 am

Re: Best practices and things you'd like changed about Love2D

Post by MrFariator »

Personally, perhaps the only change/addition I would like to see is more built-in functionality for asynchronous asset loading. In order to avoid any little stutters or pauses due to file io, I have to write some code for threads that mostly stay idle and wait for instructions to load an image, sound or other file. I think you could easily just have some few functions (like ones for specifically audio, image and generic file loading), that simply take a filepath and callback function as arguments, and then they do the necessary threading under the hood. Similar could be done for file saving.

May not be what most beginners would use (who might just load all assets at game start or so, for which you don't necessarily need multithreading), but I'm sure it could be of some convenience to those who need it.
User avatar
slime
Solid Snayke
Posts: 3129
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by slime »

slime wrote: Sat Jun 05, 2021 8:03 pm I agree that love.load is pretty redundant since love 11 (however it had initialization-related reasons to exist prior to love 11) - but outright removing it and breaking a bunch of code hasn't been a priority in the past either. Maybe it could be deprecated in love 12 or something.
I was about to commit a change to deprecate love.load for LÖVE 12, but it actually does have a valid use if main.lua isn't used and everything is done in conf.lua. Modules aren't loaded when the main scope of conf.lua is executed, so love.load has to be used to run game initialization code after modules load. The no-game screen effectively does that. It's a niche use case but without other significant restructuring I don't think I'd want to remove it.
User avatar
togFox
Party member
Posts: 764
Joined: Sat Jan 30, 2021 9:46 am
Location: Brisbane, Oztralia

Re: Best practices and things you'd like changed about Love2D

Post by togFox »

I'll add one thing, for what it is worth (not much): using love.load is useful to me in a self-documenting way.

I put all the REQUIRES up top and then all the initializing stuff in Love.load.

Necessary? No. Redundant? Yes. Helps me keep my code tidy? Yes.
Current project:
https://togfox.itch.io/backyard-gridiron-manager
American football manager/sim game - build and manage a roster and win season after season
User avatar
milon
Party member
Posts: 472
Joined: Thu Jan 18, 2018 9:14 pm

Re: Best practices and things you'd like changed about Love2D

Post by milon »

Jeeper wrote: Sun Jun 06, 2021 7:23 am ...

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.
I also like the "do it yourself" approach for roughly the same reasons - I don't need all the overhead that many others might. It's actually what got me into love in the first place - very light overhead. I'm also mostly self-taught, so learning to do everything myself is good experience too.

And I'm loving the thoughts being presented here. :D
Any code samples/ideas by me should be considered Public Domain (no attribution needed) license unless otherwise stated.
User avatar
AuahDark
Party member
Posts: 107
Joined: Mon Oct 23, 2017 2:34 pm
Location: Indonesia
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by AuahDark »

For me, it would be removing love.graphics.setFont and love.graphics.setNewFont. love.graphics.print and love.graphics.printf since 11.0 accepts 2nd "font" parameter so having those 2 functions seems redundant to me.

Example

Code: Select all

-- This
love.graphics.setFont(myFont)
love.graphics.print("Some text")

-- Is same as
love.graphics.print("Some text", myFont)
Profile. Do you encounter crashes in LÖVE Android and wanna send me logcats? Please hit me up in LÖVE Discord and send the full logcat file!
User avatar
Jeeper
Party member
Posts: 611
Joined: Tue Mar 12, 2013 7:11 pm
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by Jeeper »

AuahDark wrote: Fri Jun 18, 2021 11:05 am For me, it would be removing love.graphics.setFont and love.graphics.setNewFont. love.graphics.print and love.graphics.printf since 11.0 accepts 2nd "font" parameter so having those 2 functions seems redundant to me.

Example

Code: Select all

-- This
love.graphics.setFont(myFont)
love.graphics.print("Some text")

-- Is same as
love.graphics.print("Some text", myFont)
Say you want to use the same font everywhere, now you only need to call love.graphics.setFont(myFont) once.
I also just am used to calling love.graphics.setFont(), feels the same as .setColor()
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Best practices and things you'd like changed about Love2D

Post by grump »

Immediate mode is cumbersome. That's why there's love.graphics.newText, so you don't have to setFont and print all the time like a pleb.
User avatar
AuahDark
Party member
Posts: 107
Joined: Mon Oct 23, 2017 2:34 pm
Location: Indonesia
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by AuahDark »

Jeeper wrote: Fri Jun 18, 2021 12:22 pm Say you want to use the same font everywhere, now you only need to call love.graphics.setFont(myFont) once.
I also just am used to calling love.graphics.setFont(), feels the same as .setColor()
In my opinion being explicit is better. Stray `setFont` calls may mess up your font rendering.
Profile. Do you encounter crashes in LÖVE Android and wanna send me logcats? Please hit me up in LÖVE Discord and send the full logcat file!
User avatar
pgimeno
Party member
Posts: 3541
Joined: Sun Oct 18, 2015 2:58 pm

Re: Best practices and things you'd like changed about Love2D

Post by pgimeno »

To me that's a bit like saying that setColor should be removed and every draw call should have the colour specifier as a parameter. Yes, a misplaced setColor may mess up your drawing, like a misplaced setFont may mess up your font rendering, but it's still good to have.
User avatar
Xii
Party member
Posts: 137
Joined: Thu Aug 13, 2020 9:09 pm
Contact:

Re: Best practices and things you'd like changed about Love2D

Post by Xii »

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.
Post Reply

Who is online

Users browsing this forum: No registered users and 18 guests