LÖVE

Posted: **Fri Aug 09, 2019 3:17 am**

Hi, I'm doing a server version of my game without a graphic interface

Somehow the delta time varies and that makes my game look very laggy

I tested my code using lovec.exe

Using a simple print(dt) I had this result

With UI

t.window.vsync = 1
t.modules.window = true
t.modules.graphics = true

0.016947906610767
0.016966412619695
0.015946011801134

Without UI

t.window.vsync = 1
t.modules.window = false
t.modules.graphics = false

0.0019976209496235
0.0029990017028467

I tried to round the number (dt*10 or 1/60), but my game entities collapse and move very crazy

Update : I make a test file and I have the same result

Posted: **Fri Aug 09, 2019 9:03 am**

If your game uses the dt value properly, it shouldn't matter, it'll work the same way regardless of framerate, so I suspect your problem is that you don't in fact use dt right.

If you want to throttle the thread, you can use timer.sleep function - that is, modify love.run to sleep the remainder of 1/60th of a second after its done processing things, rather than 1 ms by default.

Posted: **Fri Aug 09, 2019 11:04 am**

AdrianN wrote: ↑Fri Aug 09, 2019 3:17 am Hi, I'm doing a server version of my game without a graphic interface

Somehow the delta time varies and that makes my game look very laggy
[...]

vsync basically pauses execution until the next frame, but since that is done by OpenGL, if you don't have OpenGL then you have no vsync.

Servers usually run at a fixed frame rate, independent of the client's frame rate. One thing is the world update timestep, a different thing is the display rate timestep. For example, Second Life servers run at 45 updates per second, and Minetest runs at 10 updates per second.

You can run your server at whatever timestep you wish it to run. If you choose a 60 Hz update rate (which is close to the client's display rate, though it will never match exactly), you can accomplish that with sleeps.

The idea is: at the beginning of the update, take a time measurement (love.timer.getTime() works well for this purpose). At the end of the update, wait for the time remaining to match your chosen update rate.

Here's an example Say you choose an update rate of 60 Hz, that's 0.016666 seconds. At the beginning of the update, take a measurement of time, say it gives 3.4. Now, at the end of the update, for your purpose the timer should be 3.4 + 0.016666 = 3.416666, but you were faster, so the measured time is actually 3.402. This means that you need to sleep 3.416666 - 3.402 = 0.0146666 seconds to correct that.

To account for other actions that are not included in the love.update callback (like handling of other callbacks), you could take the measurement *after* the sleep instead of at the beginning of the update. But the sleep needs a sane value even in the first iteration, so the first time you take the time measurement e.g. at the end of love.load.

Rough example (untested):

Code: Select all

local targetTime
local timestep = 1/60

function love.load()
  targetTime = love.timer.getTime() + timestep
end

function love.update(dt)
  dt = timestep -- ignore given dt because we want to use a fixed one
  -- Do stuff here
  love.timer.sleep(targetTime - love.timer.getTime())
  targetTime = love.timer.getTime() + timestep
end

Posted: **Fri Aug 09, 2019 4:45 pm**

pgimeno wrote: ↑Fri Aug 09, 2019 11:04 am
vsync basically pauses execution until the next frame, but since that is done by OpenGL, if you don't have OpenGL then you have no vsync.

Servers usually run at a fixed frame rate, independent of the client's frame rate. One thing is the world update timestep, a different thing is the display rate timestep. For example, Second Life servers run at 45 updates per second, and Minetest runs at 10 updates per second.

You can run your server at whatever timestep you wish it to run. If you choose a 60 Hz update rate (which is close to the client's display rate, though it will never match exactly), you can accomplish that with sleeps.

The idea is: at the beginning of the update, take a time measurement (love.timer.getTime() works well for this purpose). At the end of the update, wait for the time remaining to match your chosen update rate.

Here's an example Say you choose an update rate of 60 Hz, that's 0.016666 seconds. At the beginning of the update, take a measurement of time, say it gives 3.4. Now, at the end of the update, for your purpose the timer should be 3.4 + 0.016666 = 3.416666, but you were faster, so the measured time is actually 3.402. This means that you need to sleep 3.416666 - 3.402 = 0.0146666 seconds to correct that.

To account for other actions that are not included in the love.update callback (like handling of other callbacks), you could take the measurement *after* the sleep instead of at the beginning of the update. But the sleep needs a sane value even in the first iteration, so the first time you take the time measurement e.g. at the end of love.load.

I didn't know how it worked, I thought it was my code, but trying run a simple main.lua I realized it was the vsync and OpenGL but I didn't know how to fix.
It was very strange that without any graphics and window my game run laggy.
I think the game was moving faster and down the low dt, this one in sight seemed slow

And I understand why I don't work dt=1/60 haha

Thank you for the explanation pgimeno, the code work fine.

Thanks for your replies guys

LÖVE

[SOLVED] Small delta time without graphics and window

[SOLVED] Small delta time without graphics and window

Re: Small delta time without graphics and window

Re: Small delta time without graphics and window

Re: Small delta time without graphics and window