LÖVE

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.

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.

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.

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.

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

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

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.

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.

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.

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.