Notes:
- Reaaaaally long explanation
- Read it with love.run by it's side so you can follow up with the code
- If needed be you can check the sources, I didn't put the links directly on the text but they are at the end
Functions:
Well
love.run is the last step of the main function. Basically there are three functions:
- love.boot: Initializes the filesystem, mounts the .love file, checks if conf.lua or main.lua exists and if they don't shows the no game screen.
- love.init: Requires conf.lua, executes love.conf, sets up the window, the event handlers, the modules, and the console, then requires main.lua
- love.run: The one we are interested in...
love.run:
So first it sets the random seed for
love.math.random (
love.math.randomSeed) so that you always get different values every time you run LÖVE (If you passed the same value every time you started LÖVE love.math.random would generate the very same numbers across sessions).
Then it calls
love.load (if it exists) which you probably defined in your main.lua file (which was previously required in love.init) and passes the global arg table where the command line arguments used to execute the game can be found. If I executed the game from the command line with the command "love game.love --fused "argument whatever" the table would look something like:
Code: Select all
{
[0] = love
[1] = game.love
[2] = --fused
[3] = argument whatever
}
Then it sets dt to 0 which will later be changed and passed to update.
Then it has got an infinite loop, this is because you need to keep on executing all the time until you quit the game.
The first step of the loop is to pump the event queue (
love.event.pump), this is a stack with all the events that happened since the last frame. You then iterate through the stack using the
love.event.poll iterator, which returns an event and 6 arguments (for example "mousepressed", 63, 61, 2, false would mean that there was a mousepressed event at x=63 and y=61, with the right button and it wasn't a touch)
If the event is registered in the love.handlers table then it calls the love.handlers[event] function with the 6 arguments. This love.handlers functions are just function that then delegate to the more known callbacks. So for example there is love.handlers.mousepressed which checks if love.mousepressed exists and calls it passing all the arguments it received, but if love.mousepressed doesn't exist then the event is ignored
Also if the event was a quit event it directly checks if there is a
love.quit callback and if that function returns a falsy value (false or nil) then quits the game by returning from the love.run function which breaks the loop and terminates the game.
Then the timer is stepped with
love.timer.step and dt is changed to
love.timer.getDelta which is then passed to
love.update if love.update exists (otherwise we don't call it because that would throw an error)
Then we check that graphics are active (
love.graphics.isActive) so we can know if we can draw to the screen or not, and if we can then we clear the window (
love.graphics.clear) with the current background color (
love.graphics.getBackgroundColor), reset all the transformations we made in past frames with
love.graphics.translate,
love.graphics.rotate and
love.graphics.scale, this is done with
love.graphics.origin.
Then if
love.draw exists we call it, and after that we call
love.graphics.present which actually displays everything we drew in the screen.
After that there is a sleep (
love.timer.sleep),
this is done so that LÖVE doesn't consume a lot of CPU, basically the sleep tells the operating system to do it's stuff since we have already completed our stuff for now, when the sleep ends we request the CPU to continue executing the game, this repeats every frame.
The sleep is not that big, but it's enough to lower the load LÖVE has on the CPU.
Then the loop runs again... and so on until the
love.event.quit is fired
Source code:
love.handlers
main function
love.boot
love.init
love.run
