Why is the update speed too fast? (DEF-1785) (SOLVED)

Bugs
#19

yes, sorry)

1 Like
#20

The comments above suggests that this might be fixed by turning on vsync for your monitor/graphics driver. Have you tried this?

#21

I think no. Maybe I just do not understand the process. It seems to me that all the animation and movement themselves frog 2 times faster than they should be. not as much as in the video above, but not as smooth as it should be

#22

Now I am trying to record a video. laptop became slow down and play has been almost comfortable. if I had a 2-fold decreased FPS. I tried to change it to “game.project name” but nothing changed … in all the examples process of the game is clearly under acceleration 2 times

#23

I believe you have to find a setting for your graphics driver or monitor in your control panel which is related to “vsync”. Have you located such a setting on you computer? Maybe @Johan or @madeyes knows where to find it?

#24

I found this option, but nothing has changed … I tried to file “name game.project” lower FPS from 60 to 30 games and had very fast tb. Then I tried it with 60 fps to 90 fps to increase, but the game still goes a little fast. There are ideas for testing?

Timestep isn't in seconds?
#25

What I need to do is going in the nVidia control panel and under “Manage 3D-settings” add a setting for dmengine.exe (I need to redo it each time Defold is updated as the folder for dmengine.exe is new each time) and turn off VSync.

2 Likes
#26

Hooray, I found a solution to your problem. The file “game.project” you need to tick “variable_dt”, update_frequency below. Everything was moving smoothly!

#27

Hi all.

I have some trouble. Fix by apply VSync in NVIDIA drivers panel. Please resolve problem globality :slight_smile: Thank you

Video - https://www.youtube.com/watch?v=8uL3lBX9lm0

1 Like
#28

Finally fixed in Defold 1.2.115

4 Likes
#29

Hi, this seems to happening to me despite 2 months after it being fixed, I need to turn on Vsync or else it becomes too fast.

p/s: I’m trying to rule out my drivers, updating it

#30

Hmm, I thought we had all update speed issues solved. @Johan_Beck-Noren? How have you configured game.project? Update Frequency and Variable Dt?

#31

What we added in 1.2.115 was the possibility to enable software vsync on desktop platforms by setting the swap interval https://www.defold.com/ref/sys/#set_vsync:swap_interval.

2 Likes
#32

Update frequency set to 60 and Variable dt unticked. I have tested with Variable dt ticked but it is still fast.

#33

We’ve recently seen something similar related to G-SYNC. Do you have this?

1 Like
#34

Hmm that seems to be the other side. The update speed only works okay with Vsync on for me, I guess mine is working fine?

#35

With Vsync off, the engine will not wait for vsync (naturally), it will run as fast as it can.
So, the game will update with a fixed timestep of 1/60th of a second per update.
Presumably, your computer can do more than 60 updates per second, so you’ll basically fast forward your game.

Using “variable dt”, makes it instead update with the correct timestep between two updates.
If you’re still seeing “too fast” behavior, I’d start checking that the animations you use are using the delta time (dt) in its calculations.
Can you give an example of your code that “runs too fast”?

2 Likes
#36

Ahh I see, it’s my fault then.

I’ve only used delta time for set_position it seems.

local speed = 100

local anim_idle = hash("idle")
local anim_move_up = hash("move_up")
local anim_move_down = hash("move_down")
local anim_move_left = hash("move_left")
local anim_move_right = hash("move_right")
local anim_speed = 1

function init(self)
	msg.post(".", "acquire_input_focus")
	self.dir = vmath.vector3(0,0,0)
	self.dir_pressed = false
	self.anim = nil
	self.curr_key = hash("")
end


local function play_animation(self, anim)
	-- only play animations which are not already playing
	if self.anim ~= anim then
		-- tell the sprite to play the animation
		msg.post("#sprite", "play_animation", {id = anim})
		-- remember which animation is playing
		self.anim = anim
	end
end

local function update_animations(self)
	if self.dir.y == 1 then
		play_animation(self, anim_move_up)
	elseif self.dir.y == -1 then
		play_animation(self, anim_move_down)
	elseif self.dir.x == -1 then
		play_animation(self, anim_move_left)
	elseif self.dir.x == 1 then
		play_animation(self, anim_move_right)		
	else
		play_animation(self, anim_idle)
	end
end


function update(self, dt)
	local pos = go.get_position()
	--if vmath.length(self.dir) > 0 then
	--	self.dir = vmath.normalize(self.dir)
	--end
	go.set_position(pos + self.dir * speed * dt)

	update_animations(self)
	if self.curr_key == hash("") then
		self.dir = vmath.vector3()
	end
end
	
function on_message(self, message_id, message, sender)
	-- later
end

function on_input(self, action_id, action)
	if self.curr_key == hash("") then
		if action_id == hash("right") then
			self.dir.x = 1
			self.dir.y = 0
			self.curr_key = hash("right")
		elseif action_id == hash("left") then
			self.dir.x = -1
			self.dir.y = 0
			self.curr_key = hash("left")
		elseif action_id == hash("front") then
			self.dir.y = -1
			self.dir.x = 0
			self.curr_key = hash("front")
		elseif action_id == hash("back") then
			self.dir.y = 1
			self.dir.x = 0
			self.curr_key = hash("back")
		end
	end
	
	if action.released then
		self.curr_key = hash("")
	end
end
#37

Well, I don’t see anything wrong with your code.

The sprite’s flipbook animations are already taking the delta time into account. So since you are using no vsync and 1/60s for each update, they’ll update too fast. So for that reason, you probably want “variable_dt” ticked.

But you mention you still see “too fast” behavior? For what parts? The position, or the sprite playback?

1 Like
#38

I will update here a recording through my phone,screen recorders is messing it more.