[SOLVED] How can i stop updating whilst the window is being moved?

[unixfreak]

I have a problem with some basic collisions, that when the window is dragged across the desktop, collisions are failing either causing the player to die as the window is dragged or many objects falling through platforms.

How can i combat this?


pseudo code example of what i want to achieve:

Code: Select all

if not love.window.isMoving() then
    love:update()
end

Basically, pausing everything whilst the window is being moved across the desktop. Is this possible, or do i need to find another method?

[s-ol]

Usually this happens because the window is not being updated while you drag it, and as a result the dt is very high after it is dropped. Try putting dt = math.min(dt, 1/30) at the top of love.update and see if that fixes it / whether thats whats going on.

[HugoBDesigner]

I was going to suggest the "math.min" thing for dt, but if you want the deltaTime to be accurate but also prevent that, just do a simple check on the "length" of it:

Code: Select all

function love.update(dt)
    if dt >= 1 then
        return
    end
    --Your normal update code here--
end

[substitute541]

Alternatively:

Code: Select all

function love.load()
  ACCUMULATED_DELTA_TIME = 0
end

function love.update(dt)
  ACCUMULATED_DELTA_TIME = ACCUMULATED_DELTA_TIME + dt

  if ACCUMULATED_DELTA_TIME > 0.016666 then -- approx 1 / 60
    ACCUMULATED_DELTA_TIME = 0

    -- run stuffs
  end
end

or:

Code: Select all

function love.load()
  ACCUMULATED_DELTA_TIME = 0
  MAX_UPDATE_LOOPS = 3
end

function love.update(dt)
  ACCUMULATED_DELTA_TIME = ACCUMULATED_DELTA_TIME + dt
  local num_update_loops = 0

  while ACCUMULATED_DELTA_TIME > 0.016666 and num_update_loops < MAX_UPDATE_LOOPS do -- approx 1 / 60
    ACCUMULATED_DELTA_TIME = ACCUMULATED_DELTA_TIME - 0.016666
    num_update_loops = num_update_loops + 1
    
    -- run stuffs
  end
end

The first rate-limits the update loop to 60 fps. If the dt happens to be larger than 1 / 60, the code within the if statement will run only once. This does mean if your game happens to run below that, the code within the `if` statement will run half the time.

The second is a slightly more smarter approach using a while loop. It runs as many update steps if necessary. Example: if your game happens to run in 30 fps, the code within the while loop will run two times. Note that the MAX_UPDATE_LOOPS is kinda necessary; if you hold the window for too long, the while loop is gonna run far longer than necessary and probably crash your game. Modify if necessary.

[s-ol]

If you are running accumulated dt I would put that into love.run though instead of hacking love.update.

[unixfreak]

Usually this happens because the window is not being updated while you drag it, and as a result the dt is very high after it is dropped. Try putting dt = math.min(dt, 1/30) at the top of love.update and see if that fixes it / whether thats whats going on.

Thanks for the suggestions all, i've gone with s-ol's as it seems more simple.

I'm already using some code based on the second snippet here to cap the fps manually outside of vsync (in game option can toggle vsync on/off)

so i used in love.update()

Code: Select all

	dt = math.min(dt, 1/max_fps)

Which seems to be a fix for anything that max_fps is set to, aswell as working with vsync. Nothing seems to fail a collision now. Thanks. Hopefully it shouldn't cause other problems

Also here's the fps related code i now have, in case anyone else might find it useful (or if someone can see any issues with it).
Just adjust max_fps to any value you need.

Code: Select all

function love.load()
  max_fps = 120
  min_dt = 1/max_fps
  next_time = love.timer.getTime()
end


function love.update(dt)
  dt = math.min(dt, min_dt)
  next_time = next_time + min_dt

  --[[ update code

  --]]
end


function love.draw()

  --[[ draw code


  --]]

  local cur_time = love.timer.getTime()
  if next_time <= cur_time then
    next_time = cur_time
    return
   end
  love.timer.sleep(next_time - cur_time)
end