Missing mouse input

I’m debugging a rare issue where input is sometimes blocked. I stumbled on an issue that might be related. If the mouse is pressed and held, then released and quickly pressed again that input is ignored by Defold.

I thought I was imagining things until I recorded it with quicktime, which shows the actual input. Around 4 seconds in, the press input is ignored:

Minimal project: MouseInputIssue.zip (670.7 KB)

I thought it might have something to do with these settings in the game.project:

32

But setting those to never fire (a high repeat delay), or to fire more frequently (a low repeat delay and interval) makes no difference.

In my game this issue results in the player not jumping if clicking too quickly. Is there anything I can do to fix this?

Hi, I’ve tested your project, and that’s not easy to reproduce…

But why you don’t verify the action_id here? Is this intentional?
image

1 Like

Yeah, it’s not easy! But you managed to do it, right?

I based this on a different debug project, so there is probably old code in there. Would any changes that you had in mind fix the issue?

No, I didn’t reproduce it. I would need hyper fast fingers or slow down the frame rate to 5FPS at least :smiley:

Well you need to understand well what the code is doing… I still don’t get it :wink:

For example this value is always nil:

action.touch

I think that field “touch” doesn’t exist in the action value.

You could try these two fixes from your side:

Thanks @piXelicidio. I made those changes and I’m afraid the issue is still there.

An updated version of the minimal example with the changes: MouseInputIssue.zip (670.7 KB)

I am able to reproduce it consistently. I’m using MacOS.

Yes, those are remnants from a different project. They don’t affect the issue, which is still there, though.

To remove any question marks about the code, here is a clean version with no reference to the old project (I hope!):

function on_input(self, action_id, action)

	pprint("on_input", self, action_id, action)

	if action_id == hash("touch") and action.pressed then
	
		-- Print touches
		local str = table_print( action )
		local pos = vmath.vector3(action.screen_x,action.screen_y,0)
		msg.post("@render:", "draw_debug_text", { text = str, position = pos, color = vmath.vector4() } )
		--

		-- Create sprite
		local game_object = factory.create("go#factory")
		local distance = 200
		local degrees = math.random(360)
		local radians = math.rad(degrees)
		local x = action.x + math.cos(radians) * distance
		local y = action.y + math.sin(radians) * distance
		go.set_position(vmath.vector3(x,y,0),game_object)

		-- Tint sprite
		local sprite = msg.url(nil,game_object,"sprite")
		local r = math.random(255)/255
		local g = math.random(255)/255
		local b = math.random(255)/255
		go.set(sprite, "tint", vmath.vector4(r,g,b,1))

		-- Animate sprite
		go.animate(game_object, "position", go.PLAYBACK_ONCE_FORWARD, vmath.vector3(action.x,action.y,0), go.EASING_INOUTSINE, 0.25, 0, function()
			go.delete(game_object)
		end)

	end

end

MouseInputIssue.zip (670.3 KB)

Here is a new video, the issue happening around two seconds in:

All that out of the way, can anyone think of a solution to this quite clear cut issue?

Well I found it, and it’s starting to worrying me too!

I set the Frame cap to 10 and disabled Vsync

Then stripped off the project from all the noise, reduced it to:

function init(self)
	msg.post(".", "acquire_input_focus")	
end


local touches = 0

function on_input(self, action_id, action)
	
	--if action.pressed then
	if action_id == hash('touch' ) and action.pressed then 	
		-- Print touches
		touches = touches + 1 
		print('pressed',touches )
	end

end

Then the issue is there when I release the mouse click and click again quickly happening in a single frame!

1 Like

So to conclude:The issue happens with default frame cap and vsync settings, and is exacerbated by reducing frame cap and removing vsync.

Does anyone out there in the Defold universe have any ideas of how to fix or mitigate this?

The issue happens when the actions happens all in the same frame. Reducing the frame rate allow me reproduce it easier.

I can also confirm that happens also for keyboard input.

The docs promise us to send all the actions happening on a single frame, (how it’s supposed to be), so something is wrong:

1 Like

Hmm, I’d need to read the code to understand more what’s happening, but also, I could interpret the documentation differently. The input action is a state, in the input system, and each frame it’s updated with the input (keys/mouse/etc). And, then, if it was altered, it fires an “on_input()”. That is, only once per frame per action (not per key press!).

1 Like

That’s interesting. Does this mean a release and a press input on the same frame only reports release OR press? Could this be why only the release is fired, and not press in the video?

I guess it can report both pressed and released? (again, I haven’t read the code recently so…)

Hi @Mathias_Westerdahl. If the engine is reporting the state then is expected to happen what we are seeing, because when in a single frame I release a button and press it again there is no change in the state from outside. But, I don’t believe this behaviour is the most acceptable, because I can think of few cases where the user could fall in that particular situation and the game not responding as they wished.

While the game is at 60fps or more the occurrence of this is less probable, then this can pass unnoticeable for a long time.

1 Like

I can also confirm by my few tests that the report of pressed and released keep consistent , every “pressed” has later a “released” keeping the same number of both. The miss is when they both happen during the same frame.

So, it looks like if a released and pressed happen during the same frame, neither the pressed nor released are reported. In the video below I print every action.released and action.pressed that come through:

  1. Pressed (printed)
  2. Released (printed)
  3. Pressed (printed)
  4. Released (not printed)
  5. Pressed (not printed)
  6. Released (printed)
1 Like

It would be great if you could create a GitHub issue so we don’t lose track of this. Please include as much info as possible, steps to reproduce, test app, link to this discussion etc

3 Likes

Done!

2 Likes

Any news about the correction of entries in macos? It happens to me too and it’s annoying, I’m not considering launching the version in macos for this reason since it prevents you from pressing buttons on certain occasions, and it gives the feeling that the application does not work good.

@AGulev added some information to the ticket. Please refer to GitHub for more info.