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!
love.load vs stuff at top of main.lua
- zorg
- Party member
- Posts: 3468
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: love.load vs stuff at top of main.lua
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.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: love.load vs stuff at top of main.lua
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.
Re: love.load vs stuff at top of main.lua
One benefit is that you can use love.event.quit( 'restart' ) and love.load() will be run
GitHub | MLib - Math and shape intersections library | Walt - Animation library | Brady - Camera library with parallax scrolling | Vim-love-docs - Help files and syntax coloring for Vim
- slime
- Solid Snayke
- Posts: 3166
- Joined: Mon Aug 23, 2010 6:45 am
- Location: Nova Scotia, Canada
- Contact:
Re: love.load vs stuff at top of main.lua
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.
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.
- DanielPower
- Citizen
- Posts: 50
- Joined: Wed Apr 29, 2015 5:28 pm
Re: love.load vs stuff at top of main.lua
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.
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.
Re: love.load vs stuff at top of main.lua
Hm..
Isn't love.load the only way to get command line arguments without editing the love.run?
Isn't love.load the only way to get command line arguments without editing the love.run?
Re: love.load vs stuff at top of main.lua
Nope. There's a global arg table.
Code: Select all
print(unpack(arg)) -- works everywhere
Re: love.load vs stuff at top of main.lua
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!
Don't be a bad guy, load your love!
Re: love.load vs stuff at top of main.lua
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:
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.
Code: Select all
HelloWorld()
function HelloWorld() print("Hello World!") end
This however
Code: Select all
function love.load()
HelloWorld()
end
function HelloWorld() print("Hello World!") end
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:
Code: Select all
init
run
close
Who is online
Users browsing this forum: aikusuuta, Google [Bot] and 10 guests