search

Unity-Technologies / InputSystem

An efficient and versatile input system for Unity.
Other
1.43k stars 310 forks source link

Allow calling InputSystem.Update() from thread other than main thread #273

Closed felipeota closed 5 years ago

felipeota commented 6 years ago

I would like to be able to read input in a thread other than the main Unity loop (maybe jobs?). This would be specially useful in multiplayer games, the input can be read and sent to the server as soon as possible even if there is lag in the main loop.

Rene-Damm commented 6 years ago

In version 1.0, we'll still have limits on that. My hope is that we can at least get to the point where you can run input updates in manual mode on a thread. It won't be possible to concurrently access the input system in a safe way but you'd at least be able to flush out on a thread other than the main thread and at a point you determine.

Beyond 1.0, we will be looking at proper ECS integration and less restrictive threading.

felipeota commented 6 years ago

Let me see if I get it, we will be able to call the InputManager Update method on a separate thread but the OnUpdate which reads the recorded input will still be called on the main thread, right?

Rene-Damm commented 5 years ago

Sorry, didn't mean to leave you hanging. Dropped the ball on this one.

we will be able to call the InputManager Update method on a separate thread

That's where I'd like to get to. ATM Update() is restricted to the main thread. What I'd like to have is the ability to switch the system into a mode where you can instead move Update() to a thread of your choosing. It wouldn't be a fully concurrent setup and the API wouldn't be thread-safe (as in, available for concurrent access by several threads) but the thread that does input processing would no longer have to be the main thread.

OnUpdate which reads the recorded input will still be called on the main thread

It'd get called on whichever thread you invoke Update() on.

felipeota commented 5 years ago

Thanks, that's what we are looking for. Do you have an ETA for that?

Rene-Damm commented 5 years ago

Bah, keep dropping the ball here. Sorry bout that :/

Unfortunately, it looks like we'll probably not get the native work done for 1.0-preview and it'll be main-thread only. The ability to manually flush is in by now but it still has to happen in a ComponentSystem's OnUpdate rather than in a job.

We will need the ability to move off the main thread for ECS so it will happen. Just not for the initial release. Sorry I don't have better news.

StefDevs commented 5 years ago

Came here to request this as well. I want to add that it's been really disappointing to see these new APIs come so close to providing a simple data-oriented API, but then bury themselves in ECS boiler plate. Please just let me manually update in my own thread with a simple call without having to embrace ECS (I don't hate it, but I don't always want to use it).

I was really hoping this new api with "manual mode" would finally allow polling input at a rate faster than the render/main thread, but it seems not to be the case :(

(Good work in general though, the new system is a big improvement in many other ways)

Rene-Damm commented 5 years ago

Yup, understand the disappointment. Wish the timing had worked out better.

However, once we've reached verified, fitting more natively into the DOTS world and decoupling us from the main thread requirement is going to among the first work items to get going next.

Rene-Damm commented 5 years ago

Migrated the request to our internal tracking system to make sure it gets taken into consideration when we'll go look at feature work after 1.0 is in safe waters. (internal ticket ISX-273)

As part of us migrating away from GitHub issues, I'll go close this one. But no worries, doesn't mean it's forgotten :)

sharpobject commented 5 months ago

So did it ever happen?