Unclear % operation for counting

[zorg]

You can use modulo like this if you are getting os.time() instead of dt, because os.time() (at least on windows and linux) returns an INT. You can also, alternatively, floor the return of love.timer.getTime(), which I think would be more compatible with other platforms where what os.time() returns may not be consistent. I use it all over the place for simple animations (things that pulse on a frequency of 0.5 or 0.33hz, for instance). For anything that needs a frequency outside of that, use a timer instead.

You don't need the function to be aware of dt in this case as it can be using only local vars, but I tend to have a ton of timers that are all global anyway all over the place.

Consider the fact that os.time is not the same as what love.timer.getTime returns; the equivalent would be os.clock... and even then, löve's implementation has more precision. (and is recommended to be used)

Instead of doing hackish stuff, just implement a fixed timestep if that's what you need for your game; your heartbeat example was one of those, kinda.

Actual implementations with counters were posted earlier in the thread.

[Hadrombolac]

super helpful stuff zorg, soulmata and pgimeno. Thanks!!!

[Hadrombolac]

I forgot to add one more thing. Am playing around and testing some scoping things regarding your suggestions about the counter. Realized Im in the dark about whats the code execution priority? love.load() gets called only once at the start, got it. love.update(dt) gets called every frame, got it.What about the functions I write in between?

Heres an example

Code: Select all

local spawnTimer = 0
local spawnVar = math.random() + math.random(1)

function love.load()

end

function love.update(dt)

     spawnTimer = spawnTimer + dt

    if spawnTimer > spawnVar then
        print(spawnVar)
        spawnTimer = 0
        spawnVar = math.random() + math.random(1)
        
    end
   
end

this nicely writes out a random float every random float time interval. But If I put the initial local spawnVar init in the love.load() I get an error : attempt to compare nil with number. How so? Doesnt love.load() init all variables before update gets called?

[soulmata]

Unless you get around to using threads, everything (barring a few edge cases like immediate mode GUIs) is executed in serial. There's no prioritization - a function will execute, complete, and then return control to whatever function called it, and so on. Ultimately love.update is coordinating that, so your code "priority" is in fact the order of the code in love.update.

I use a form of rudimentary "Scheduling" for things in love.update(), by having a function set a flag which will then change what love.update() does later in the same frame - a good example is saving the game, because there is a momentary hiccup when this happens. Rather than doing that in the middle of a draw operation or when the user would notice, I set a flag, that flag is evaluated at the end of love.update() but after it's done with love.draw(). But this is not asynchronous - everything is still in order in love.update().

The reason you'd be getting a nil error is in your example, you'd attempting to perform an operation on a nil, exactly as it says, because spawnVar is local to love.load(). If spawnVar is only ever needed by love.update() and you want it redefined on every frame, you make it local to love.update(). If you want it global, just remove the 'local' - you could then have love.load() define it. Local variables are lexical to the function that creates them - ONLY that function can access that variable - the one exception being upvalues which is not something you really need to think about..

[Hadrombolac]

thanks alot, again for this amazing description soulmata. So regarding functions, that means if they dont get called in update() regardless where they are written, they never execute?

About local variables, I see tutorials that declare local variables in love.load(). Are those still considered global variables?

[BrotSagtMist]

@BrotSagtMist : you say above that one cant extract fixed values out of floats, but then say its a hacky solution. I presume a hacky solution would still print something to the console?

You only need to multiply DT by say 10 times and snip off the after point stuff. Then youll get a normal counting thing that should work most of the time, emphasis on most.

About local variables, I see tutorials that declare local variables in love.load(). Are those still considered global variables?

Bad bad tutorials.
Then again i never got why to even use love.load
But no, local means it stays inside this block or within functions declared in this block. So unless you create functions also in there it makes zero sense to use locals there.

[zorg]

thanks alot, again for this amazing description soulmata. So regarding functions, that means if they dont get called in update() regardless where they are written, they never execute?

About local variables, I see tutorials that declare local variables in love.load(). Are those still considered global variables?

Functions can get called anywhere, it's just that they need to be called somewhere.
Even love.load, love.update, love.draw, etc. get called by some code you're not aware of yet.

Anyway, if you want things to be called each frame, you do stuff in / call stuff from love.update and/or love.draw

If you define a local in any block (function, do...end, for/while/repeat loops), those variables will only be available there; love.load's not special in that regard either... so either those tutorials don't expect those values to be used elsewhere, or they are busted.

[pgimeno]

At the risk of spoiling the broth:

The order of execution is:

• First, the code at the top level of main.lua. This is what allows declaring functions, because unless you execute a function declaration, the function doesn't get declared.
• Then, love.load.
• Then, in a loop:
  • all input and OS events (mouse, keyboard, window resize...)
  • love.update
  • love.draw

That's about it.

As for how locals work, it's simple. Every local is visible from the block they are declared in, and all contained blocks, and its lifetime lasts until the block where it is declared ends.

So, declaring a local at top level makes it visible everywhere in the file after the local is declared.

For example, to allow your code to run while in love.load, you can declare the variables in the top level, then use them in love.load, like this:

Code: Select all

local spawnTimer
local spawnVar

function love.load()
  spawnTimer = 0
  spawnVar = math.random() + math.random(1)
end

function love.update()
  ...
end

Declaring them at the top like that makes them visible in the whole file, and only in this file. They won't be visible in other files. Which is good, because otherwise (if they are global) it soon becomes a hell to track what file modifies a variable, and it's easy to mistakenly overwrite a variable from another file by mistake.

There's no problem with declaring local variables in love.load. For example, it's common to use loops to load assets, and 'for' loop variables are implicitly local. You just have to be aware that their lifetime ends when love.load ends, so they won't be visible from the outside.

As a side note, math.random(1) will always return 1, so you could as well write math.random()+1 instead of math.random()+math.random(1).

[BrotSagtMist]

Well, consider:

Code: Select all

counter=10
love.load=function()
 local counter=1
 love.keypressed=function()
  counter=counter+1
 end
 love.draw=function()
  love.graphics.print(counter.."___".._G.counter)
 end
end
love.keyreleased=function()
 counter=counter+1
end

[Hadrombolac]

You folks are the best!!

BrotSagtMist, what is that strange notation I havent seen before ? love.load=function()? Is that just a style preference to function love.load() ? It reminds me of code like this that I came across and didnt understand...

Code: Select all

gStateMachine = StateMachine {
        ['title'] = function() return TitleScreenState() end,
        ['play'] = function() return PlayState() end,
    }