LÖVE

Is there any effective difference between putting stuff in love.load() versus just putting stuff in the beginning of main.lua? Why would you choose one over the other?

Thanks!

if you put it anywhere in the body of main.lua outside of any function, it will load and execute that code before love.load is called, otherwise it'll run the code when love.run calls love.load. That's most of the difference.

I get the feeling that love.load only exists because that's how other game frameworks do it, even those in languages where code cannot be executed outside of a function or classes. Load() would be necessary in such languages, but effectively is not necessary in lua. For example, you could just put everything you wanted to be in love.load() after you define all your other callbacks in love.

One benefit is that you can use love.event.quit( 'restart' ) and love.load() will be run

Currently the seed for love.math.random is set just before love.load is called (after main.lua is loaded), in the default love.run. LÖVE 0.11 will make that obsolete by setting the random seed when the love.math module is loaded (before main.lua is loaded) though.

davisdude wrote: ↑Sat Oct 21, 2017 1:03 am One benefit is that you can use love.event.quit( 'restart' ) and love.load() will be run

love.event.quit("restart") does as close to a full restart as possible - the entire lua instance shuts down and is recreated, conf.lua is loaded again, main.lua is loaded again, etc.

I asked this on the IRC in the past, and was given the same answer as davisdude. But I've never really used love.event.quit('restart'), so I haven't tested the outcome. If restarting the game using that command does completely reset and run the main.lua again from scratch, what is the purpose of love.load()?

I've never used it in any of my projects. I always put my initialization code in the main file above my love.update(), love.draw(), etc.

Hm..
Isn't love.load the only way to get command line arguments without editing the love.run?

MadByte wrote: ↑Sun Oct 22, 2017 5:26 amIsn't love.load the only way to get command line arguments without editing the love.run?

Nope. There's a global arg table.

It's just sexier to have it in love.load mmmkay? Who wouldn't want to load their love? Bad guys.


Don't be a bad guy, load your love!

Perhaps a little late to mix myself in this one (this is an old thread I know, and I know the woes of thread necromancy).

It is the way Lua has been set up as a language not essential to have a load() callback indeed. I do prefer to have it in my projects though for various reasons. It can make sure all definitions and "declarations" (as far as you can speak of that in Lua) are done before you do some actual loading.
This will cause an error (Trying to call a "nil" value).

This however Will just put "Hello World" on the stdout console and not throw any errors.
If you have various reasons (most of all "code cleanness") to have an alternate order in which things are called, you must in "direct calling" always take the order of the code in mind. The load callback takes that issue away.
And since also in LÖVE some very dirty ways of dumping code together are possible (Lua has been set up for that. Trust me, I tried), you can at least make sure that when love.load is called everything outside the love.load function has been properly defined. Having a load callback can be a conflict preventer.

It's for that reason I prefer to use the load callback, and in some Lua engines I made myself prior to investigating LÖVE I also put such a callback in, practically for the same reason. And to put it even sillier, in BlitzBasic and BlitzMax where such callbacks are not even supported at all much of my "main code" looks like this: