problems with input at low framerates

Unity Engine
1

I noticed that when I’m running at low fps I get delayed input responses on mouse buttons. For instance if I press the mouse button very fast to shoot a prefab it keeps shooting even after I stopped pressing the mouse button.

This is more noticeable on webplayer builds, the input documentation states that Input.GetKeyDown returns true on the frame the user pressed the key down, but seems like a buffer of my mouse clicks is being created and processed so no click is missed.

This is terrible for my game since I expect players to mash the mouse buttons and this results in the character being locked into the shooting state for a period of time making the game unresponsive.

I’ve uploaded a web player that illustrates this issue.

http://www.c2estudio.com/manySpheresTestWeb.html

Just mash the left mouse button and you’ll see what I mean.

I just got a lot of spheres and very high settings on shadows to force a low fps.

The code I use to shoot is:

var prefabToShoot : GameObject;
var forceStrenght : float;

function Update () 
{
	
	if(Input.GetKeyDown(KeyCode.Mouse0))
	{
		if(!prefabToShoot.rigidbody)
		{
			Debug.Log("prefab needs a rigidbody");
			return;	
		}
	
		var instance : GameObject = Instantiate(prefabToShoot);
	
		instance.rigidbody.AddForce(transform.forward * forceStrenght);

	}
}

Is there anything I can do to fix this?

1 Like
2

I’d also like to add that when running on the editor the input performs a lot better to the point that this is not an issue.

3

Sorry if this is a stupid question or anything, I’m sure some of you have encountered this, how did you resolve it? I really need to find a way to fix this, first I thought it was my code, that’s why I wrote the little demo but now that I know it’s a general issue I’m out of ideas.

Please help… :cry:

4

It’s possible the clicks are queued at an OS level, in which case there’s not much Unity can do that I can think of, although it’s interesting that it doesn’t happen in the editor. Actually it looks like all input is queued: if you click a lot of times and then press the right mouse button, it won’t show the context menu until all the left clicks were processed. Short of “fixing” it by not having a low frame rate, I’m not sure what the answer is.

–Eric

5

How about trying Input.ResetInputAxes(); on MouseUp?

if (Input.GetButtonDown (“Fire1”)) {

// fire ball }

if (Input.GetButtonup (“Fire1”)) {

Input.ResetInputAxes();

}

*Edit: Never mind, it doesn’t appear to flush the queue looking at the docs.

6

The clicks might be getting queued by the OS, but if that’s the case I wonder what the unity editor is doing so it doesn’t affect it that much, whatever that is, is what I need to do, any unity devs reading? can you give me a hint?

7

Still unable to figure this one out and I’m afraid its out of my hands now, without knowing how unity handles its input and how it does it in the editor to minimize the impact on low fps.

I seem to remember back when I learned direct input 9 that you could use buffered and unbuffered input, I’m not sure what unity uses for it’s input or how they initialize it, but if I could just set that to use unbuffered input my problem would go away.

Again without more knowledge I’m just assuming things that are out of my control… What I do need is to fix my game…

Is this something I have to pay support for? Someone from Unity please answer, we really need to get this fixed or have more clarity on the issue.

Thanks Eric and Quietus for their replies, atleast I know I’m not asking something trivial. :?

8

After some testing with the help of some in the irc channel I found out that this issue is related only to mouse button input, if I do the same but check for the spacebar everything behaves as expected. Any clues?

This issue happens in web player and standalones (macOSX, can’t verify on windows) and it doesn’t happen at all when running the scene on the editor.

9

I have the same issue in our game - sometimes it gets so serious that the player keeps firing for 10 or more seconds until the buffer is fully dequeued.
I’m sure it’s something simple, and one of the Unity guys can give some input, no pun intended.

10

Thank God I’m not the only one who has an issue with this! :wink:

I mean sorry you have the same problem as me, lets hope we get some info on what is causing this and how to prevent it from happening.

I’ve been actively asking in the irc and currently emailing support, I’ll post any findings in here.

By the way does the issue happen in the editor for you?

11

A quick update…

I recieved an email form UT, this issue is related to how the unity player for macosx handles the mouse input and will look into a solution on Unity 2.5 or 2.6.

Hoping its 2.5…

12

Hi, ratamorph,
I have that same problem in my game, but it’s related to Keypad input. Anyway it’s the same problem, it looks it returns true in ALL the frames the user keep the key pressed and not only on the first frame. Your last post is rather old, did you got some news lately?
Many thanks.

13

I have this problem when reading the keyboard. I run my input reading in FixedUpdate. I don’t know if that is right or not. When I have high fps, the user input is lost for ever. When I have low fps, the user input is read more than once.

	public override void ReadUserInput()
	{
		if (Input.GetButtonDown("GearUp"))
		{
			mCurrentGearIndex++;
		}

		if (Input.GetButtonDown("GearDown"))
		{
			mCurrentGearIndex--;
		}
	}

Anyone knows a solution for this?

/Zelk

14

Have the same issue here, it’s quite critical in my game. Any news?

1 Like
15

I just tested with this code:

void Update() {
        if(Input.GetKeyDown(KeyCode.RightArrow)) {
            print("Pressed " + Time.time);
        }
}

In the low frame rate, I can see “Pressed” a lot. (Even not low frame rate, sometimes I can see it)

1 Like
16

Note that using Unity 2019.1.0f2

1 Like
17

Yeahh this is still an issue. Mouse inputs are lost at low framerates with update and fixedupdate on windows… I’m wondering how people work around this. (2021.3.16f1)

18

Please do not revive 15 year old threads. Make a new one if you are having a similar sounding issue.

You’re supposed to read input in Update(). As long as you do that, no input events will be lost. Do not read input in FixedUpdate() - it can run more than one time a frame (which will cause you to read same inputs twice) or less than once per frame (which will cause you to miss inputs).

1 Like