LÖVE

I would like to create save the defauit love.run() callback function
like this; what do I do to get a pointer to a function?

function love.load()
lr = love.run()
end

--then redefined love.run
function love.run()
fori=1,50,1 do
splash()
love.graphics.present()
end
--later I want to change to a different love.run() callback definition maybe in an event or after a while.:
love.run = lr
end

--What if I want to change the state of the love.focus() callback without using events....

Don't use parentheses: And it's not a pointer to the function, it is the function value. Lua has first-class functions.

Anyway, your thingy is not going to work, because love.run is only called once in boot.lua. (Furthermore, love.load is only called in love.run...)

What you want is game states. Are you familiar with the term or would you like an introduction?

Technically, these are function pointers.

Either way, once you call the love.run function (or any of it's equivalents), you wouldn't be able to dynamically change it - everything happens from within an infinite loop inside of it. You would need to exit this loop and then exit the function, which leads to program termination as the execution goes straight to the end of main file.

I second Robin's suggestion though. Simply set your love.update and whatnot functions to whatever they should be (one of your other functions) dynamically. That'll do the trick.

So the love.run() function is called by the boot after the love.load() function is called once?

What if love.load() doesn't return?

What if I overwrite love.run() to run another function run2() when that returns then run3(). Can I set love.run =nil while I am within the function? Its just a pointer right?

So the love.run() function is called by the boot after the love.load() function is called once?

What if love.load() doesn't return?

Default love.run calls love.load. It does not accept any return value, so if there's any, it's simply discarded - it is irrelevant.

What if I overwrite love.run() to run another function run2() when that returns then run3(). Can I set love.run =nil while I am within the function? Its just a pointer right?

If you (re)write love.run function, it will be called instead. Note that love.run is your whole game, everything happens from within it. See wiki article love.run.

You can do what you suggested, as having sub-run functions called from main run function. This is acceptable, but I fail to see the point - you're not going to need different processing pipeline. If you do though, I really would like to hear why.

You can set it to nil, but as it's already running and won't be called again, it doesn't change anything.

LoveHurts wrote:What if love.load() doesn't return?

You mean like an infinite loop or an exception?

LoveHurts wrote:What if I overwrite love.run() to run another function run2() when that returns then run3(). Can I set love.run =nil while I am within the function? Its just a pointer right?

I'm not sure what your end goal is here. I'd suggest you start by not overriding love.run until you are more experienced with both Lua and LÖVE. Even I rarely change love.run from the default.

The reason why I wanted to do this is I was looking at the code for another game... and it seems to run a little slow. So I was trying cut out as many if statements as a could. I never want to check if its the gamestate. I just want to switch to the correct states at the right time by overwriting the love.run() function or one of its child threads...

The odds that you'll significantly improve performance by what you're describing here is next to zero.

I would suggest profiling some parts of the code and figuring out which are slowest. A simple if statement on the game state is unlikely to be the problem. More likely it's something like unneccesary calculations, inefficiency storage of data, or loads of draw calls that can be optimised away.

LoveHurts wrote:The reason why I wanted to do this is I was looking at the code for another game... and it seems to run a little slow. So I was trying cut out as many if statements as a could. I never want to check if its the gamestate. I just want to switch to the correct states at the right time by overwriting the love.run() function or one of its child threads...

That's like trying to make a car go faster by removing the paint. Focus on the engine, the wheels and the structure weight. In a program that's the code that is executed a lot (i.e. loops), the instructions that are slow to execute (reading from the disk on each frame, for example) or lots of recursion (functions calling functions calling functions calling the first functions). Removing one isolated "if" is of no consequence (unless it's inside of a big loop, or its condition depends on a disk read, etc).

From what you described, gamestates is your choice.

You can easily re-define a callback as following: etc.
Replacing callbacks like that ultimately gives zero performance overhead, due to the way love.run and event handlers work. Although I second kikito's words.

Also, what you're doing is basically a premature optimization. Before you do that, you should figure what's causing the slowdowns.