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
[SOLVED] Small delta time without graphics and window
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: Small delta time without graphics and window
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.
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.
Re: Small delta time without graphics and window
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
Re: Small delta time without graphics and window
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.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.
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
Who is online
Users browsing this forum: Google [Bot] and 63 guests